Wine 1.0?

Por: em 19/03/08 na(s) categoria(s): Software

comentários 54

 

Port_wine

 

Bem, eu não sei se alguém aqui também está surpreso, porém depois de ver um alfa com 12 anos de duração, eu esperava pelo menos mais uns 20 para o projeto chegar em sua versão 1.0.

Estava arrumando umas coisinhas em meu artigo sobre desenvolvimento, que por motivos de força maior está andando a passos bem lentos, quando resolvi entrar no WineHQ afim de pegar algumass informações recentes sobre o libwine e eis que para minha surpresa não só a versão 1.0 está com data marcada (6 de junho) como também a versão 1.1.0 logo em seguida, no dia 20!

Ok, nesses últimos 3 anos o wine evoluiu muito, saiu da versão 0.9.0 para a versão 0.9.57 (muito?!), e nesse ritmo pelo menos mais 3 anos me parecia um tempo bem aceitável para chegar na versão 1.0, levando em conta o nível de dificuldade do projeto.

Aparentemente, as últimas investidas do Google (money!) e as liberações de  especificações/documentações por parte da Microsoft deram um “UP” no Wine. As próximas 3 versões (28/03 – 11/04 – 25/04) serão os últimos betas, seguidos pela 1.0.0rc1 e 1.0.0rc2 em 9/05 e 23/05 respectivamente.

Menino do bucho grande diz: 15 anos de desenvolvimento? Depois dizem que o SL merece respeito!

Ok, o projeto Wine está aí há muitos anos e ainda vai precisar muito mais para rodar todas as aplicações do Windows (se é que realmente será possível rodar todas).

Então para quem não sabe, o Wine é um dos projetos mais malucos que existem por aí! Antes que digam besteira, vale lembrar que ele não emula nada! A idéia é traduzir as chamadas de Windows para Linux. Alguns falam que o Wine é pílula azul capaz de trazer os programas do mundo das chamas para o mundo da luz!

Já que Wine faz os programas Windows rodarem nativamente no Linux, é comum esperar muitos bug e não é por menos, o wine suporta programas escritos para Windows 2.0/3.0/3.1/NT 3.5/NT 4.0/ 95 / 98 / ME / 2000 / XP / 2003 / Vista / 2008 …

Ocupando pouco mais de 20MB, pessoalmente acredito que nem a MS teria feito algo tão otimizado assim e se lembrarmos que estamos falando de 21 anos de evolução em sistemas operacionais Windows, esses 15 anos do Wine nem parecem tanto não é?

Ok, o wine pode ser um projeto e tanto, mais nada comparado com o original!

 

O Wine não será um substituto para o Windows tão cedo, pelo menos no que diz respeito às aplicações. Porém o projeto vai muito além de “traduzir programas Windows em tempo real para rodar nativamente no Linux”. A biblioteca “libwine” pode ser usada para compilar e ligar códigos fonte de aplicações Windows nos *nix, ajudando e muito criar aplicações multiplataforma.

E o melhor: a libwine pode fazer com que aplicações Windows rodem no Windows! Maravilha né?

É muito comum algumas aplicações desenvolvidas para Windows 98 não serem compatíveis com o XP (por exemplo) e esse também é um dos focos da libwine, que pode ser usada normalmente no ambiente Windows para ajudar a portar o código entre as muitas versões do sistema.

Enfim, a lógica nos diz que o Wine sempre estará atrás dos sistema da MS, entretanto isso não o torna obsoleto. Algumas empresas, por exemplo, não precisariam adquirir um sistema operacional inteiro para rodar uma única aplicação win, ou reescrever milhares de linhas de código de sua aplicação para de rodá-la no novo sistema da Redmond.

O que esperar da versão 1.0?

Bem, a notícia triste é que a versão 1.0 não vai rodar todos os mais recentes aplicativos Windows e, muito provavelmente, nem o Adobe CS3. No entanto, o time de desenvolvimento espera que a versão CS2 rode com 100% de compatibilidade.

A grande idéia da versão 1.0 vai ser o congelamento e a estabilização dos muitos recursos, corrigir os últimos 103 bugs e finalmente lançar a primeira versão pronta para ser usada em diversos ambientes sem “medo” de que quando sair um novo relase tudo pare de funcionar.

A versão 1.0 pode não ser algo “tão incrível” para muitos, mais certamente será um marco  importante para o projeto, que agora poderá evoluir muito mais rapidamente e de maneira muito mais madura.

Mais textos de | Site | Twitter

  • http://www.allflexrepresentacoes.com.br/ rfnet

    Era tudo que os desenvolvedores precisavam para caminhar a passos mais largos : dinheiro e documentação!

    ______________________________________________________________
    Ixi ainda não pensei em uma assinatura ! hehehe

  • http://yawara.br.com Ubiratan.apo

    Agora vamos ver como ficam as versões comerciais, CrossOver e Cedega.

    Espero que isso dê algum impulso ao projeto DarWine que está meio parado.

    yawara.br além da tecnologia.

  • bluesball

    sempre vai estar atras do windows, corrigindo as mancadas dele…hehe

    com grana tudo fica mais fácil e rapido. e viva o google. :)

  • http://yawara.br.com Ubiratan.apo

    O único jeito do Wine não ficar atrás é a Microsoft assumir o desenvolvimento do Wine.

    Já pensaram? A Microsoft joga fora o Windows 7, assume o desenvolvimento do Wine e lança o Windows X com um kernel baseado em Linux!

    É mais ou menos o que a Apple fez com Mach Kernel e o BSD que acabou gerando o Darwin.

    Qual seria a principal fonte de receita da MS então? Continuaria sendo o MS Office como é hoje, mas rodando também em Linux, BSD, Solaris, OS X, etc…

    Sei que é pedir muito para a Microsoft, mas que seria legal seria. :)

    yawara.br além da tecnologia.

  • Weber

    Alguém pode me responder uma pergunta, bem básica? Se o Wine não emula o Windows, só traduz as chamadas do sistema, o que afinal de contas faz um emulador? :?

    • http://yawara.br.com Ubiratan.apo

      Um emulador simula uma máquina completa, processador, memória, HDs, etc… Por isso quando se usa um emulador é necessário que se instale uma cópida do sistema operacional desejado nessa máquina virtual.

      Resumindo com um emulador você tem o SO real rodando em uma máquina virtual, já com o Wine a situação é inversa, você tem um SO virtual rodando em uma máquina real.

      yawara.br além da tecnologia.

      • xzerorj

        Aí, foi mal, mas máquina virtual é uma coisa e emulador é outra. Máquina virtual você tem que instalar SO para ela funfar, já o emulador, ele funfa direto. A ROM que você aloca, no caso de emuladores de vídeo-games, é que precisa reconhecer o hardware/software para funfar, por isso utilizamos um emulador.

        Se o wine faz a tradução das chamadas do aplicativo hóspede para o sistema hospedeiro ele é de fato um emulador. Uma máquina virtual não traduz nada, pois ela na verdade mantem ambos os ambientes em separado.

        • http://www.fabiocardoso.com.br Fabião

          A máquina virtual traduz sim.
          Um vmware da vida recebe cada chamada de uma aplicação rodando no mesmo e a processa por uma camada de emulação, para só aí devolvê-la ao processador da máquina. Já o wine não: a resolução das chamadas dos aplicativos não é feita via emulação do processador, é feita nativamente, no caso do wine.

          Windows:

          Chamada da aplicação => Dll do windows => Kernel

          Wine:

          Chamada da aplicação => Dll do wine => Kernel

          Emulador de nintendo64:

          Chamada da aplicação => Emulador => Interpretação (ou recompilação) do código, que vira outra coisa => Kernel

          Como se um emulador “mastigasse”, processasse ele mesmo com seus algoritmos tal chamada, e devolvesse ela com outro aspecto. O wine só lê e entrega.

          • xzerorj

            Valeu pela explicação e muito obrigado pelas correções. Isso me ajudou muito.

            Mas que máquina virtual e emulador são coisas distintas, isso são mesmo!

          • http://www.fabiocardoso.com.br Fabião

            Ah são mesmo. Sâo conceitos distintos, aliás. Coisas completamente diferentes.

      • Weber

        Isso que vc descreveu como emulador, eu conheço como máquina virtual… :?
        Será que estou tão perdido assim?

        • xzerorj

          Então vamos combinar assim: Emulador = hardware e Máquina virtual = software OK?

          • Weber

            Ah, agora está claro! Valeu por esclarecer a minha dúvida.

  • xzerorj

    Em computação, um emulador é um software criado para essencialmente transcrever instruções de um processador alvo para o processador no qual ele está rodando. O emulador também é responsável pela simulação dos circuitos integrados ou chips do sistema de hardware em um software.

    Fonte: Wikipedia

    Em português claro, a definição acima me parece que é exatamente o que o wine faz, ou seja, ele é de fato um emulador. Claro que a Wikipedia pode estar errada, mas a afirmação do Wallacy ao dizer que wine não é emulador é um tanto confusa pra mim.

    • http://yawara.br.com Ubiratan.apo

      Um emulador virtualiza o hardware, você pode ver pela definição da Wikipedia eles falam em processadores, circuitos integrados e chips.

      O que o Wine faz é fazer ligações entre bibliotecas do sistema hospedeiro e o programa que está rodando, é mais um tradutor do que um emulador.

      yawara.br além da tecnologia.

      • http://melinka.net Rocky

        Gostei do termo tradutor, se encaixa perfeitamente para descrever o Vinhozinho….. ;)

        _____________________

        Muita Pimenta para sua vida!

        Primeiro Pro-Commenter da Blogosfera Brasileira.

        • Joao Lima

          Emulador: Os dispositivos fisicos sao criados via software e executam da mesma maneira do hardware real, ou seja, se eu pedir para escrever uma imagem na tela o
          emulador vai fazer os mesmos processos do hardware real para gerar a imagem.

          Simulador: Tem o mesmo objetivo do emulador, porem faz a tarefa de maneira diferente, pois em vez de criar todo o sistema via software, cria algum processo que executa as requisiçoes de maneira semelhante ao hardware real,mas entrega o mesmo resultado.

          Tradutor: Basicamente traduz as chamadas de um programa feito para alguma plataforma, para outra plataforma diferente em tempo de execução real, nao existe nada fazendo papel de hardware apenas um software gerando codigo de uma plataforma para outra, EX: WINE.

          Acho que isso ja basta para esclarecer as diferenças entre as tecnicas de emulaçao, existem outras como a para-virtualização que usa um meio termo entre tradutor e simulador, EX: WMware ESX entre outros.

      • xzerorj

        Nesse caso o wine está mais para o jvm do que para um emulador.

        Mas tem uma coisa que me parece contraditória: ele cria, para um programa windows um ambiente que distoa um pouco do linux, tipo, você está usando um word da vida, de repente tenta abrir um documento e o que você vê na janela? uma unidade “C”, com pastas na mesma hierarquia do windows.

        Sei lá, eu posso estar falando uma tremenda besteira, mas o comportamento do wine me sugere um emulador, ainda que o nome dele me diga o contrário

        • Wallacy

          Isso do "C:" etc, é por causa de algumas diferenças básicas de arquitetura de sistema. Não tem como saber que tipo de chamada de ambiente o programa está fazendo, digamos que o programa esteja tentando acessar o "C:", ou uma chave do registro… etc.. etc.. esse tipo de coisa não existe no ambiente Linux, logo essa parte é simulada, para evitar bugs…

          Imagina o programa esperar um retorno do tipo "C:\Windows\system32\" e ele retornar \lib\ ou outra pasta…. Não rola… Ou tentar acessar um dispositivo de audio (sei lá como), e o o Alsa devolver para o programa uma saida não compatível.. etc…

          Mais isso já é um nível um pouco mais alto, o wine ainda está só traduzindo o código….

          Esse tipo de coisa ai é só para evitar bugs, ele é um tradutor, isso é fato, porém só traduzir não basta, é necessário se adequar as estruturas do sistema para que a lógica que o programador criou permaneça intacta.

           

          —–
          No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
          Henry Wadsworth

    • shimatai

      Wine é uma sigla recursiva, muito comum no mundo GNU.

      WINE = Wine Is Not an Emulator

      Vale lembrar que o Wine não utiliza as DLLs do Windows (distribuidas pela Microsoft), a equipe de desenvolvimento reescreveu TODAS as chamadas nas DLLs, por causa de licença.

      –
      “Uma pessoa inteligente resolve um problema, um sábio o previne.” Albert Einstein

    • hamacker

      [quote=xzerorj]

      Em computação, um emulador é um software criado para essencialmente transcrever instruções de um processador alvo para o processador no qual ele está rodando. O emulador também é responsável pela simulação dos circuitos integrados ou chips do sistema de hardware em um software.

      Fonte: Wikipedia

      Em português claro, a definição acima me parece que é exatamente o que o wine faz, ou seja, ele é de fato um emulador. Claro que a Wikipedia pode estar errada, mas a afirmação do Wallacy ao dizer que wine não é emulador é um tanto confusa pra mim.

      [/quote]

      definitivamente não.
      Se a microsoft portasse a WIN32 API para Unix será que seria emulação ? Não.
      Existem dezenas de APIs que são multiplataforma, o problema é que a WIN32 não é.

      O WINE procura corrigir isso criando o que a microsoft recusa-se a fazer : uma WIN32 API para Unix. Visto que o WINE é feito por engenharia reversa e isso é um processo lento de tentativa e erro então fica explicado os 15 anos de desenvolvimento.

      Com a versão 1.0, voce pode criar uma aplicação windows que seja compátivel com o WINE e ele rodará também onde o wine for suportado, ou seja, Mac/Linux/Unix/BSDs e até mesmo no Windows como foi falado. Apenas programas que não são compátiveis com o WINE é que vão testar a sorte de garbage(não roda) até gold (roda 100%).

      –
      http://hamacker.wordpress.com

  • gjofili

    É uma notícia excelente. Eu uso Linux em 95% do tempo mas, de vez em quando, preciso rodar alguma coisa no Xp… se isso funcionar bem posso apagar o Xp :)

  • xultz

    Há pouco tempo atrás fizeram um benchmark, e algumas aplicações rodaram mais rápido no Wine que nativamente no Windows. É de se pensar…

  • http://www.techalien.net mestrealien

    Realmente, investimento $$$ é tudo, foi só o google dar uma mãozinha $$$ e o projeto decolou.

    TechAlien.Net

  • avontz

    Eu não fui muito feliz ao usar wine junto com unbutu.. precisava fazer um trampo e tinha que instalar o photoshop cs2…

    Sonho meu…rs

    *******************************

    Música eletrônica + atitude -> sabotagem.org

  • Pessoa

    Eu só espero que eles não tenham usado a documentação da Microsoft para isso. As entidades envolvidas com o FOSS estão recomendando que não se use a documentação por possíveis problemas jurídicos com a empresa, pois a licença não é compatível com software de código aberto. E não estou falando de Richard Stallman e sim de pessoas sérias que realmente se preocupam com a viabilidade do código aberto no mercado.

    –
    “A imaginação é mais importante que o conhecimento.”
    – Albert Einstein

    • Wallacy

      É justamente por isso que o projeto andava muito devagar.
      Eles estão criando tudo do zero, eles mesmo alertam no site deles que o projeto é 100% não Microsoft!!

      —–
      No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
      Henry Wadsworth

      • http://www.fabiocardoso.com.br Fabião

        Criaram tudo do zero é ingenuidade.

        Eu (leia-se EU) penso que bastante deste código do wine ai foi feito na base da engenharia reversa mesmo.

        E eu não falo em olhar o que o windows faz e repetir não.

        Óbvio que ninguém jamais terá provas disso, mas, é meio evidente.

        • Wallacy

          Sim, claro….

          Eu me referi ao código bruto, “criar do zero” é um dos efeitos da engenharia reversa, se obter a logica, mais não o código, dai eles recriam o código.

          Dai, mistura um pouco com códigos públicos, mais um pouco com algumas coisas tiradas de algumas especificações dos próprios compiladores, etc.. etc.. E pronto, “ninguém jamais terá provas disso”.

          A idéia mesmo do “100% não MS” é não ter usado “diretamente” nada que a MS disponibilizou…

          —–
          No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
          Henry Wadsworth

      • Pessoa

        Sei que o Wine cria tudo do zero por não ter acesso aos fontes do Windows. Estava me referindo a sua declaração sobre o uso da documentação liberada pela Microsoft no desenvovimento do Wine:

        “Aparentemente, as últimas investidas do Google (money!) e as liberações de especificações/documentações por parte da Microsoft deram um “UP” no Wine.”

        –
        “A imaginação é mais importante que o conhecimento.”
        – Albert Einstein

  • http://vinicius.soylocoporti.org.br viniciusandre

    Evolução numérica de versão não quer dizer nada. Isso é somente referência dos desenvolvedores, e não sinônimo de código acumulado.

    http://vinicius.soylocoporti.org.br

    • Wallacy

      Isso é fato, mais dizer que um projeto vai deixar de ser beta não deve significar alguma coisa não é?

      —–
      No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
      Henry Wadsworth

      • http://vinicius.soylocoporti.org.br viniciusandre

        Também não, ué. Quem sente a maturidade do código e dificuldade dos bugs também são os desenvolvedores. Deixar de ser beta é uma noção dos desenvolvedores para com o programa em relação à sua utilização.

        http://vinicius.soylocoporti.org.br

  • Donnie Darko

    Ai, sim, seria o X WindowS heheheh

  • Tonny

    Só pra constar: Os feeds tão com problema, acho, na acentuação, e não é o meu charset.

  • Donnie Darko

    Alguém sabe se o iTunes (versão corrente) roda legal sobre o Wine?

    • http://www.tiueice.com AceKiller

      Se não me engano o Wine-doors já tem um script de instalação dele, mas eu confirmo logo a noite, se não tiver, eu posto uma errata ;)

  • guedesav

    Bom, pelo menos ele chegou na versão 1.0 algum dia… isso é bom sinal.

    Aproveitando a carona, alguém mais bem informado sobre o projeto sabe a quantas anda a questão do DirectX no wine?

    Bruno Guedes
    — Toupeira Profissional
    — Universitário
    — Bloguista
    “Boa Noite e Boa Sorte” (Edward R. Murrow)

    • Wallacy

      Direct3D 8 e 9 estão em 95%
      DirectDraw está em 95%
      DirectInput 75%

      São os mais “completos”.

      Porém boa parte dos componentes do DirectX está em 5%. Isso é claro para os clones, pois a instalação do DirectX pode ser feita normalmente no Wine.

      —–
      No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
      Henry Wadsworth

      • http://www.fabiocardoso.com.br Fabião

        Feito o D3D, o DDraw e o DInput, falta o que, o DSound ?

        Logo, porque temos aqueles montes de problemas de renderização em jogos rodando pelo Wine ?

        Deixando claro que são chamadas do DX, logo, o kernel do windows não tem muita participação nisso.

        • hamacker

          Nem tudo é só DX.
          Provavelmente o jogo carrega outras funções não presentes no DX, mas na WIN32 ou suas próprias bibliotecas que estejam “melando” o processo.

          Se fosse possível instalar o windows dentro do WINE provavelmente não teria problema com todas as bibliotecas nativas, porém não teria nenhum beneficio plausível para isso.

          • http://www.fabiocardoso.com.br Fabião

            Eu ainda acho que há problemas no wine com relação as chamadas Dx, que, a meu ver, não estão em 95% como o pessoal do wine quer insinuar.

            Talvez 95% de um objetivo interno, mas não 95% de uma conversão perfeita.

          • Wallacy

            Tem muita coisa faltando, dê uma olhada: Link

            O DirectShow por exemplo tem praticamente só 50%.

            E mesmo assim, o maior vilão dos jogos via Wine nem é o directx, pois da para instalar o DirectX completo no Wine.
            O problema são as chamadas da API do Windows que bugam tudo. Um POG aqui, outro ali, e um itenzinho que não funciona direito deixa tudo bugado.

            —–
            No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
            Henry Wadsworth

          • hamacker

            Pois é, mas no caso acima ele instalou o DX no wine, portanto taria usando o DX nativo e não as fakes-bibliotecas do wine.

          • http://www.fabiocardoso.com.br Fabião

            E como fica a questão do EULA do Directx se instalado no wine ?

            Mais do que o fato de tal programa rodar no wine, tem que verificar se você é legalmente apto a rodá-lo no mesmo.

            Eu não sei se é ou se não é, estou conjecturando. Porém, muito provável que não seja.

          • hamacker

            O problema desse método de instalar programas autonomos do windows é justamente barrar nas licenças. No caso específico do DX, quando se tenta fazer o download está o aviso :
            Este download está disponível para clientes que executam Microsoft Windows autêntico. Clique no botão Continuar para iniciar a validação do Windows. Conforme descrito em nossa declaração de privacidade, a Microsoft não usará as informações coletadas durante a validação para identificá-lo ou contatá-lo.

            No entanto, o mesmo não vale para runtimes como o vb, vc e cia.

            Falando sobre o EULA, alguns a ignoram porque ela simplesmente não tem validade jurídica aqui no Brasil, ou mesmo, qualquer lugar fora do EUA. As intrigas que o EUA tem com a chamada “aliança do mal” é problema deles, mesmo que lá esteja dito que não há garantia se rasgar o invólucro, aqui a garantia é obrigatória e as vezes solidária. A única vez que ví o EULA valer foi no caso da EMBRAER que ficou impedida de vender aviões para a Venezuela por conta dos firmwares americanos, mas aí provavelmente não era um EULA trivial.

            Um tempo atrás foi noticiado que o programa de validação do Windows soltava a pérola de que o WINE era um Windows autentico. Muito hilário…

          • Wallacy

            O Wine-Doors pergunta se você tem Windows Original ou não… Realmente hilário.

            Podiam usar um verificador de chaves… O pessoal que faz os keygen sabe como é a sequência correta :)

            —–
            No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
            Henry Wadsworth

          • Wallacy

            Ele falou dos “95%” e esses são referentes aos clones, por isso mostrei o link…

            E esses clones só existem por causa do problema da EULA que você colou…

            A ideia era falar que o problema dos jogos, geralmente é por causa de problemas na API Windows incompleta, não do Directx, até porque essas APIs precisam suportar o Directx corretamente (mesmo que completo).

            —–
            No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
            Henry Wadsworth

          • http://www.fabiocardoso.com.br Fabião

            Porquê eu discordo de vocês:

            Porque, a vocação, o propósito mor do D3d, por exemplo, é evitar ao máximo as chamadas pelo hardware da API do windows, e vice versa. A intenção é a comunicação direta e reta do jogo com a VGA, por comandos simples e linguagem própria.

            Eu já ví jogos com problemas sérios na implementação de pixel shader no wine: Posso citar exemplos, inclusive: Oblivion. E, pixel shader não necessita de qualquer API do windows ou do jogo para rodar, é diretamente escrito em HLSL e “compilado” para a devida plataforma gráfica que a placa de vídeo produz; Logo, é exclusivamente responsabilidade do DirectX.

            Para tais erros ocorrerem, é fato que deva haver algo errado com a implementação do DX, porque é praticamente só esta parte da API que está entre a VGA e o jogo. E de fato estão:

            Some SM 3.0 features are still missing. Instancing is now in, vertex textures and some other stuff still missing. Not widely used among games yet.

            Pelo que vejo, o conceito de “not widely used” não me parece muito correto. E, além de lidar com a falta de vertex texturing, quero ver a hora que o povo do wine descobrir que a ATI usa gambiarra para implementar tal coisa em suas placas.

          • Wallacy

            É uma dificuldade que o wine tem para implementar as chamadas do DirectX. É isso que to falando. O DirectX em sí, está lá fazendo seu trabalho, mais o wine não deixa ele comunicar corretamente com a VGA, tem muito problema de sincronia com X, e algumas instruções conflitam como até com o modo openGL nativo.
            Quando o WineCore melhorar, vai ter um suporte melhor ao DirectX, e com certeza quando os clones melhorarem, também já que o pessoal da WineHQ vão saber melhor lidar com esse tipo de dado.
            Veja que querendo ou não, o DirectX está sobre o sistema, e no Windows ele pode até agir sem intermédio da API Windows, mais não que dizer que na implementação “Linux” não está agindo sobre a API Linux. Existe algumas diferenças no “acesso direto ao hardware” entre os sistemas, e muito provavelmente é esse o caso.

            O que eu quis dizer é que fisicamente o DirectX (depois de instalado) está completo no Wine, porém o “sistema” (winecore + linux) não deixa ele agir corretamente. O DirectX é como um “programa”, e é feito nos moldes “Windows” e esses “moldes” ainda não são completamente suportados pelo Wine. Ele pode tentar acessar diretamente a VGA quantas vezes quiser, mais sem o suporte adequado dos outros componentes do Wine, ele não vai funcionar direito.

            —–
            No caráter, na conduta, no estilo, em todas as coisas, a simplicidade é a suprema virtude.
            Henry Wadsworth

          • http://www.fabiocardoso.com.br Fabião

            Então, simples: Por mais que o pessoal do wine proclame que o directX está “95%”, na realidade está bem longe disso, levando-se em conta o todo.

            Eles realmente imaginam que, até junho/julho, vão resolver todos estes problemas de forma satisfatória, e nós teremos Crysis rodando perfeitamente no Linux?

            Se não, “1.0″ vira “numeração de desenvolvedor” mesmo.

  • Ricardo Bicalho

    Eu costumo chamar o Wine de um mapeador ou tradutor da Win32 API para Linux.

  • marck

    Realmente é impressionante o que o pessoal do Wine tem feito. Engenharia reversa não é uma ciência exata e deve dar um trabalhão.
    Para quem se interessar em saber o que é suportado pelo wine ( estão separados por categorias de programas) : http://appdb.winehq.org/appbrowse.php