Wine 11.15 est sorti le samedi 8 août, légèrement en décalage avec le rythme habituel du vendredi, avec 41 correctifs et deux changements qui méritent une seconde lecture. Le premier est la prise en charge de la compilation ARM64EC via MinGW, utile à qui assemble des binaires Windows sur ARM avec une chaîne d'outils libre. Le second est un correctif Wayland pour les couleurs délavées causées par une double conversion sRGB, un défaut facile à supporter et difficile à remarquer. Sous tout cela se trouve le bogue 4811, ouvert en mars 2006 contre MSXML3, enfin refermé. Nous avons regardé ce qui change vraiment.
The short answer
Wine 11.15 est sorti le samedi 8 août, en décalage avec le rythme du vendredi habituel, avec 41 correctifs. Les ajouts marquants sont la compilation ARM64EC via MinGW, davantage d'algorithmes de dérivation de clé dans BCrypt, des conversions de formats supplémentaires dans WindowsCodecs et la gestion NTLM en processus dans msv1_0. Deux corrections Wayland arrivent : les couleurs délavées dues à une double conversion sRGB, et le contenu décalé des applications plein écran en 4 tiers 3. Le bogue 4811, un défaut MSXML3 dans XMLDOMDocument déposé en mars 2006, est enfin clos. C'est une version de développement, pas la branche stable.
La plupart des versions de Wine se parcourent en diagonale. Celle-ci contient une ligne franchement drôle, d'une drôlerie que seuls les logiciels de longue vie savent produire : un rapport de bogue ouvert en mars 2006 a été clos samedi. Le bogue 4811, un défaut MSXML3 dans la zone XMLDOMDocument, a passé vingt ans dans le traqueur à avoir raison.
Ce qui change ce que vous pouvez construire
L'entrée la plus lourde de conséquences est la prise en charge de la compilation ARM64EC via MinGW. ARM64EC est l'interface binaire en mode mixte de Microsoft pour Windows sur ARM, et sa raison d'être est de laisser du code ARM64 natif et du code x64 émulé vivre dans le même processus. C'est ce qui rend le portage progressif possible : vous compilez en ARM64 natif les modules qui comptent, vous laissez tourner sous émulation le greffon dont personne n'a les sources, et vous livrez quelque chose qui fonctionne avant que tout le graphe de dépendances soit porté.
Produire des binaires pour cette interface passait largement par la chaîne d'outils de Microsoft. L'amener dans MinGW la déplace vers le chemin de compilation croisée libre, ce qui sert Wine en interne sur hôte ARM et sert aussi qui construit des cibles Windows depuis une machine Linux et préférerait ne pas ajouter un serveur de compilation Windows au pipeline pour une seule interface binaire.
Deux correctifs Wayland que l'on ressent avant de les remarquer
Le correctif de couleur est le plus intéressant. Wine 11.15 corrige les couleurs délavées causées par une double conversion sRGB, ce qui se produit quand un contenu déjà encodé en sRGB est traité comme linéaire puis reconverti avant l'affichage. Le résultat visible n'est pas une image cassée, c'est une image légèrement relevée et légèrement plate. Les tons moyens montent, le contraste tombe, et l'ensemble paraît laiteux.
Ce mode de défaillance dure justement parce qu'il est doux. Personne n'ouvre un bogue intitulé « les gris sont faux d'un petit peu », il persiste donc jusqu'à ce que quelqu'un remonte le pipeline de bout en bout. Le second correctif Wayland est plus visible à l'usage : les applications plein écran en 4 tiers 3 avaient leur contenu décalé dans la sortie au lieu d'être à sa place, le genre de chose que l'on remarque immédiatement puis que l'on contourne en évitant le plein écran.
Ces deux corrections comptent plus qu'un correctif d'application isolé parce qu'elles touchent le chemin d'affichage plutôt qu'un programme. Quiconque utilise Wine dans une session Wayland est concerné.
Le reste du lot
Trois ajouts plus discrets complètent le tableau. BCrypt gagne des algorithmes de dérivation de clé, ce qui étend l'ensemble des primitives cryptographiques que l'implémentation Wine de l'API Windows sait satisfaire au lieu de renvoyer une erreur d'algorithme non pris en charge. WindowsCodecs récupère des conversions de formats supplémentaires, si bien que le composant d'imagerie passe entre davantage de formats de pixels sans que l'application appelante ait à combler le trou, une cause récurrente d'images blanches ou fausses dans les logiciels qui supposent que la plateforme s'en chargera. Et msv1_0 gère maintenant l'authentification NTLM en processus avec un repli, ce qui améliore le comportement des applications qui s'attendent à s'authentifier auprès de la machine locale comme sous Windows.
Les correctifs par application suivent la répartition habituelle. Les jeux prennent leur part, et la longue traîne de logiciels de gestion qui maintient Wine pertinent là où personne n'écrit d'articles aussi : WordPerfect 7 et QuickBooks 2009 figurent tous deux dans cette version.
Qu'en faire
Traitez la 11.15 pour ce qu'elle est. Les versions de développement sortent environ tous les quinze jours et existent pour que les problèmes remontent avant la branche stable annuelle, ce qui veut dire qu'en exploiter une en production, c'est choisir d'être testeur avancé. Si Wine soutient quelque chose dont des gens dépendent, restez où vous êtes.
Si vous suivez un défaut précis, en revanche, le lot est large et le test le plus rapide reste votre propre application. Et si vous utilisez Wine sous Wayland, les corrections de couleur et de plein écran sont une raison d'essayer qui ne tient à aucun programme en particulier. Le correctif MSXML3 vieux de vingt ans ne changera la journée de personne, mais il rappelle que le traqueur de Wine tient moins d'un arriéré que d'une archive du comportement de Windows, et que ses entrées n'expirent pas parce que le calendrier a avancé.
Sources et pour aller plus loin
- Wine 11.15 Released With Wayland Fixes, Fix For A 20 Year Old MSXML3 Bug, Phoronix, 8 août 2026
- Notes de publication de Wine 11.15, GitLab WineHQ
- Site du projet WineHQ et téléchargements
- Bugzilla Wine, bogue 4811
Questions fréquentes
Qu'est-ce qu'ARM64EC et pourquoi sa prise en charge par MinGW compte-t-elle ?
ARM64EC est l'interface binaire de Microsoft pour Windows sur ARM qui permet à du code natif ARM64 et à du code x64 émulé de cohabiter dans un même processus. L'usage pratique est le portage progressif : une grosse application peut compiler ses modules critiques en ARM64 natif tout en laissant les greffons, les bibliothèques tierces et tout ce dont les sources ARM n'existent pas tourner sous émulation, dans le même espace d'adressage, au lieu d'exiger que tout l'arbre de dépendances soit porté d'un coup. Jusqu'ici, produire des binaires ARM64EC revenait en pratique à utiliser la chaîne d'outils de Microsoft. Wine 11.15 ajoute cette cible à MinGW, ce qui compte dans deux directions. Cela donne à Wine un chemin plus propre pour construire les modules en mode mixte dont il a besoin sur hôte ARM, et cela offre à qui compile des binaires Windows depuis Linux une route vers la même interface binaire sans machine de compilation Windows dans la boucle.
En quoi consistait le problème de couleurs délavées sous Wayland ?
Une double conversion sRGB, c'est-à-dire l'équivalent, en gestion des couleurs, d'une correction appliquée deux fois. Les valeurs de pixels de la plupart des applications Windows sont déjà encodées en sRGB, donc si le chemin de composition les traite comme linéaires et les reconvertit en sRGB avant l'affichage, tout ressort plus clair et plus plat qu'il ne devrait. Les tons moyens montent, le contraste baisse, et le résultat paraît légèrement laiteux plutôt que franchement cassé, ce qui explique précisément la longévité de ce genre de défaut. Personne n'ouvre un rapport pour dire que les gris sont faux de deux pour cent. Wine 11.15 le corrige, aux côtés d'un second correctif Wayland où les applications plein écran en 4 tiers 3 voyaient leur contenu décalé dans la sortie au lieu d'être à sa place. Ce sont deux corrections que l'on apprécie surtout après coup, quand la même application cesse d'avoir l'air subtilement de travers.
Comment un bogue reste-t-il ouvert vingt ans dans un projet actif ?
En étant réel, reproductible, et jamais tout à fait prioritaire pour quiconque. Le bogue 4811 a été déposé en mars 2006 contre MSXML3, le composant de services XML de Microsoft, dans la zone XMLDOMDocument. MSXML3 est le type de dépendance qui apparaît sous de vieux logiciels de gestion et des installeurs plutôt que sous quoi que ce soit doté d'une communauté active, si bien que la population touchée était réduite, technique et généralement capable de contourner. Le traqueur de Wine contient une longue traîne exactement de cette forme : des défauts bien caractérisés dans des composants dont les utilisateurs restants se comptent par dizaines. Ils se referment quand quelqu'un travaille par hasard à proximité dans le code, ce qui semble être le cas ici. L'intérêt n'est pas le correctif mais ce qu'il dit de la traîne : les rapports vieux de vingt ans dans Wine restent souvent exacts, parce que le comportement Windows qu'ils décrivent n'a pas changé non plus.
Faut-il déployer la 11.15 ou attendre la branche stable ?
Wine 11.15 est une version de développement, publiée environ toutes les deux semaines sur la route de la prochaine série stable, et le conseil habituel s'applique. Si Wine fait partie d'un flux de travail dont des gens dépendent, restez sur la branche stable et laissez les versions de développement se décanter. Si vous poursuivez un correctif précis de ce lot, et 41 ont atterri, dont du travail sur WordPerfect 7 et QuickBooks 2009 en plus de divers jeux, tester la 11.15 contre votre propre application reste le moyen le plus rapide de savoir si votre problème en fait partie. Les deux corrections Wayland sont celles qui touchent le plus probablement un bureau entier plutôt qu'une application, et quiconque utilise Wine dans une session Wayland a donc une raison plus large que d'habitude de l'essayer.
Qu'est-ce qui change d'autre dans cette version ?
Trois choses méritent d'être nommées. BCrypt gagne des algorithmes de dérivation de clé supplémentaires, ce qui étend l'ensemble des primitives cryptographiques que les applications peuvent demander à l'implémentation Wine de l'API de cryptographie de Windows au lieu d'échouer sur un identifiant d'algorithme non pris en charge. WindowsCodecs récupère davantage de conversions de formats, ce qui permet au composant d'imagerie de passer entre plus de formats de pixels sans que l'application ait à combler l'écart elle-même, une cause fréquente d'images blanches ou corrompues dans les logiciels qui supposent que la plateforme convertira pour eux. Et msv1_0 gère désormais l'authentification NTLM en processus avec un chemin de repli, ce qui améliore la compatibilité des logiciels qui s'attendent à s'authentifier auprès de la machine locale comme ils le feraient sous Windows. Aucun de ces points n'est spectaculaire isolément. Ensemble, ils suivent le schéma habituel de Wine : retirer les raisons qu'a une application d'abandonner.