Mantendo a tradição que foi a apresentação do Wine 1.4, eu anuncio que já foi lançado o primeiro release candidate do Wine 1.6 que representa o 3º estádio de desenvolvimento após o Wine alcançar a primeira versão estável. :P
Durante estes meses todos em que decorria as versões de desenvolvimento 1.5.x, no mundo Linux ocorrerem várias coisas, tais como:
- O lançamento de alguns jogos nativos para Linux.
- O lançamento do Darling (que já veio atrasado para o meu gosto :(), que habilitou a execução de programas Mac OS X em Linux, se bem que está ainda num estado alpha...
- Por fim, lançaram este mês o primeiro emulador Android decente para Linux que permite correr aplicações deste sistema operativo numa máquina Linux Desktop, útil para quem utilize aplicações como complemento. (AndroVM foi o protótipo, agora é o GenyMotion ;))
Suspeito que a versão 1.6 seja a escolhida para criar uma versão oficial para Android, o problema é que como será escolhido e implementado o emulador x86 para os tablets (maioritários) ARM. Mesmo quando foi apresentado no FOSDEM o protótipo do Wine para Android, já existia na Google Play um emulador para correr alguns jogos (que são exactamente dois oficialmente suportados: Caeser III e Starcraft: Broody War 1.663) baseados no Windows em tablets Android: o programa Winulator.
O Winulator baseia parcialmente no source-code de uma porção do DirectX antigo (3 a 7) de acordo com o Wine, mais o trabalho do próprio autor em complementar algumas funções do WIN32 API. No entanto a grande diferença é este programa actua mais como um launcher sobre uma versão minimalista nativa em ARM do wrapper mini-DX7 para Open GL ES 2.0, acoplado com um emulador tipo binary translator/dynamic recompiler que faria a recompilação do executável do jogo (x86) num macro-código ARM na altura do lançamento da execução do jogo. Desta forma, o overhead entre arquitecturas foi minimizado e jogos que requerem pelo menos um Pentium MMX para terem um desempenho adequado podem ser executados num chip ARM dual e quad-core.
(Infelizmente o segredo daquela aplicação era mesmo o JIT x86/ARM, pelo que seria improvável que o autor cedesse o código-fonte para fundir com o Wine para Android, embora fosse o passo mais coerente, visto que o autor verificou que era impossível suster sozinho o desenvolvimento do Winulator sem fundi-lo com o Wine. :()
O Wine para Android irá resolver um problema fulcral do Winulator, visto que suportará as aplicações Desktop GDI e o DirectX, ao contrário do Winulator que requeria o rip da pasta do jogo do computador para o tablet, e só suportava o Direct3D em full-screen. Mas dificilmente o Wine superaria o módulo dos controlos que emulam parte das acções do rato que o Winulator possui (pois o seu objectivo era correr alguns jogos do Windows antigos, e não o Word!).
Embora o lançamento do Wine para Android será uma aplicação claramente disruptiva, o nosso interesse é destacar as novidades do Wine 1.6 que só serão aproveitadas devidamente em máquinas x86 baseadas em Linux ou Mac OS X. (A versão para Android não será provavelmente um port 1:1, pois dificilmente existem funções que nem a emulação x86/ARM daria remotamente qualquer rendimento palpável, salvo os tablets x86 com Android que vão surgindo recentemente).
O Wine 1.6 apresenta algumas novidades que são fulcrais (como a ênfase na versão Android que não é inocente de todo), dos quais destacamos:
- A arquitectura ARM é oficialmente suportada, embora na prática não tenha maior usuabilidade que servir de ferramenta de compilação de algum software Windows em máquinas Linux ARM. A versão para Android é derivada deste esforço. Para resolver fica a questão da emulação x86.
- O Wine para Mac OS X ganhou um driver nativo para o Cocoa API, substituindo a necessidade do X11.app para instalar e executar o Wine. Portanto as aplicações Windows no Mac OS X utilizam agora o Quartz API nativamente para o funcionamento deste emulador.
(Entretanto o suporte para X11.app ainda é mantido como opção caso ocorra problemas com o driver nativo.)
- O trabalho na emulação do Direct3D prosseguiu no último ano, destacando a implementação do próprio compilador de shaders e pipelines que pretende reduzir o overhead, e resolver alguns dos problemas de quebra de frame-rates em jogos exigentes graficamente.
- O trabalho na implementação do Directx 10 e 11 andou um bocado parado :rolleyes:, o que motivou a mobilização por parte da Codeweavers (que lança as versões comerciais do Wine com adições proprietárias) para que a equipa do Wine trabalha-se internamente na implementação do DirectX 11. O Directx 10 já uns 75% implementado, mas falta funções da interface para ser activado. Espera-se que na versão 1.8 já seja possível correr jogos DX10 e DX11, pois prevê-se que o DX9 seja gradualmente abandonado no próximo ano. (A vinda das novas consolas baseadas no DX11 vão estimular o abandono no antigo DX9).
- O Wine possui dois componentes autónomos: o Wine Internet Explorer (um wrapper MSHTML sobre o Gecko) e o Wine Mono (a implementação do .NET), que ainda não são suficientemente maduros para substituir a implementação nativa da Microsoft.
- Especula-se que uma terceira componente esteja na forja, que não é nada mais, nada menos que implementar o WinRT :wow:, habilitando a execução de Aplicações Metro pelo Wine. (evidentemente que não será pela Windows Store...)
Isto porque andaram a implementar as dll que surgiram com o Windows 8, e formam a base do WinRT (aparte do .NET que do qual é a linguagem padrão desta API)
- Também registaram correcções de bugs, completaram funções quebradas e deram continuidade a um projecto interno que estava ainda mais parado que o DX10 (que recomeçou ao cair do pano :D): o suporte a controladores nativos do Windows para certos dispositivos USB.
- Isto porque foi implementado no rc1 as primeiras funções relacionadas com o registo e instalação de controladores, que no Wine somente serão suportados controladores para dispositivos USB que operam no user-mode. (O Darling aparentemente suportará uma maior gama de controladores USB, visto que o IOKit é uma bibliotecas Unix-like e portanto mais fácil de sincronizar com o udev). Esta funcionalidade estará mais virada para dispositivos simples que são acompanhados com determinado software: como é o caso dos smartphones que utilizam software Windows para actualizar o seu firmware. (Não esperem que isso vá funcionar na versão 1.8!)
Em suma o lançamento do Wine 1.6 é mais uma versão de consolidação, mas com uma aposta clara para uma nova gama de dispositivos (os tablets Android e computadores ARM), e com o objectivo claro que preparar a versão oficial para o Mac OS X. :D
Durante estes meses todos em que decorria as versões de desenvolvimento 1.5.x, no mundo Linux ocorrerem várias coisas, tais como:
- O lançamento de alguns jogos nativos para Linux.
- O lançamento do Darling (que já veio atrasado para o meu gosto :(), que habilitou a execução de programas Mac OS X em Linux, se bem que está ainda num estado alpha...
- Por fim, lançaram este mês o primeiro emulador Android decente para Linux que permite correr aplicações deste sistema operativo numa máquina Linux Desktop, útil para quem utilize aplicações como complemento. (AndroVM foi o protótipo, agora é o GenyMotion ;))
Suspeito que a versão 1.6 seja a escolhida para criar uma versão oficial para Android, o problema é que como será escolhido e implementado o emulador x86 para os tablets (maioritários) ARM. Mesmo quando foi apresentado no FOSDEM o protótipo do Wine para Android, já existia na Google Play um emulador para correr alguns jogos (que são exactamente dois oficialmente suportados: Caeser III e Starcraft: Broody War 1.663) baseados no Windows em tablets Android: o programa Winulator.
O Winulator baseia parcialmente no source-code de uma porção do DirectX antigo (3 a 7) de acordo com o Wine, mais o trabalho do próprio autor em complementar algumas funções do WIN32 API. No entanto a grande diferença é este programa actua mais como um launcher sobre uma versão minimalista nativa em ARM do wrapper mini-DX7 para Open GL ES 2.0, acoplado com um emulador tipo binary translator/dynamic recompiler que faria a recompilação do executável do jogo (x86) num macro-código ARM na altura do lançamento da execução do jogo. Desta forma, o overhead entre arquitecturas foi minimizado e jogos que requerem pelo menos um Pentium MMX para terem um desempenho adequado podem ser executados num chip ARM dual e quad-core.
(Infelizmente o segredo daquela aplicação era mesmo o JIT x86/ARM, pelo que seria improvável que o autor cedesse o código-fonte para fundir com o Wine para Android, embora fosse o passo mais coerente, visto que o autor verificou que era impossível suster sozinho o desenvolvimento do Winulator sem fundi-lo com o Wine. :()
O Wine para Android irá resolver um problema fulcral do Winulator, visto que suportará as aplicações Desktop GDI e o DirectX, ao contrário do Winulator que requeria o rip da pasta do jogo do computador para o tablet, e só suportava o Direct3D em full-screen. Mas dificilmente o Wine superaria o módulo dos controlos que emulam parte das acções do rato que o Winulator possui (pois o seu objectivo era correr alguns jogos do Windows antigos, e não o Word!).
Embora o lançamento do Wine para Android será uma aplicação claramente disruptiva, o nosso interesse é destacar as novidades do Wine 1.6 que só serão aproveitadas devidamente em máquinas x86 baseadas em Linux ou Mac OS X. (A versão para Android não será provavelmente um port 1:1, pois dificilmente existem funções que nem a emulação x86/ARM daria remotamente qualquer rendimento palpável, salvo os tablets x86 com Android que vão surgindo recentemente).
O Wine 1.6 apresenta algumas novidades que são fulcrais (como a ênfase na versão Android que não é inocente de todo), dos quais destacamos:
- A arquitectura ARM é oficialmente suportada, embora na prática não tenha maior usuabilidade que servir de ferramenta de compilação de algum software Windows em máquinas Linux ARM. A versão para Android é derivada deste esforço. Para resolver fica a questão da emulação x86.
- O Wine para Mac OS X ganhou um driver nativo para o Cocoa API, substituindo a necessidade do X11.app para instalar e executar o Wine. Portanto as aplicações Windows no Mac OS X utilizam agora o Quartz API nativamente para o funcionamento deste emulador.
(Entretanto o suporte para X11.app ainda é mantido como opção caso ocorra problemas com o driver nativo.)
- O trabalho na emulação do Direct3D prosseguiu no último ano, destacando a implementação do próprio compilador de shaders e pipelines que pretende reduzir o overhead, e resolver alguns dos problemas de quebra de frame-rates em jogos exigentes graficamente.
- O trabalho na implementação do Directx 10 e 11 andou um bocado parado :rolleyes:, o que motivou a mobilização por parte da Codeweavers (que lança as versões comerciais do Wine com adições proprietárias) para que a equipa do Wine trabalha-se internamente na implementação do DirectX 11. O Directx 10 já uns 75% implementado, mas falta funções da interface para ser activado. Espera-se que na versão 1.8 já seja possível correr jogos DX10 e DX11, pois prevê-se que o DX9 seja gradualmente abandonado no próximo ano. (A vinda das novas consolas baseadas no DX11 vão estimular o abandono no antigo DX9).
- O Wine possui dois componentes autónomos: o Wine Internet Explorer (um wrapper MSHTML sobre o Gecko) e o Wine Mono (a implementação do .NET), que ainda não são suficientemente maduros para substituir a implementação nativa da Microsoft.
- Especula-se que uma terceira componente esteja na forja, que não é nada mais, nada menos que implementar o WinRT :wow:, habilitando a execução de Aplicações Metro pelo Wine. (evidentemente que não será pela Windows Store...)
Isto porque andaram a implementar as dll que surgiram com o Windows 8, e formam a base do WinRT (aparte do .NET que do qual é a linguagem padrão desta API)
- Também registaram correcções de bugs, completaram funções quebradas e deram continuidade a um projecto interno que estava ainda mais parado que o DX10 (que recomeçou ao cair do pano :D): o suporte a controladores nativos do Windows para certos dispositivos USB.
- Isto porque foi implementado no rc1 as primeiras funções relacionadas com o registo e instalação de controladores, que no Wine somente serão suportados controladores para dispositivos USB que operam no user-mode. (O Darling aparentemente suportará uma maior gama de controladores USB, visto que o IOKit é uma bibliotecas Unix-like e portanto mais fácil de sincronizar com o udev). Esta funcionalidade estará mais virada para dispositivos simples que são acompanhados com determinado software: como é o caso dos smartphones que utilizam software Windows para actualizar o seu firmware. (Não esperem que isso vá funcionar na versão 1.8!)
Em suma o lançamento do Wine 1.6 é mais uma versão de consolidação, mas com uma aposta clara para uma nova gama de dispositivos (os tablets Android e computadores ARM), e com o objectivo claro que preparar a versão oficial para o Mac OS X. :D