Wine 11 reescreve em nível de kernel a forma como o Linux executa jogos de Windows e alcança grandes ganhos de desempenho

• A arquitetura de execução de jogos de Windows no Linux foi totalmente redesenhada em nível de kernel, eliminando os gargalos de sincronização baseados no wineserver
• O novo driver NTSYNC processa objetos de sincronização NT diretamente no kernel e registrou ganhos de FPS de até mais de 8x
• Com a conclusão do WoW64, agora é possível executar apps Windows de 32 bits em Linux 64 bits sem bibliotecas separadas
• Driver Wayland aprimorado, suporte a Vulkan 1.4, melhorias em Bluetooth e force feedback e ampliação da compatibilidade em gráficos e E/S
• Os efeitos de melhoria de desempenho e estabilidade se espalham por todo o ecossistema baseado em Wine, incluindo Proton, SteamOS e Lutris

---

Principais mudanças no Wine 11

• O Wine 11 não é apenas uma atualização anual simples, mas uma grande reformulação que reescreve em nível de kernel a forma como o Linux executa jogos de Windows

  • Além de anos de correções de bugs acumuladas e melhorias de desempenho, inclui mudanças estruturais como suporte a NTSYNC, conclusão do WoW64 e fortalecimento do driver Wayland
  • Os ganhos de desempenho se espalham por projetos baseados em Wine como Proton e SteamOS

Limitações anteriores e soluções temporárias

• No passado, o Wine não conseguia implementar perfeitamente no Linux as primitivas de sincronização NT do Windows (mutex, semaphore, event etc.)
  • Para sincronizar entre threads, era necessário fazer chamadas RPC ao wineserver repetidamente, e milhares de chamadas por segundo causavam atraso nos frames e temporização irregular
• O Esync reduzia as chamadas ao wineserver usando eventfd, mas esbarrava em problemas de limite de descritores de arquivo
• O Fsync é mais rápido por ser baseado em futex, mas exige patches fora do kernel principal, o que dificulta seu uso em distribuições comuns
  • O futex_waitv do Linux 5.16 é diferente do protótipo do Fsync e não é um substituto completo
• Ambas as abordagens eram soluções temporárias, e certas APIs NT (por exemplo, NtPulseEvent e o modo wait-for-all de NtWaitForMultipleObjects) não podiam ser implementadas com precisão

NTSYNC — redesenho da sincronização em nível de kernel

• O NTSYNC adiciona ao kernel Linux um novo driver de dispositivo /dev/ntsync para modelar diretamente objetos de sincronização Windows NT
  • A sincronização passa a ser tratada dentro do kernel, e as idas e vindas ao wineserver são eliminadas
  • Gerenciamento de filas, semântica de eventos e operações atômicas passam a ser executados diretamente pelo kernel
• A desenvolvedora é Elizabeth Figura, criadora do Esync e do Fsync, e o recurso foi apresentado na Linux Plumbers Conference de 2023 antes de ser integrado ao Linux 6.14

• Números de melhoria de desempenho

  • Dirt 3: 110.6 → 860.7 FPS (melhoria de 678%)
  • Resident Evil 2: 26 → 77 FPS
  • Call of Juarez: 99.8 → 224.1 FPS
  • Tiny Tina’s Wonderlands: 130 → 360 FPS
  • Call of Duty: Black Ops I ficou totalmente jogável

• Diferenças em relação ao fsync

  • Para usuários de fsync, os ganhos são mais limitados, mas em jogos com gargalos multithread a melhora é dramática
  • Como está incluído no kernel principal, não são necessários patches separados, e ele pode ser usado imediatamente em distribuições recentes como Fedora 42 e Ubuntu 25.04
  • Vem ativado por padrão no SteamOS 3.7.20 beta e também está habilitado no Proton GE
  • O NTSYNC é o primeiro caso na história do Wine a alcançar uma implementação precisa de sincronização em nível de kernel

WoW64 concluído — integração da compatibilidade com 32 bits

• A implementação da arquitetura WoW64 (Windows 32-bit on Windows 64-bit) foi concluída no Wine 11
  • Em sistemas Linux de 64 bits, não é mais necessário instalar bibliotecas separadas de 32 bits para executar apps Windows de 32 bits
  • Um único binário detecta automaticamente a arquitetura do executável e o processa
• Inclui mapeamento de memória OpenGL, passthrough SCSI e até suporte a aplicativos de 16 bits
  • Isso permite executar também softwares antigos do Windows dos anos 1990
• Antes, diferenças na configuração de multilib entre distribuições dificultavam a execução, mas agora o Wine lida com isso internamente

Wayland e outras melhorias importantes

• Driver Wayland

  • Cópia bidirecional pela área de transferência, suporte a arrastar e soltar e escala do compositor ao trocar de resolução melhoram a compatibilidade com jogos antigos
  • A maior parte dos problemas de compatibilidade do Wine na transição de X11 para Wayland foi resolvida

• Gráficos e mídia

  • No X11, o EGL passa a ser o backend padrão do OpenGL, substituindo o GLX
  • Adicionado suporte a Vulkan 1.4 e decodificação com aceleração de hardware H.264 baseada em Vulkan Video

• E/S e periféricos

  • Melhorias em force feedback ampliam o suporte a volantes de corrida e flight sticks

  • Suporte a serviços Bluetooth BLE e pareamento**,** além de melhorias no processamento de soundfonts MIDI

    • Adicionados compressão Zip64, Unicode 17.0.0, digitalização TWAIN 2.0 (64 bits) e ping IPv6

• Desempenho e expansão de plataformas

  • Melhor gerenciamento de prioridade de threads em Linux e macOS, com ganhos de desempenho multithread
  • Suporte à simulação de páginas de 4K em ARM64, ampliando a compatibilidade com dispositivos Linux baseados em ARM

Compatibilidade com jogos e correções de bugs

• Melhorias de compatibilidade para títulos importantes como Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI e Battle.net
• Centenas de correções de bugs foram incluídas, melhorando a estabilidade e o desempenho gerais

Avaliação geral

• Combinando NTSYNC, conclusão do WoW64, melhorias no Wayland e grande volume de correções de bugs, o Wine 11 é o lançamento mais importante desde o Proton
• O desempenho e a compatibilidade melhoram em todos os projetos baseados em Wine, como Proton, Lutris e Bottles
• Para quem joga no Linux, o Wine 11 é uma versão que definitivamente vale a pena experimentar

[kh0324]

No fim, isso vai acabar dando em compatibilidade retroativa quebrada de novo para vários anos de jogos antigos..

Parece que é uma troca equivalente mesmo

[GN⁺]

Comentários do Hacker News

• Tenho um respeito quase infinito pelo projeto Wine
  Passar 30 anos tentando reproduzir exatamente o comportamento documentado e não documentado do Windows parece um trabalho tedioso e pouco recompensador, mas foi isso que fez o Wine se tornar um produto realmente útil
  Especialmente quando vejo jogos antigos rodando melhor do que no Windows, dá para sentir o nível de atenção aos detalhes e a tolerância ao sofrimento envolvidos

  • Antigamente eu evitava jogar no Linux porque achava que não tinha como o Wine funcionar direito
    Às vezes eu testava algum jogo simples e pensava “ué, isso funciona?”, mas não achava que fosse algo confiável
    Hoje admito que esse julgamento estava completamente errado
  • Apesar de ser um projeto realmente excelente, é uma pena que aplicativos corporativos como Word, Excel e Outlook ainda não funcionem tão bem
    Dizem que o Excel 2010 foi a última versão a receber classificação Platinum
    É interessante pensar por que esse tipo de app é mais difícil do que jogos
  • O Wine executa automaticamente testes de compatibilidade em várias plataformas
    Se você olhar a página de resultados de teste, dá para ver que essa verificação sistemática é a chave para alcançar alta compatibilidade
  • O ReactOS também merece ser mencionado
    Muito do conhecimento obtido naquele projeto acabou fluindo para o desenvolvimento do Wine
  • Quando eu usava OS/2 nos anos 90, para rodar aplicativos do Windows era preciso iniciar o Windows inteiro
    Na época eu queria construir algo como o Wine por conta própria, mas não tinha conhecimento suficiente
    Hoje só uso Linux para servidor, então não tenho utilidade para isso, e ouvi dizer que também existe Wine para Mac, mas não tenho nenhum aplicativo de Windows que eu realmente queira rodar

• Fiquei impressionado ao ver o quanto os frames dos jogos subiram graças ao Proton
  Dirt 3 passando de 110FPS para 860FPS, e Resident Evil 2 de 26FPS para 77FPS, é difícil de acreditar
  Acho que isso só aconteceu porque a Valve despejou muito dinheiro nisso

  • Mas esses números comparam Wine+ntsync com a versão padrão do Wine, então há um certo exagero
    Se comparar com o Wine anterior baseado em fsync, o ganho fica na faixa de alguns poucos por cento
    Ainda assim, o ntsync é claramente uma melhoria
    Pela documentação do ntsync, trata-se de um driver de kernel para implementar com mais precisão no Linux as estruturas de sincronização do Windows
  • Também é preciso notar que a comparação é “quando não se usa esync ou fsync”
  • Tenho curiosidade sobre a relação entre Proton e Wine — o Proton é só o nome usado para Valve/SteamOS ou é um projeto separado?

• Também houve quem dissesse para não se empolgar demais com os ganhos de desempenho do ntsync
  Na maioria dos casos, o ganho fica em porcentagens de um dígito, e alguns jogos podem até ficar um pouco mais lentos

  • Para quem usa um kernel sem patch de fsync, a história pode ser diferente
  • Também surgiu a sugestão de comparar a diferença de desempenho entre Wayland e X11

• Quando vejo esse tipo de assunto técnico de baixo nível, sinto vergonha de só fazer aplicativos CRUD

  • Mas CRUD também tem valor e faz bem para a saúde mental
    Já ouvi a história de um desenvolvedor genial que sofreu com cronogramas extremos e acabou migrando para um trabalho simples de CRUD em VB, dizendo que parecia “férias remuneradas”
  • Eu também ajudo com coisas simples no Outlook, tipo “clique aqui, clique ali”, mas esse tipo de trabalho também é essencial
  • Por outro lado, dizem que desenvolvedores de baixo nível também sentem que lhes falta habilidade quando precisam lidar com sistemas de alto nível
  • Até eu, que faço compiladores, tentei várias vezes criar um app CRUD para projeto pessoal e fracassei
    Já tentei Rails, Phoenix e Django, mas não foi fácil
    Recentemente tive algum progresso com a ajuda do Claude
  • Aplicativos CRUD também não são tão simples assim
    Os requisitos corporativos são complexos, então a arquitetura pode desmoronar facilmente

• Fico feliz de saber que os milhares de dólares que gastei na Valve acabaram sendo usados para melhorar o Wine
  Tenho curiosidade sobre quantos desenvolvedores e contratados a Valve empregou nisso

  • Dois terços dos desenvolvedores do Wine pertencem à CodeWeavers e têm contrato com a Valve e o Proton
    Ou seja, a maior parte do financiamento vai para lá

• Paradoxalmente, o Wine pode ser autodestrutivo
  Se os jogos rodarem bem no Linux, os desenvolvedores podem simplesmente fazer ports nativos para Linux, e o Wine pode deixar de ser necessário

  • Mas como a API do Wine é mais estável do que a do Linux, o Wine pode acabar se tornando um alvo de primeira classe
  • Na prática, acho que acontece o oposto
    Mesmo quando existe um port nativo, muitas vezes é mais estável rodar a versão Windows via Proton
    A API do Windows é familiar e não muda, então os desenvolvedores continuam usando ela como referência principal
  • Hoje em dia, “suporte a Linux” basicamente significa rodar bem no Proton
  • Acho que esse tipo de situação é um “bom problema”
  • Além disso, o Wine é usado para muitas outras coisas além de jogos, então mesmo que os ports nativos aumentem, a demanda continuará existindo
    Como o ABI do Windows ainda é mais estável, manter só o build de Windows continua sendo eficiente, desde que a diferença de desempenho seja mínima

• Houve uma pergunta sobre não ser possível implementar o ntsync em espaço de usuário com memória compartilhada
  O Claude explicou que, como para “95% dos jogos” uma abordagem simples já bastava, não houve motivação para implementar uma lógica complexa de memória compartilhada, e quando a precisão passou a importar, tornou-se natural colocá-la no kernel

  • Mas na prática isso é impossível porque o Linux não oferece esse tipo de funcionalidade em espaço de usuário
    O ntsync não é só um wrapper de API, mas um adaptador em nível de kernel que reproduz o comportamento de sincronização do kernel NT
    Pelo código-fonte, ele se integra intimamente ao agendador do kernel
  • A documentação do kernel também afirma claramente que “uma implementação em espaço de usuário não consegue atingir o desempenho e a precisão do Windows”
    Link da documentação

• É impressionante ver o Linux reimplementar o Windows e ainda fazer melhor
  Em um momento em que a Microsoft torna seu próprio software cada vez mais incômodo, esse tipo de conquista é notável

  • Em especial, é muito significativo que o Wine mantenha o suporte a 16 bits que desapareceu no Windows 64 bits
    Muitos jogos antigos são baseados em 16 bits, e mesmo jogos de 32 bits muitas vezes têm instaladores de 16 bits

• Se algum desenvolvedor do Wine vir este post, seria ótimo se fizesse uma palestra sobre isso na Carolina Code Conference 2026
  A chamada para palestrantes vai até 31 de março

• Se você quiser a mesma coisa no macOS, pode contribuir com este repositório

  • Mas, sinceramente, existem pouquíssimos jogos para MacOS, então provavelmente quase não há desenvolvedores interessados
    Tenho lembranças de jogar o jogo de tanques Bolo nos Macs da escola antigamente, mas deve haver menos de 1% da quantidade de jogos de Windows
  • Mas se precisou ir para o kernel por razões de desempenho, então por que no Linux isso não foi feito em espaço de usuário?