URL: https://linuxfr.org/news/hadron-le-futur-de-macos-court-circuite-tout-macos Title: Hadron, le futur de macOS court-circuite tout macOS Authors: Thomas Debesse BAud, cli345 et Xavier Teyssier Date: 2026-10-28T09:01:22+01:00 License: CC By-SA Tags: dxvk, vulkan, zink, wine, macos, proton et steam Score: 9 Un hadron est une particule composite, composée de particules subatomiques régies par l'interaction forte, nous dit [Wikipédia](https://fr.wikipedia.org/wiki/Hadron). Si cela vous fait penser à Proton, ce n’est peut-être pas parce qu’un proton est un hadron, mais parce que Hadron, comme Proton, promet de faire tourner vos jeux (et plus) n’importe où, même sur des systèmes _terreux_. ![Logo Hadron](https://dl.illwieckz.net/b/linuxfr.org/hadron-macos-futur/hadron-logo-light.svg) Vous connaissez peut-être Proton, l’assemblage de Wine et d’autres composants libres que Valve emploie pour faire tourner des jeux Windows sous Linux pour sa plate-forme Steam. Hadron propose la même chose pour macOS. Des jeux Windows ? Sous macOS ? Quel est le 🌀️💀️⚡️⁉️ de rapport avec LinuxFr.org et son objectif de promotion des logiciels libres ? C’est parce que [Hadron](https://github.com/Broyojo/hadron) est construit de briques libres du sol au plafond : Wine, FEX, Mesa, vkd3d… ---- [La forge du projet Hadron](https://github.com/Broyojo/hadron) ---- [![7zFM sur macOS et Apple Silicon grâce à Hadron](https://dl.illwieckz.net/b/linuxfr.org/hadron-macos-futur/20261028-120512-000.macos27-hadron-7zfm.960.png)](https://dl.illwieckz.net/b/linuxfr.org/hadron-macos-futur/20261028-120512-000.macos27-hadron-7zfm.png)_Le logiciel libre 7zFM pour Windows x86-64 s‘exécutant sur un Mac mini M1 sous macOS 27 sans utiliser Rosetta 2._ Le développement de [Hadron](https://github.com/Broyojo/hadron) est encore très jeune, confidentiel, mais très rapide et réactif. Votre serviteur a testé de faire tourner le jeu libre [Unvanquished](https://unvanquished.net) et a rencontré deux bugs ([1](https://github.com/Broyojo/hadron/issues/111), [2](https://github.com/Broyojo/hadron/issues/112)) qui ont tous deux été corrigés dans les deux jours ([1](https://github.com/Broyojo/hadron/pull/119), [2](https://github.com/Broyojo/hadron/pull/118)), et une nouvelle version incorporant les correctifs a été publiée sous cinq jours ([1](https://github.com/Broyojo/hadron/pull/146)). Les spéculations sur « _qui est derrière Hadron_ » pourraient se tourner naturellement vers Valve, qui est le premier bénéficiaire économique d’un tel système, mais le _README_ du projet Hadron est explicite : « _It is unofficial. Hadron is not affiliated with or endorsed by Valve, Apple, CodeWeavers or any of the projects it builds on_ », « _C’est un projet non officiel. Hadron n’est ni affilié à, ni approuvé par Valve, Apple, CodeWeavers ou l’un des projets sur lesquels il s’appuie_ ». Il semble donc que Hadron soit simplement l’initiative de son auteur David Andrews (_Broyojo_), ni plus ni moins. Au delà de la proximité de nom entre Hadron et Proton, Hadron reste délibérément focalisé sur Steam : la fenêtre qui s’affiche quand vous lancez Hadron ne sert qu’à intégrer Hadron à Steam, et les premières versions ne proposaient d’ailleurs pas d’option pour lancer un programme non-Steam (fonctionnalité ajoutée très rapidement en quelques jours aussi). Le but premier de Hadron est Steam, et quand vous rapportez un bug pour un jeu, il vous est demandé l’identifiant Steam de ce jeu (cet identifiant est heureusement optionnel). # Pourquoi Hadron ? En 2027, Apple sortira macOS 28 et à cette occasion, a prévu de drastiquement réduire l’étendue de la compatibilité Rosetta 2. Rosetta 2 est le système de traduction automatique qui permet de faire tourner des binaires amd64 (x86-64) sur arm64 (Apple Silicon ici, dans les macs « M »). Rosetta 2 a un 2 parce que Rosetta premier du nom s’occupait de traduire les binaires PowerPC vers Intel il y a très longtemps. Par commodité nous dirons simplement Rosetta au lieu de Rosetta 2 dans la suite de l’article. Apple a annoncé que Rosetta ne sera plus disponible pour les applications, mais qu’ils conserveront une petite sous-partie prévue uniquement pour faire tourner des vieux jeux non maintenus s'appuyant sur des bibliothèques pour Intel (« _we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks_ » ([source](https://developer.apple.com/documentation/Apple-Silicon/about-the-rosetta-translation-environment)). C’est une affirmation super floue. Que restera-t-il de Rosetta ? Sur quoi pourra-t-on compter et ne pas compter ? Pour Apple, décommissionner Rosetta a un intérêt : ne plus fournir toutes les bibliothèques systèmes en double, ne plus avoir à apporter de la maintenance et du code système pour l’architecture amd64, etc. Tout l’effort de migration vers arm64 est entièrement externalisé vers le développeur indépendant. Ça coûte très cher à l’échelle globale, mais rien du tout pour Apple, et leur clientèle est suffisamment captive pour que le développeur au milieu y soit contraint. Si un développeur échoue à porter son logiciel, le développeur perdra des ventes, mais pas nécessairement Apple. Ce n’est pas le problème d’Apple, surtout quand l’acquisition du logiciel a lieu probablement en dehors de leur marché. Ceci est d’autant plus vrai en dehors du jeu : un logiciel de production concurrent remplace facilement un autre s’il venait à disparaître. Pour un consommateur de jeu, c’est insupportable : il ne veut pas perdre son jeu parce que le développeur ne le développe plus. Il y a un attachement affectif, le joueur y a investi une partie de sa vie, il peut être attaché à l’histoire, etc. Et si le jeu est encore développé, le joueur ne trouve pas d’intérêt à ce que le développeur se retrouve avec plus de travail qui ne lui apportera aucun changement en jeu. Rajouter gratuitement du travail au développeur de jeu n’apporte rien au joueur. Et pour une plate-forme tierce de vente et de location de logiciels comme Steam et autre GOG GALAXY, c’est une catastrophe : si un développeur échoue à porter son logiciel, ou n’est plus disponible pour cette tâche, ce sont des ventes en moins pour le développeur et pour le vendeur. Un vendeur de jeux qui prend sa commission à chaque vente (et dont ce serait la première sinon la seule activité économique) a intérêt à ce que le moindre effort soit proposé aux développeurs de jeux. # L’architecture de Hadron Ne pas confondre avec le [Grand collisionneur de hadrons](https://fr.wikipedia.org/wiki/Grand_collisionneur_de_hadrons) ! L’architecture de Hadron est très différente, mais fait aussi se rencontrer plein de particules élémentaires libres pour observer des effets très intéressants. [![Diagramme de l’architecture de Hadron](https://dl.illwieckz.net/b/linuxfr.org/hadron-macos-futur/hadron-architecture-light.svg)](https://dl.illwieckz.net/b/linuxfr.org/hadron-macos-futur/hadron-architecture-light.svg) _Diagramme de l’architecture de Hadron, telle que décrite dans la documentation du projet._ ## FEX, le traducteur automatique d’instruction processeur Comme alternative à Rosetta pour traduire les instructions amd64 vers arm64 pour exécuter des logiciels, il existe au moins deux logiciels libres : [FEX](https://fex-emu.com) (dont le développement était initialement secrètement soutenu par Valve), et [Box64](https://box86.org) développé par notre [ptitSeb](https://github.com/ptitSeb) national. Ces deux logiciels libres ont été à la base développés pour s’exécuter sous Linux. Hadron a choisi FEX et le fait tourner sous macOS. Ainsi, plus besoin de compter sur Rosetta et d’être dépendant du bon-vouloir d’Apple ! Le choix de FEX correspond bien à l’écosystème de Valve : l’intégration de FEX peut prendre exemple sur celle déjà réalisée pour Steam sur le _Steam Frame_ (un produit de réalité virtuelle tournant sous Linux et sur ARM), et permet d’hériter des tests déjà réalisés par Valve pour le Steam Frame. En intégrant FEX, Hadron rend les jeux et autres logiciels indépendants de la volonté d’Apple d’abandonner la prise en charge de l’architecture x86. ## Wine, l’implémentation libre des API Windows On ne présente plus [Wine](https://www.winehq.org), le logiciel libre qui permet de faire tourner depuis des décennies des programmes Windows sous Linux, BSD et macOS. En 2022 Arek Hiler avait prononcé la désormais célèbre phrase [_Win32 Is The Only Stable ABI on Linux_](https://blog.hiler.eu/win32-the-only-stable-abi/), Win32 est la seule interface binaire de programmation qui soit stable sous Linux. Ce constat de l’ABI Win32 comme une interface très stable s’étend en fait bien au-delà des utilisateurs de Linux. Wine est une brique fondamentale de [Proton](https://github.com/ValveSoftware/Proton), la sous-couche de Valve pour faire tourner des jeux Windows sous Linux. Hadron fait de même pour macOS. Hadron intègre donc FEX et Wine pour faire tourner des programmes Windows compilés pour x86 (32-bit et 64-bit) sur les macs exécutant macOS sur des processeurs ARM. L’héritage Wintel ne s’effacera donc jamais. En intégrant Wine, Hadron rend les jeux et autres logiciels indépendants des interfaces de programmation de macOS. ## Mesa, Zink et KosmicKrisp [Mesa](https://mesa3d.org) est la collection de pilotes graphiques libres qui domine nos écosystèmes Linux et BSD. Mais Mesa propose aussi des pilotes pour d’autres plate-formes, comme Windows et macOS. L’article [Le pilote open-source Vulkan pour AMD “RADV” de chez Mesa bientôt disponible sous Windows ?](https://linuxfr.org/news/le-pilote-open-source-vulkan-pour-amd-radv-de-chez-mesa-bientot-disponible-sous-windows) posait ce constat en répondant à la question « _Et pour Vulkan sur macOS ?_ » : > En participant au développement de RADV sous Linux et Windows, Valve se donne le pouvoir de contrôler la qualité de la pile logicielle d’exécution des jeux qu’ils vendent, jusqu’au pilote graphique inclus. > > Pour macOS, la solution n’est pas à voir du côté de RADV (les derniers macs n’ont plus de cartes graphiques AMD de toute façon), mais du côté de MolktenVK et KosmicKrisp, des pilotes libres convertissant les appels Vulkan vers l’API Metal de macOS. > > Sur macOS Vulkan est déjà disponible grâce à MoltenVK, une implémentation libre traduisant Vulkan pour l’API propriétaire Metal de macOS. Valve a investi dans MoltenVK. Cela permet par exemple à Valve de faire tourner leur jeu Dota2 sur macOS et pouvoir continuer à le vendre aux utilisateurs de macOS sans se soucier de l’obsolétisation d’OpenGL sur macOS par Apple. > > KosmicKrisp est lui un pilote Mesa qui fait de même (convertir Vulkan vers Metal) mais de façon intimement spécialisée pour les puces AGX que l’on trouve dans les ordinateurs Apple M1, M2, etc. (aussi appelé « Apple Silicon »). Et vous le voyez venir en mille, Hadron intègre [KosmicKrisp](https://docs.mesa3d.org/drivers/kosmickrisp.html) pour fournir la prise en charge de l’API graphique Vulkan. KosmicKrisp traduit les appels Vulkan vers l’Interface de programmation (API) propriétaire Metal. En intégrant KosmicKrisp, Hadron rend les jeux et autres logiciels indépendants de la politique d’Apple refusant de prendre en charge le standard industriel Vulkan. Mais, et pour OpenGL ? [Zink](https://docs.mesa3d.org/drivers/zink.html) est un pilote Mesa qui implémente OpenGL au dessus de Vulkan, quel que soit le système (Zink tourne déjà sous Linux et Windows, et donc aussi macOS comme on peut le voir). Voilà, problème résolu. En fait macOS fournit déjà OpenGL, mais ils l’ont déclaré obsolète depuis longtemps et ne fournissent qu’une ancienne version 4.1 qui date de 2010 (16 ans déjà !) qui est 7 ans plus ancienne que la dernière version d’OpenGL (4.6). Zink implémente donc OpenGL 4.6 et en intégrant Zink, Hadron rend les jeux et autres logiciels indépendant de la volonté d’Apple d’abandonner OpenGL. Et au passage, Zink propose la dernière version d’OpenGL et est un pilote désormais bien connu des développeurs de jeu, c’est tout bénef ! Hadron a comme politique de favoriser Zink à la place de l’implémentation OpenGL maison d’Apple. Quand un des bugs donnés comme exemple et affectant Unvanquished a été rapporté, l’expérimentation avait été réalisée avant que Hadron ne propose un moyen simple de lancer un logiciel en dehors de Steam, et donc l’expérimentation avait été faite en appelant Wine directement sans passer par le lanceur de Hadron. Le développeur Broyojo a constaté en lisant le journal du [moteur de jeu Dæmon](https://github.com/DaemonEngine/Daemon) que dans ces circonstances, le jeu utilisait l’implémentation OpenGL d’Apple, chose qu’il s’est empressé de corriger fissa. Et pour le coup, ce changement est ce qui a corrigé le bug, trop facile. L’article sur RADV et Windows indiquait : > Pour un distributeur de jeu vidéo comme Valve c’est excellent : ça signifie que -- si nécessaire -- le jeu peut être distribué avec RADV sur Windows et Linux pour les utilisateurs de cartes graphiques AMD, et MoltenVK ou KosmicKrisp sur macOS afin de fournir une expérience Vulkan finement contrôlée, et autres combinaisons sus-mentionnées. Cela permet de contrôler et donc d’assurer au maximum la compatibilité d’un jeu. Nous y sommes. À part que cette fois-ci, ce n’est pas Valve qui en aurait eu l’initiative. ## vkd3d-proton, DirectX 12 sur KosmicKrisp Là où Zink implémente OpenGL sur Vulkan, [vkd3d-proton](https://github.com/HansKristian-Work/vkd3d-proton) fait de même et implémente DirectX 12 sur Vulkan, lui-même implémenté par KosmicKrisp. DirectX 12 est l’interface de programmation graphique propriétaire de Microsoft pour Windows, elle est similaire à Metal et Vulkan. Un développeur de jeu libre n’en a pas besoin : il peut utiliser OpenGL ou Vulkan, mais de très nombreux jeux utilisent Direct X 12, et Hadron s’assure donc de fournir cette prise en charge. Comme son nom l’indique, vkd3d-proton est une brique essentielle de Proton, et l’est aussi maintenant pour Hadron. ## mtld3d et DXMT, les plus anciens Direct3D sur Metal Vous connaissez peut-être le logiciel [DXVK](https://github.com/doitsujin/dxvk) qui implémentent Direct3D 8, 9, 10 et 11 au dessus de Vulkan. Vous aviez peut-être entendu parlé de D9VK qui faisait de même pour D3D9 mais qui est désormais intégré à DXVK, ou WineD3D qui implémentait Direct3D 8, 9, 10 et 11 au dessus de OpenGL. Proton utilise DXVK sous Linux, implémentant donc D3D sur Vulkan, et Hadron pourrait faire de même, à la façon dont c’est effectivement implémenté avec vkd3d-proton. Mais il existe deux logiciels qui implémentent D3D sur l’API Metal directement, ce qui permet de supprimer une couche intermédiaire de traduction. Ces deux logiciels libres sont [mtld3d](https://github.com/athei/mtld3d) qui implémente D3D9 sur Metal, et [dxmt](https://github.com/3Shain/dxmt) qui implémente D3D10 et D3D11 sur Metal. Pour D3D8, Hadron ne précise pas si quelque chose est prévu, mais il devrait être possible d’utiliser DXVK, ou encore [d3d8to9](https://github.com/crosire/d3d8to9) qui implémente D3D8 sur D3D9. Et on peut supposer que rien ne devrait techniquement empêcher d’utiliser [dd7to9](https://github.com/elishacloud/dxwrapper/wiki/DirectDraw-to-Direct3D9-Conversion) et autres projets de ce type (voir [dxwrapper](https://github.com/elishacloud/dxwrapper) pour plus de détails). # Win32 + Vulkan + AMD64, la plate-forme universelle ? Pour un développeur de logiciel libre, ces APIs DirectX sont peu utiles, mais tout le reste de cet écosystème peut profiter aux développeurs de logiciels libres. Les compilateurs libres du projet MinGW permettent de compiler pour Win32. Wine permet de faire tourner ces programmes Win32 ailleurs que sur Windows. Et en s’appuyant sur les API graphiques OpenGL ou Vulkan, et des bibliothèques comme OpenAL ou SDL pour le son, le fenêtrage et les entrées, un développeur de jeu libre peut donc produire un seul binaire entièrement libre de la tête aux pieds qui tourne partout, sous Linux, BSD, macOS ou Windows. Alors bien évidemment, certains préféreront un programme natif à leur système, avec de bonnes raisons. Mais quand un lanceur comme Steam ou une alternative libre comme Lutris fait toute l’intégration pour vous, tout ce qui retient se réduit à un attachement affectif (et ça compte beaucoup). C’est un chagrin légitime mais il n’empêche pas de jouer. Wine fait déjà tourner naturellement les programmes x86 sur Linux et autres BSD. FEX peut être associé à Wine pour faire tourner des programmes Windows x86 sous Linux et macOS sur les processeurs ARM. Et Box64 sait faire de même sous Linux, non-seulement sur ARM64, mais aussi sur PowerPC (en mode _petit-boutiste_), RISC-V et Loongson. Certains ont pu [déclarer que « _AMD64 is the new Java_ »](https://unvanquished.net/unvanquished-0-56-2-quality), en réalité, c’est peut-être la triforce Win32 + Vulkan + AMD64 qui est ce nouveau Java. Vous ferez peut-être autant la grimace, mais ça ne marche pas moins. Et avec Hadron, votre prochain environnement de développement pour macOS pourrait simplement être MinGW, trop bien ! Avec Hadron, le futur de macOS court-circuite tout macOS, et Apple ne peut rien y faire.