Wine - Tópico Geral

WINE 1.1.0 out :)

The Wine development release 1.1.0 is now available.

What's new in this release (see below for details):
- Many more gdiplus functions implemented.
- Improved graphics tablet support.
- Many Richedit fixes and improvements.
- Support for HWND_MESSAGE windows.
- A lot of new MSHTML functions.
- Many fixes in MSI registry handling.
- Initial implementation of the inetmib1 DLL.
- Improvements to the quartz renderers.
- Various bug fixes.

http://www.winehq.org/?announce=1.1.0
 
WINE 1.1.1 Released, New Improvements


It was two weeks ago that WINE 1.1.0 was released as the first development version since WINE 1.0 was released. In their usual timed released cycles, WINE 1.1.1 is now out today. WINE 1.1.1 features installer fixes for Adobe Photoshop CS3 and Microsoft Office 2007, more progress on the gdiplus functionality, Unicode file support in regedit, improved video playback, and Richedit fixes and improvements. In addition, there are a number of other miscellaneous bug-fixes in this second post-1.0 development release. The release announcement and full change-log for WINE 1.1.1 can be viewed at WINE HQ. Meanwhile, for users interested in the stable releases, WINE 1.0.1 is next on their road-map and that should be out by the end of next month.

fonte
 
WINE 1.1.2 Released, New Features


WINE 1.0.1 still hasn't been released in the stable branch, but the WINE 1.2 development branch is coming along nicely. WINE 1.1.2 is the latest development release and it incorporates control panel improvements, new appwiz (application wizard) panel, restructurations of state handling in Direct3D, support for timer queue functions, many MSXML improvements, Solaris support fixes, and various bug fixes. The release announcement for WINE 1.1.2 can be read at WINE HQ.
Fonte
 
E pumba, cá temos a 1.1.3 :)

The Wine development release 1.1.3 is now available.
What's new in this release:

  • Beginnings of ddraw overlay support.
  • Many more crypt32 functions.
  • Improved support for tables in Richedit.
  • Support for NETWM window maximization.
  • Many installer fixes.
  • Tweaks for better PulseAudio support.
  • Various bug fixes.
The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.

via WineHQ
 
E a 1.1.4!

The Wine development release 1.1.4 is now available.

What's new in this release (see below for details):
- Substantial chunks of WinHTTP are implemented.
- More JavaScript support.
- Beginnings of shell AppBar implementation.
- Several fixes for Google Chrome support.
- Chinese translations.
- Various bug fixes.

via WineHQ
 
The developers behind WINE are out with their bi-weekly development update to this popular open-source project. Added in this latest WINE 1.1.22 release are improvements to OLE copy/paste functionality, the start of x86_64 exception handling support, Direct3D locking fixes, ARB shaders improvements, and better OpenGL pixel format support. Like usual, there are also a variety of bug fixes contained in this latest release.

Via WineHQ.org.
 
Wine 1.1.30

A comunidade do Wine resolveu lançar a versão 1.1.30 deste poderoso software. Para quem não sabe, o Wine é uma implementação open source que permite executar programas do Windows em sistemas operativos baseados em UNIX (Linux, BSD’s, etc).
Novidades neste lançamento:

  • Suporte para OpenAL
  • Vários melhoramentos no suporte a HTML e JavaScript
  • Vários melhoramentos e correcções nos controlos comuns
  • Algum trabalho envolvendo Direct3D 10
  • Suporte a MAPI melhorado
  • Várias correcções de bugs
Poderá descarregar o Wine 1.1.30 aqui como também pode aceder directamente ao repositório GIT. Acrescento que ainda pode consultar a documentação do Wine caso tenha alguma dúvida na zona de documentação do WineHQ. Mais informações sobre este lançamento podem ser visualizadas no comunicado oficial.
 
Wine 1.1.32

do Peopleware de Vítor M.
Wine (acrónimo para WINE Is Not an Emulator) é um projecto para sistemas operativos UNIX que permite executar nesse ambiente software especificamente concebido para o Microsoft Windows.

O WINE funciona como uma camada (semelhante a um emulador) que expõe uma API compatível com a do Windows; ao serem executadas as diferentes funções, o Wine irá traduzi-las para rotinas em UNIX cujo resultado seja idêntico. Diz-nos também a Wikipedia que o Wine ainda disponibiliza a sua própria biblioteca (Winelib) por forma a que o código-fonte dos programas concebidos para Windows possa ser compilado no ambiente UNIX.
Alterações no Wine 1.1.32:


  • Algumas correcções na encriptação, principalmente no sistema a 64-bit.
  • Melhorado o acesso DVD no Mac OS.
  • Vários comandos comuns foram melhorados.
  • Vários suportes para HTML foram melhorados.
  • Mais optimizações DIB.
  • Vários bugs corrigidos.
ico_01.jpg
Licença: GPL
ico_02.jpg
Sistemas operativos: Linux
ico_03.jpg
Download: Wine 1.1.32 [15.13MB]
ico_04.jpg
Homepage: Wine
Fonte
 
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 ! :-D

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 :-D)
- 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 ? :002:

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! :-D )
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 :002: que terá que ser implementados pelo Wine Mono para fechar estes "pequenos" buracos. :joker:
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. :-D (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! :002:
 
Era fantástico se com o novo Wine o meu Photoshop não bloqueasse quando tento abrir ficheiros *.PSD. Este é o único motivo pelo qual ainda visito o Windows, embora nem sequer seja nos meus computadores, não quero cá nada disso. :P
 
As boas notícias é que no Wine 1.4 o Photoshop CS5 instala e corre sem problemas (na verdade já corria desde o lançamento, mas exigia usar ferramentas de terceiros para instalar o programa! :002: ).
Mas o que pode provocar instabilidades são essencialmente os drivers de vídeo mal implementados, uma má distribuição Linux que provoca quebras durante a execução, ou o próprio Wineprefix já estar podre.
Para os mais audaciosos, é possível instalar o wrapper do CUDA e permitir a aceleração computacional destas placas NVidia para correr o Photoshop CS5, mas não tenho experiência neste aspecto.

Resumindo, com um computador decente (4 Gb de RAM e uma placa de vídeo com 512 Mb ou mais que seja ATI ou NVidia, recomendando a última caso queira usar a CUDA) e uma cópia do Photoshop CS5 são os requisitos para correr o Photoshop CS5 no Wine.

Mas para ser mais sincero vou dizer alguns dos jogos Windows que instalei e corri na minha máquina Linux Ubuntu 10.04 :) com uma placa NVidia GT440, 4 Gb de RAM e um processador Pentium D a 3,4 GHz (os primeiros dual-core do mercado :-D), o que é uma máquina relativamente razoável.
Apesar de tudo, só joguei pessoalmente alguns deles, uma vez que foi um familiar meu que quis testar o sistema e trocar os saves com um computador Windows que tinha. :002:

Half-Life 1, Half-Life 2, HL2: Episode 1 e 2 (tudo completo com as definições todas no máximo!)
Assassin's Creed, AC 2, AC2 Brotherhood (O framerate tendia a oscilar um bocado consoante a quantidade de objectos renderizados no ecrã)
Age of Empires 1,2,3 incluindo expansões.
Football Manager 2007,08,09,10,11 (cortesia do meu familiar que prefere mais o 2007)
GTA 3, VIce City, San Andreas, 4 (mas não experimentei muito a fundo, visto que só no Wine 1.4 e com o Update 7 é que o GTA4 é finalmente jogável pelo Wine!)
Rome Total War e Medieval II Total War (estes ora tinham uns bugs aqui e acolá)
Witcher II (só para testar, mas o jogo é muito complexo. Deve-se evitar instalar patches que exigem o .NET 4.0 visto o Wine não suporta esta versão condignamente!)
E mais uns quantos que não recordo por enquanto... :002:
 
Última edição:
Arucard visto que pelos vistos percebes do wine coisa que eu nem por isso, poderias me dizer se há maneira de instalar a steam + cs 1.6 funcional ?

já tentei dezenas de vezes em varias distros, com várias versões de distros sem sucesso, ficava sempre com erros.
Até cheguei a tentar com o crossover e resultados iguais :wow:

cumps
 
Acho isso estranho, sempre que instalo o steam e qualquer jogo de lá, uso como se estive-se no windows. Duplo click no icon para instalar, e dentro do steam o mesmo que faria no windows tb.
 
Desconfio que o problema seja apenas este: falta de drivers para a placa gráfica.
Se a máquina tiver uma placa gráfica Intel é preciso uma sacrossanta paciência para conseguir correr um jogo que exige aceleração 3D. :mad:

Se for ATI ou NVidia terás que instalar os drivers proprietários, e as distros contêm informação para a instalação.
Mas se for uma placa ATI anterior à X1600 (se não for ainda pior), a AMD descontinuou o suporte para placas consideradas obsoletas (isto é, antes da era DirectX 10 ! :mad:) desde 2009, e a única forma seria confiar nos drivers open-source que vão se tornando uma alternativa para placas antigas, no entanto exigem recursos das placas que não são utilizados, embora com o novo driver Gallium 3D já conseguia correr os jogos antigos que exigem o DirectX8/9, desde que aplique resoluções baixas para ser minimamente utilizável.

As versões antigas do Counter-Strike até correm com os drivers open-source da ATI ! (mas com vários problemas)
Por experiência minha, até resolvi um problema de lentidão do cs 1.6 com uma máquina Ubuntu que foi resolvida trocando a definição de áudio referente à aceleração de hardware, ao desmarcar a opção de emulação. :-D

Quanto ao Wine, eu esqueci de outra novidade: o suporte nativo para correr aplicações que usem outros sistemas de caracteres. Existe um utilitário que efectuava a mudança do parâmetro locale para a aplicação em questão.
Agora basta instalar os locales e as fontes para funcionar.
e acrescentar o parâmetro: LC_ALL=locale wine prog.exe
como tenho alguns jogos yaoi japoneses, isto funcionou às mil maravilhas...
 
Quanto ao Office 2010, a classificação encontra-se em Silver, mas é recomendado usar uma ferramenta como o PlayonLinux para o instalar num wineprefix em separado!
O Office 2010 só instala e funciona minimamente com o modo Windows 7, e o célebre programa de instalação requer a instalação prévia do .NET 2.0.
Por agora, a não ser que queiram mesmo instalar os programas do Office no Linux fiquem ainda pela versão 2007 do qual funciona melhor, uma vez que na versão 1.4-rc1 o Word, Excel e Powerpoint 2010 ainda tem problemas de estabilidade. (Já dá para correr macros, escrever algum texto e inserir figuras, mas a aplicação pode falhar ao fim de alguns minutos de uso ou não) :p
 
Back
Topo