Um dos mais complexos projectos open-source, o Wine, lançou o primeiro release candidate da versão 1.4 deste sub-sistema Win32 API que permite correr grande parte do software Windows em sistemas Linux.
Este longo e complexo projecto teve origem em 1993, mas foi sujeito a grandes revisões da sua arquitectura até que em 2005 apresentou o primeiro protótipo funcional do Wine (A versão 0.9.0), do qual assumiu que o sub-sistema Win32 API implementada no Wine devia ter a mesma arquitectura do Windows NT, eliminando os antigos modelos baseados no Windows 95/98 e DOS sem esquecer que as primeiras versões do Wine eram inspiradas no antigo Windows 3.1 !
As novidades da versão 1.4 podem ser resumidas em alguns pontos essenciais, e apresentam em alguns casos trabalho em curso que ficou para as futuras versões 1.5.x, dos quais destaco:
- Direct3D 9 funcional (o que não significa que existam bugs noutros componentes que impedem um jogo X de correr
), e a implementação do Direct3D 10/11 a 65%, mesmo considerando a nova arquitectura exigida para esse fim.
- Suporte inicial ao OpenCL e CUDA, sendo nestes casos um wrapper para as bibliotecas nativas do Linux.
- Migração do sub-sistema DOS/Win16 como um subsistema próprio dentro do Win32 API.
- Adopção de uma nova arquitectura de som baseada no Windows 7, e suporte ao PulseAudio (que nestes rc vão tentar limar
)
- Suporte do gstreamer para criar uma ponte entre os codecs nativos e as aplicações Windows requesitem (embora nada impeça de instalar codecs Windows para uma determinada aplicação).
- Implementação inicial (de facto) do sucedâneo Wine Internet Explorer e Mono .NET, que actuam como projectos autónomos.
- Motor DIB, que permitiu criar uma interface de abstracção gráfica entre um programa que utilize o GDI e o X server.
- A introdução da versão de 64-bits do Wine.
- E a célebre implementação experimental para dispositivos USB que não está activada na versão padrão do Wine.
O que significa esta salganhada toda, do qual mostra a tendência actual dos sistemas operativos modernos terem resmas de bibliotecas, máquinas virtuais que aumentam em muito a complexidade dos mesmos ?
Em primeiro lugar, a grande prioridade do Wine foram claramente os jogos (os de topo, evidentemente) do qual exigiria que a implementação do DirectX fosse completada. Neste plano foram completados o multisampling e corrigidos as bibliotecas responsáveis pelos dispositivos de entrada (Xinput e companhia), de modo a que a versão DirectX 9.0c do Wine permitisse correr os jogos mais recentes.
Neste plano, era óbvio que não seria possível tornar a implementação do DirectX como uma simples tradução através do OpenGL mas seria necessário criar uma camada de abstracção gráfica do qual os drivers das placas de vídeo teriam o maior papel. Outras bibliotecas matemáticas e gráfica complementadas com o OpenGL prosseguiram para resolver este problema.
Noutro plano, já era evidente que a implementação do DirectX 10/11 era inevitável pelo que a complexidade da implementação disparou devido às novas interfaces que a Microsoft criou para que as GPU compatíveis os utilizassem. Como este projecto demorou mais tempo, optaram por colocar o suporte ao DirectX 10 para a futura versão 1.6, e apesar disso conseguiram implementar 65% das funções desta biblioteca gráfica.
Deste o começo do Windows, as funções gráficas foram implementadas pela biblioteca GDI. As primeiras versões do Wine traduziam cada instrução gráfica como uma instrução para o X window server, resultando na perda de performance quando estávamos perante aplicação exigentes (embora mais recentemente tendiam a usar o próprio DirectX para ganhar velocidade de execução). A solução (apontada há 10 anos!) era criar um motor gráfico DIB (podemos ver isso como um protótipo do motor gráfico Direct3D usado no Wine) para que existisse uma camada de abstracção gráfica na memória do computador, de modo a que fosse sincronizado com o X server o buffer gráfico como um único bloco, e as instruções de actualização usando o GDI fossem mediadas pelo motor DIB.
Entretanto surgiram ao longo dos últimos tempos uma biblioteca computacional para GPU chamada OpenCL e a Nvidia desenvolvera um sistema similar designado CUDA. Como estas duas bibliotecas foram distribuídas nativamente para sistemas Linux, bastou criar um wrapper (uma implementação instrução a instrução) para que as aplicações Windows acedessem as novas funcionalidades das placas gráficas em questão, de forma transparente. No caso do OpenCL, foi implementado de forma independente no Wine as primeiras funções do OpenCL 1.0 e 1.1 para emular esta funcionalidade em placas mais genéricas.
A passagem do Windows para 64 bits (embora a maioria do software ainda seja 32 bit) levou à criação da versão de 64-bit do Wine, o que na altura em que se cria o wineprefix (uma pasta do qual simula uma instalação do Windows) pode-se optar pela criação de uma versão de 32 ou 64 bits, o que não impede a instalação de software de 32-bit no wineprefix de 64-bit, uma vez que o Wow64 foi implementado.
Quanto às antigas aplicações de 16-bit e do Windows 95/98 que utilizavam uma parte do Win32 API, a estratégia que adoptaram foi a mesma do Windows NT/XP, um sub-sistema dentro do Win32 para que as antigas aplicações tenham interface com as bibliotecas mais modernas.
Quanto ao velho Win16 API (que o Windows de 64-bit optou pela remoção total) usado por programas do Windows 3.1, a equipa do Wine tentou criar uma forma que na versão de 64-bit do Wine os programas Windows de 16-bit corressem. Isto foi conseguido ao criar versões virtuais de 16-bit do Windows 3.x (que eram na realidade de 32-bit) emparelhadas com as congêneres de 32-bit, controladas pela biblioteca WoW (que no NT serviu para correr software de 16-bit no sistema de 32-bit) do Wine. O winevdm (A máquina virtual do DOS implementada pelo Wine) carrega o Wow quando tenta correr uma aplicação de 16-bit do Windows, e o facto de terem virtualizado este sub-sistema em 32-bit permitiu este sub-sistema correr no Wine de 64 bit. (Ou por outras palavras, bateu a Microsoft por ser o único "Windows" de 64-bit que pode correr os programas de 16-bit!
)
Quanto à execução de programas DOS puros (do qual a CPU no modo 64-bit não permite correr directamente), optaram pela integração do emulador DosBox para substituir o arcaico sub-sistema DOS que não era actualizado havia anos, e desta forma liquidou muitos problemas ao optar pela emulação pura e dura.
Outra área do qual o Wine teve que implementar e resolver foi a área do multimédia, a começar pela interface com o som do qual tinha drivers virtuais para o ALSA, OSS e mais alguns e estava a ficar obsoleta com a interface unificada apresentada pelo Windows 7, e a clara imposição da arquitectura PulseAudio. A primeira parte foi implementada recentemente, mas o suporte nativo ao PulseAudio está ainda por completar devidamente, e aguardasse que seja resolvido o quanto antes da versão 1.4 final.
Outra funcionalidade foi a introdução do sistema de codecs gstreamer que permite o uso de codecs nativos por parte de aplicações Windows poderem renderizar o aúdio e vídeo, evitando a instalação de codecs Windows pelo Wine. No entanto, não significa que programas que utilizem explicitamente o Windows Media Player ou o QuickTime usem o gstreamer em vez das aplicações nativas. Criar um sucedâneo do WMP para forçar as aplicações a usarem o gstreamer seria provavelmente uma opção futura para reduzir a dependência de componentes do Windows que não seriam legalmente usadas no Wine sem uma licensa (embora não exista problema com a instalação dos codecs do WMV no Wine e Linux).
E ao referir sucedâneos, é quase obrigatório criar um para o Internet Explorer do qual apesar de ser possível instalar algumas versões no Wine, a licença não considera legal o uso num sistema operativo não-Windows. Na realidade, este sucedâneo existe e foi baptizado de Wine Internet Explorer.
O WIE não é mais que uma versão modificada do motor Gecko para Windows (O motor do Firefox é o Gecko.
), do qual foram acrescentados bibliotecas de compatibilidade características do Internet Explorer (motor Trident) e uma interface gráfica para este browser.
Infelizmente, este browser não teve a evolução necessária para se tornar minimamente funcional (e o Wine pode lançar o browser nativo do Linux, caso o programa só active um link) e serve até ao momento como um modo de compatibilidade e com muitas funções por implementar, apesar de ter várias funcionalidades parcialmente activas.
Existe a pressão para que nas versões 1.5.x o WIE se torne um browser que sirva como recurso válido para aplicações críticas que dependam do IE, e isto implica compatibilidade com os plug-ins do Flash e WMV (lançando o gstreamer), o suporte ao ActiveX (que está parcial) para que seja possível visitar determinados sites IE-only (Na Coreia do Sul é quase impossível usar um browser que não seja o IE para usar muitos sites, devido ao uso abusivo do ActiveX), sem usar o Windows.
Com o aparecimento de novas plataformas de programação por cortesia da Microsoft: .NET e suas encarnações (como o WinRT do Metro que é baseado no .NET), foram brindados com a necessidade do suporte do .NET no Wine.
É possível instalar algumas versões do .NET no Wine, mas a velha questão das licenças obriga a que seja conveniente pensar em algumas alternativas. Uma implementação open-source do .NET é o Mono que implementou com sucesso até à versão 2.0 e parte do 3.0 e 4.0, mas existem partes que são especificas do Win32 API
que terá que ser implementados pelo Wine Mono para fechar estes "pequenos" buracos.
A semelhança de que o WIE foi implementado como um projecto autónomo do Wine, não é de admirar que em breve (Wine 1.5.x) seja introduzido um Wine .NET baseado na versão Windows do Mono mais uns elementos criados pelo Wine, como um projecto autónomo.
E para acabar as novidades da versão 1.4 (como o panorama para o 1.6), só falta referir aquele que será o maior salto do Wine, o suporte de alguns controladores USB para Windows no Wine. Desenvolvido ao longo dos dois últimos anos, mas como uma funcionalidade desactivada por padrão, permite que determinados softwares desenvolvidos para certos dispositivos de hardware ligados por USB possam ser instalados no Linux usando o Wine. Isto porque muitos dispositivos (que não sejam placas gráficas, de som ou que dependam das API do núcleo do Windows) USB podem ser modulados como simples dispositivos de armazenamento, e nesta óptica foi criada uma implementação que emula parte do modo núcleo do Windows no modo utilizador do sistema operativo Linux para que seja possível operar este hardware do qual não existem drivers nativos, ou software funcional. O plano apresentado nos finais de 2011 prevê que seja na versão 1.6 que esteja implementado definitivamente o suporte USB ao Wine, habilitando certos dispositivos de armazenamento como o iPhone a funcionar no Linux correndo o iTunes no Wine (O iTunes funciona parcialmente, quanto mais o driver). No futuro, é possível que seja introduzido um wrapper para o SANE e CUPS de modo a habilitar as impressoras e scanners a trabalharem com drivers Windows usando o próprio Wine já com USB suportado.
(Embora, em muitos casos é preferível trocar a impressora não-suportada por outra em vez de esperar 2 ou 3 anos para isto ser possível!)
Depois deste longo discurso, vou jogar Assassin's Creed Brotherhood pelo Wine!