En octobre 2026, le média spécialisé Windows Latest a mis en lumière une réalité technique pour le moins insolite : au cœur de l’actuel système d’exploitation Windows 11 26H2 repose toujours du code de gestion de la mémoire écrit en 1995 pour Windows 95. Loin d’avoir été supprimé, ce vestige a été recompilé par Microsoft puis intégré directement dans la couche de compatibilité du système. Sa seule mission consiste à préserver le fonctionnement de vieux programmes conçus il y a trois décennies avec une gestion erronée de la mémoire.
Chez Microsoft, la rétrocompatibilité se matérialise souvent sous la forme d’une conservation perpétuelle du code source d’origine. En encapsulant d’anciens modules dans des systèmes modernes, l’éditeur élève les anomalies d’antan au rang de contrats système intemporels. Chaque machine tournant aujourd’hui sous Windows 11 continue ainsi de supporter les conséquences de compromis commerciaux vieux de plus de trente ans.
Dans la boîte à outils de Windows 11 : du code vivant issu de Windows 95
Dénicher ce fossile vivant dans Windows 11 26H2 ne requiert aucune compétence pointue en rétro-ingénierie. Il suffit d’installer le kit officiel Windows ADK de Microsoft, de sélectionner les outils de compatibilité applicative (« Application Compatibility Tools ») et de lancer le Compatibility Administrator en version 32 bits. Dans la longue liste de correctifs système disponibles figure en bonne place une option baptisée EmulateHeap.
Figure : L’option de compatibilité EmulateHeap dans le Compatibility Administrator de Windows 11. Source : Windows Latest
Le principe d’action d’EmulateHeap est aussi simple que radical : dès lors que cette option est activée pour un ancien programme, le système intercepte la totalité de ses appels à la mémoire tas (heap). Qu’il s’agisse des routines d’allocation comme HeapCreate, des fonctions de verrouillage telles que LocalLock ou de réallocation via GlobalReAlloc, chaque instruction est détournée vers une implémentation dédiée. Son comportement reproduit à l’identique les caractéristiques du Windows 95 sorti en 1995.
Microsoft a d’ailleurs renoncé à simuler ces règles à l’aide d’heuristiques contemporaines. Selon les notes partagées par le célèbre ingénieur Raymond Chen, l’équipe a directement récupéré le code source original du gestionnaire de mémoire de Windows 95, l’a recompilé et l’a inséré dans le module de compatibilité. Microsoft a préféré le code d’origine à l’émulation comportementale afin d’écarter le moindre risque d’incompatibilité imprévue. C’est ainsi que des instructions machine vieilles de 31 ans ont obtenu droit de cité dans le système d’exploitation le plus récent.
Sauver SimCity : quand Microsoft palliait les erreurs des développeurs
Ce correctif atypique trouve sa source dans une bataille commerciale décisive menée il y a trente ans. En 1995, alors que Microsoft préparait le lancement historique de Windows 95, le célèbre jeu PC SimCity plantait de manière systématique sur les machines de test. Si le nouvel OS s’avérait incapable de faire tourner le titre phare de l’époque, les utilisateurs rejetteraient immédiatement la faute sur le système d’exploitation plutôt que sur le jeu.
Figure : SimCity 2000, le célèbre jeu de gestion urbaine qui a marqué son époque. Source : Nap’n’Retrogaming
Les ingénieurs de Microsoft menèrent l’enquête et découvrirent rapidement que l’anomalie incombait exclusivement au jeu lui-même. Jon Ross, l’un des concepteurs de SimCity, admit plus tard que le code comportait une erreur classique d’utilisation après libération (use-after-free) : l’application libérait un bloc de mémoire auprès du système, puis continuait tranquillement à y lire les données obsolètes.
À l’époque de Windows 3.x, une architecture mémoire rudimentaire masquait cette faille sévère. Le système 16 bits reposait sur un multitâche coopératif ; lorsqu’une application relâchait de la mémoire, l’OS n’effaçait ni ne réassignait immédiatement les adresses physiques correspondantes. Les données résiduelles demeuraient intactes et le jeu continuait de tourner par pur hasard. Mais avec l’arrivée du multitâche préemptif et d’un gestionnaire de mémoire 32 bits dans Windows 95, la mémoire libérée était immédiatement écrasée ou invalidée, entraînant le crash instantané du jeu.
Joel Spolsky, ancien chef de programme chez Microsoft, révéla les dessous de l’affaire dans un article célèbre publié en 2000 : au lieu d’exiger un correctif en urgence de l’éditeur Maxis, Microsoft intégra une routine de détection spécifique dans le gestionnaire d’allocation de Windows 95. Dès que le noyau identifiait le processus de SimCity, le gestionnaire basculait dans un mode dérogatoire retardant la réassignation de la mémoire libérée. Afin d’assurer le succès commercial de sa plateforme, le système d’exploitation a pris en charge les failles de code d’un éditeur tiers.
Ériger des vulnérabilités en contrat : du bricolage au module permanent
Dans les années 1990, de telles anomalies étaient légion. L’explosion rapide du marché des logiciels PC vit déferler une multitude d’applications 32 bits développées à la hâte, criblées d’irrégularités mémoire. De nombreux programmeurs, habitués à la tolérance de Windows 95, finirent par considérer la possibilité de relire de la mémoire libérée comme une spécificité normale du système.
Lorsque la branche Windows NT succéda définitivement à la gamme Windows 9x, Microsoft imposa une architecture de mémoire tas beaucoup plus stricte et sécurisée. Des centaines de jeux anciens et de logiciels professionnels se retrouvèrent brusquement inutilisables sur les nouvelles versions. Microsoft ne pouvant pas coder une gestion d’exception pour chaque titre au sein du noyau NT, les ingénieurs durent trancher entre pureté architecturale et préservation d’un écosystème logiciel colossal. Ils choisirent une solution pragmatique.
Figure : Le cheminement de survie du code mémoire de Windows 95 au sein de la couche moderne de compatibilité. Source : Windows Latest
L’équipe détacha le composant de gestion de mémoire directement depuis l’arborescence du code source de Windows 95 pour en faire un correctif de compatibilité autonome baptisé EmulateHeap. D’un point de vue strict de cybersécurité, les failles d’utilisation après libération constituent des vulnérabilités critiques pouvant ouvrir la voie à l’exécution de code arbitraire. Mais face aux impératifs économiques du marché grand public, la rétrocompatibilité l’a emporté sur la rigueur conceptuelle. Microsoft a ainsi gravé dans le marbre les défauts du passé sous forme d’engagements système permanents.
Refondre l’interface en WinUI 3 tout en distribuant des modules de 1995
Ce culte absolu de la compatibilité donne lieu à de saisissants contrastes d’ingénierie. D’un côté, Microsoft s’efforce de moderniser l’apparence de Windows : même les boîtes de dialogue des propriétés de fichier, quasiment inchangées depuis des décennies, adoptent désormais le framework WinUI 3. De plus, afin d’éradiquer les failles mémoire à la racine, Microsoft intègre activement le langage Rust au sein du noyau Windows.
Mais derrière cette vitrine technologique étincelante, les dettes techniques restent fidèlement préservées. Même en 2026, sur la version 26H2 de Windows 11, Microsoft fait appel à ses chaînes modernes de compilation pour fabriquer le gestionnaire de mémoire vieux de 31 ans et l’inclure dans les images système officielles. À l’inverse, des composants pourtant chers aux utilisateurs, à l’image du célèbre jeu 3D Pinball, ont été impitoyablement abandonnés au fil des transitions.
La décision d’abandonner 3D Pinball lors du passage au 64 bits était tout aussi pragmatique : le moteur de détection des collisions avait été écrit exclusivement en assembleur x86 32 bits, sans aucune documentation sur la logique en virgule flottante. Lors du portage 64 bits, la bille traversait systématiquement les batteurs. Identifier l’anomalie aurait nécessité plusieurs jours de rétro-ingénierie ; Microsoft a donc préféré rayer purement et simplement le jeu du système. La patience de Microsoft envers le code hérité a ses limites : les jeux récréatifs sont jetables, mais le socle de la compatibilité applicative demeure intouchable.
Trente et un ans de compromis : l’addition payée par le matériel moderne
Pourtant, ce composant historique que Microsoft protège depuis tant d’années perd de son efficacité sur le matériel contemporain. Depuis Windows 11 22H2 et les versions ultérieures, les passionnés de rétrogaming constatent des défaillances fréquentes d’EmulateHeap. Lorsqu’ils tentent de lancer des classiques tels que Grand Theft Auto: Vice City ou Need for Speed: Most Wanted avec cette option, les jeux perdent souvent des canaux audio ou plantent dès le démarrage.
La raison tient au fait que les ordinateurs actuels ne partagent plus du tout les caractéristiques matérielles de 1995. Les processeurs modernes disposent de multiples cœurs, d’exécutions d’instructions dans le désordre et de barrières matérielles d’isolation de la mémoire. Conçu à l’époque des processeurs monocœurs et de la mémoire à plat, le gestionnaire de mémoire de Windows 95 ne peut tout simplement plus interagir convenablement avec les pilotes graphiques actuels et les environnements fortement multithreadés.
Si la rétrocompatibilité absolue a permis à Windows d’ériger une forteresse commerciale imprenable, elle a également généré une dette technique gigantesque. À chaque saut d’architecture, Microsoft doit continuer à traîner l’intégralité du fardeau d’hier. Ce qui n’était au départ qu’un bricolage temporaire est devenu un fossile logiciel inamovible. Lorsque le monde progresse trop loin, la promesse de ménager le passé indéfiniment finit par devenir un poids pour tous les utilisateurs du présent.
Sources et références :
- Article de Windows Latest : Pourquoi Windows 11 intègre toujours le gestionnaire de mémoire de Windows 95
- Chronique de Joel on Software : Strategy Letter II: Chicken and Egg Problems
- Documentation technique Microsoft : Chronique Windows Compatibility sur le fonctionnement d’EmulateHeap
