Wine 11 réécrit au niveau du noyau la manière dont Linux exécute les jeux Windows et obtient d’énormes gains de performances

• Refonte complète au niveau du noyau de l’architecture d’exécution des jeux Windows sur Linux, supprimant le goulot d’étranglement de synchronisation lié à wineserver
• Le nouveau pilote NTSYNC traite directement dans le noyau les objets de synchronisation NT, avec des gains de FPS pouvant dépasser x8
• Avec WoW64 désormais achevé, les applications Windows 32 bits peuvent s’exécuter sur un Linux 64 bits sans bibliothèques séparées
• Renforcement du pilote Wayland, prise en charge de Vulkan 1.4, améliorations Bluetooth et force feedback, etc. : la compatibilité progresse sur l’ensemble de la pile graphique et des entrées/sorties
• Les gains en performances et en stabilité se diffusent à tout l’écosystème fondé sur Wine, notamment Proton, SteamOS et Lutris

---

Principaux changements de Wine 11

• Wine 11 n’est pas une simple mise à jour annuelle,

  mais une refonte majeure qui réécrit au niveau du noyau la façon dont Linux exécute les jeux Windows
  • En plus des corrections de bugs et optimisations accumulées au fil des années, cette version introduit des changements structurels comme la prise en charge de NTSYNC, l’achèvement de WoW64 et le renforcement du pilote Wayland
  • Les gains de performances s’étendent à l’ensemble des projets basés sur Wine, comme Proton et SteamOS

Limites historiques et solutions de contournement

• Jusqu’ici, Wine ne parvenait pas à implémenter parfaitement sur Linux les primitives de synchronisation NT de Windows (mutex, semaphore, event, etc.)
  • Pour synchroniser les threads, il fallait effectuer à chaque fois des appels RPC vers wineserver, parfois des milliers de fois par seconde, provoquant des retards d’image et un timing irrégulier
• Esync réduisait les appels à wineserver grâce à eventfd, mais se heurtait aux limites sur le nombre de descripteurs de fichiers
• Fsync, basé sur futex, est plus rapide, mais nécessite des patches externes au noyau, ce qui le rend difficile à utiliser sur les distributions standard
  • Le futex_waitv de Linux 5.16 diffère du prototype de Fsync et ne constitue pas un remplacement complet
• Les deux approches restaient des solutions provisoires, incapables d’implémenter fidèlement certaines API NT, comme NtPulseEvent ou le mode wait-for-all de NtWaitForMultipleObjects

NTSYNC — refonte de la synchronisation au niveau du noyau

• NTSYNC ajoute au noyau Linux un nouveau pilote de périphérique /dev/ntsync qui modélise directement les objets de synchronisation Windows NT
  • La synchronisation n’est plus gérée dans l’espace utilisateur mais directement dans le noyau, supprimant les allers-retours avec wineserver
  • La gestion des files, la sémantique des événements et les opérations atomiques sont toutes prises en charge par le noyau
• Cette évolution a été développée par Elizabeth Figura, déjà à l’origine d’Esync et Fsync, présentée à la Linux Plumbers Conference 2023 puis intégrée à Linux 6.14

• Chiffres des gains de performances

  • Dirt 3 : 110.6 → 860.7 FPS (gain 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 devient entièrement jouable

• Différences par rapport à fsync

  • Pour les utilisateurs de fsync, les gains restent limités, mais les jeux affectés par des goulots d’étranglement multithread bénéficient d’améliorations spectaculaires
  • Comme NTSYNC est intégré au noyau principal, aucun patch séparé n’est nécessaire, et il est immédiatement utilisable sur des distributions récentes comme Fedora 42 et Ubuntu 25.04
  • Il est activé par défaut dans la bêta de SteamOS 3.7.20 et également pris en charge par Proton GE
  • NTSYNC constitue le premier cas dans l’histoire de Wine d’une implémentation correcte de la synchronisation au niveau du noyau

WoW64 achevé — unification de la compatibilité 32 bits

• L’implémentation de l’architecture WoW64 (Windows 32-bit on Windows 64-bit) est achevée dans Wine 11
  • Sur un système Linux 64 bits, il n’est plus nécessaire d’installer des bibliothèques 32 bits séparées pour exécuter des applications Windows 32 bits
  • Un binaire unique détecte automatiquement l’architecture de l’exécutable et la gère en conséquence
• Cela inclut le mappage mémoire OpenGL, le passthrough SCSI et même la prise en charge des applications 16 bits
  • Des logiciels Windows anciens des années 1990 peuvent ainsi être exécutés
• Auparavant, les différences de configuration multilib selon les distributions compliquaient l’exécution ; désormais, Wine le gère en interne

Wayland et autres améliorations majeures

• Pilote Wayland

  • La copie bidirectionnelle via le presse-papiers, la prise en charge du glisser-déposer et le redimensionnement par le compositeur lors des changements de résolution améliorent la compatibilité des jeux plus anciens
  • La plupart des problèmes de compatibilité de Wine lors du passage de X11 à Wayland sont désormais résolus

• Graphismes et médias

  • Sous X11, EGL devient le backend OpenGL par défaut, remplaçant GLX
  • Prise en charge de Vulkan 1.4 et ajout du décodage matériel H.264 via Vulkan Video

• Entrées/sorties et périphériques

  • Les améliorations du force feedback renforcent la prise en charge des volants de course et des joysticks de simulation

  • Prise en charge des services Bluetooth BLE et de l’appairage, amélioration du traitement des soundfonts MIDI

    • Ajout de la compression Zip64, de Unicode 17.0.0, de la numérisation TWAIN 2.0 (64 bits) et de la fonction ping IPv6

• Performances et extension de plateforme

  • Amélioration de la gestion des priorités de threads sur Linux et macOS, avec de meilleures performances multithread
  • Prise en charge de la simulation d’une taille de page de 4K sur ARM64, améliorant la compatibilité avec les appareils Linux basés sur ARM

Compatibilité des jeux et corrections de bugs

• La compatibilité s’améliore pour des titres majeurs comme Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI et Battle.net
• Des centaines de corrections de bugs sont incluses, améliorant globalement la stabilité et les performances

Évaluation d’ensemble

• Avec la combinaison de NTSYNC, de l’achèvement de WoW64, des améliorations de Wayland et d’un grand nombre de corrections de bugs, Wine 11 est la sortie la plus importante depuis Proton
• Les performances et la compatibilité progressent dans tous les projets basés sur Wine, comme Proton, Lutris et Bottles
• Pour les utilisateurs qui jouent sous Linux, Wine 11 est une version qui mérite absolument d’être essayée

[kh0324]

En conclusion, ça va encore se traduire par des années de vieux jeux avec une rétrocompatibilité cassée..

C’est un échange équivalent, en fait.

[GN⁺]

Avis sur Hacker News

• J’ai un respect presque infini pour le projet Wine
  Reproduire pendant 30 ans le comportement documenté et non documenté de Windows semble être un travail ingrat et monotone, mais c’est grâce à cela que Wine est devenu un produit réellement utilisable
  Surtout quand on voit que d’anciens jeux tournent mieux que sous Windows, on mesure l’attention au détail et la tolérance à la souffrance que cela demande

  • Avant, j’évitais de jouer sous Linux parce que je pensais que Wine ne pourrait jamais vraiment fonctionner correctement
    J’essayais parfois de lancer un petit jeu simple et je me disais « tiens, ça marche ? », mais je ne pensais pas que c’était fiable
    Maintenant, j’admets que ce jugement était totalement faux
  • Même si c’est un projet vraiment remarquable, c’est dommage que les applications métier comme Word, Excel ou Outlook fonctionnent encore mal
    Il paraît qu’Excel 2010 est la dernière version à avoir obtenu la note Platinum
    C’est intéressant de se demander pourquoi ces applications sont plus difficiles à prendre en charge que les jeux
  • Wine exécute automatiquement des tests de compatibilité sur différentes plateformes
    En regardant la page des résultats de tests, on voit que cette validation systématique est au cœur de sa forte compatibilité
  • ReactOS mérite aussi d’être mentionné
    Une grande partie des connaissances acquises dans ce projet a alimenté le développement de Wine
  • Dans les années 1990, quand j’utilisais OS/2, il fallait lancer Windows en entier pour exécuter des applications Windows
    À l’époque, j’aurais aimé créer quelque chose comme Wine moi-même, mais je n’en avais pas les connaissances
    Aujourd’hui, je n’utilise Linux que pour les serveurs, et j’ai entendu dire qu’il existe aussi Wine sur Mac, mais je n’ai pas vraiment d’application Windows que j’aie envie d’exécuter

• J’ai été stupéfait de voir à quel point le nombre d’images par seconde a grimpé grâce à Proton
  Voir Dirt 3 passer de 110 FPS à 860 FPS, et Resident Evil 2 de 26 FPS à 77 FPS, c’est difficile à croire
  Je pense que c’est grâce à tout l’argent que Valve a investi là-dedans

  • Cela dit, ces chiffres comparent Wine+ntsync avec la version de base de Wine, donc c’est un peu exagéré
    Comparé à Wine avec fsync, le gain n’est que de quelques pourcents
    Cela reste malgré tout une amélioration nette
    D’après la documentation ntsync, il s’agit d’un pilote noyau destiné à implémenter plus fidèlement sous Linux les mécanismes de synchronisation de Windows
  • Il faut aussi noter que la comparaison porte sur le cas « sans esync ni fsync »
  • Je me demande quelle est exactement la relation entre Proton et Wine — est-ce simplement le nom côté Valve/SteamOS, ou bien un projet séparé ?

• Certains disent qu’il ne faut pas trop s’emballer sur les gains de performance de ntsync
  Dans la plupart des cas, les gains restent de l’ordre de quelques pourcents, et certains jeux peuvent même devenir légèrement plus lents

  • Pour ceux qui utilisent un noyau sans patch fsync, la situation peut être différente
  • Quelqu’un suggère aussi qu’il serait intéressant de comparer les performances entre Wayland et X11

• Quand je lis ce genre de discussion sur des technologies aussi bas niveau, j’ai presque honte de ne faire que des applications CRUD

  • Mais le CRUD a aussi de la valeur, et c’est bon pour la santé mentale
    J’ai déjà entendu l’histoire d’un développeur génial épuisé par des délais extrêmes, qui avait fini par passer à un poste de CRUD simple en VB en disant que c’était « comme des vacances payées »
  • Moi aussi, j’aide parfois simplement des gens dans Outlook avec des trucs du genre « cliquez ici, puis là », mais c’est aussi un travail essentiel
  • À l’inverse, même les développeurs bas niveau disent qu’ils se sentent parfois dépassés lorsqu’ils doivent manipuler des systèmes de plus haut niveau
  • Même moi qui écris des compilateurs, j’ai essayé plusieurs fois de faire une application CRUD pour un projet perso, sans succès
    J’ai testé Rails, Phoenix et Django, mais je n’ai pas trouvé ça simple
    Récemment, j’ai quand même un peu progressé avec l’aide de Claude
  • Les applications CRUD ne sont pas si faciles que ça
    Les exigences des entreprises sont complexes, et l’architecture peut s’effondrer très facilement

• Je suis content de savoir que les milliers de dollars que j’ai dépensés chez Valve ont finalement servi à améliorer Wine
  Je me demande combien de développeurs et de prestataires Valve a engagés pour cela

  • Les deux tiers des développeurs de Wine travaillent chez CodeWeavers, qui est sous contrat avec Valve pour Proton
    Autrement dit, la majeure partie du financement passe par eux

• Wine pourrait, paradoxalement, être autodestructeur
  Si les jeux tournent bien sous Linux, les développeurs pourraient finir par faire directement des portages Linux, et Wine ne serait alors plus nécessaire

  • Mais comme l’API de Wine est plus stable que Linux, Wine pourrait au contraire devenir une cible de premier ordre
  • En réalité, je pense que c’est l’inverse
    Même quand il existe un portage natif, faire tourner la version Windows via Proton est souvent plus fiable
    L’API Windows est familière et ne change pas, donc les développeurs continuent à s’en servir comme référence
  • Aujourd’hui, « support Linux » signifie en pratique fonctionner correctement avec Proton
  • Je pense que c’est un « bon problème » à avoir
  • En plus, Wine sert à bien d’autres usages que le jeu, donc même si les portages natifs se multiplient, la demande restera là
    Comme l’ABI Windows reste plus stable, il est plus efficace de ne maintenir qu’un build Windows tant que l’écart de performances reste minime

• Quelqu’un a demandé s’il ne serait pas possible d’implémenter ntsync en espace utilisateur avec de la mémoire partagée
  Claude a expliqué que, comme pour 95 % des jeux une approche simple suffisait, il n’y avait pas vraiment de motivation pour implémenter une logique complexe de mémoire partagée, et qu’une fois la précision devenue importante, il était naturel de passer au noyau

  • Mais en réalité, c’est impossible parce que Linux ne fournit pas les fonctionnalités d’espace utilisateur nécessaires
    ntsync n’est pas un simple wrapper d’API, mais un adaptateur au niveau du noyau qui reproduit le comportement de synchronisation du noyau NT
    En regardant le code source, on voit que cela est étroitement intégré à l’ordonnanceur du noyau
  • La documentation du noyau précise aussi qu’une implémentation en espace utilisateur ne peut pas atteindre le niveau de performance et de précision de Windows
    Lien vers la documentation

• C’est impressionnant de voir Linux réimplémenter Windows tout en faisant parfois mieux
  Alors que Microsoft rend progressivement son propre logiciel de plus en plus pénible à utiliser, ce genre d’accomplissement est remarquable

  • Le fait que Wine conserve notamment la prise en charge du 16 bits, disparue de Windows 64 bits, est très important
    Beaucoup d’anciens jeux reposent sur du 16 bits, et même parmi les jeux 32 bits, il arrive souvent que le programme d’installation soit en 16 bits

• Si un développeur de Wine lit ceci, j’aimerais qu’il fasse une présentation sur le sujet à la Carolina Code Conference 2026
  L’appel à propositions est ouvert jusqu’au 31 mars

• Si vous voulez la même chose sur macOS, vous pouvez contribuer à ce dépôt

  • Mais honnêtement, il y a trop peu de jeux sur MacOS pour qu’il y ait vraiment beaucoup de développeurs intéressés
    J’ai bien quelques souvenirs de parties de Bolo sur les Mac de l’école, mais on doit être loin d’atteindre 1 % du nombre de jeux Windows
  • Cela dit, si pour des raisons de performances il fallait l’intégrer au noyau, alors pourquoi Linux ne l’a-t-il pas fait en espace utilisateur ?