Résumé :
Windows 11 dispose déjà d'une interface utilisateur moderne, de mécanismes de sécurité avancés et de capacités croissantes d'intelligence artificielle, mais au plus profond du système d'exploitation, Microsoft conserve encore du code de l'ère Windows 95. Étonnamment, ces codes ne sont pas simplement laissés dans le système en tant que fichiers historiques, mais peuvent toujours s'exécuter sous certaines conditions, offrant ainsi une prise en charge de la compatibilité pour certaines applications qui s'appuient sur un ancien comportement de gestion de la mémoire.
Dans Windows 11 26H2, Microsoft conserve toujours un mécanisme de réparation de compatibilité des applications appelé EmulateHeap. Il permet à certains anciens programmes d'utiliser du code inspiré du gestionnaire de mémoire de Windows 95 pour empêcher ces programmes de planter en raison de changements dans la façon dont Windows moderne gère la mémoire.
L'histoire de ce mécanisme remonte aux années 1990. A cette époque, une erreur de programme avait été révélée dans un jeu classique appelé "SimCity". Au lieu de simplement demander aux développeurs de réparer le jeu, Microsoft a directement modifié le comportement de Windows 95 afin que le jeu puisse continuer à fonctionner. Depuis lors, Microsoft a utilisé un mécanisme de compatibilité plus systématique pour aider d'autres anciens logiciels rencontrant des problèmes similaires à continuer de fonctionner dans les nouvelles versions de Windows.
Cet historique révèle également un principe de conception important de Windows depuis longtemps : pour un système d'exploitation doté d'un énorme écosystème logiciel, il est parfois plus important de maintenir les anciens programmes en fonctionnement normal que de nettoyer complètement le code historique.
Une erreur de mémoire dans "SimCity" invite Microsoft à modifier le système d'exploitation
Pour comprendre pourquoi EmulateHeap existe, vous devez d'abord comprendre une erreur de programmation courante : continuer la lecture après avoir libéré de la mémoire.
Lorsque l'application est en cours d'exécution, elle doit demander de la mémoire au système d'exploitation pour enregistrer les données. Lorsque les données ne sont plus nécessaires, le programme doit libérer la mémoire correspondante afin que le système puisse la réaffecter à d'autres usages.
Si un programme libère un bloc de mémoire mais continue à lire des données à partir de celui-ci, une erreur dite « d'utilisation après libération » se produit. Il s’agit d’une faille de programmation typique qui peut amener un programme à lire des données non valides, à planter et même à provoquer des problèmes de sécurité dans certains cas.
Certains programmes des premiers environnements Windows s'appuyaient de manière inattendue sur ce comportement erroné.
Selon un article publié en 2000 par Joel Spolsky, co-fondateur de Stack Overflow et ancien ingénieur Microsoft, les premières versions Windows de « SimCity » présentaient des problèmes similaires. Jon Ross, le développeur de cette version, a admis plus tard avoir accidentellement laissé un bug : le jeu continuerait à lire les données initialement stockées là-bas après avoir libéré la mémoire.
La raison pour laquelle ce problème n'a pas été immédiatement révélé est liée à la méthode de gestion de la mémoire de Windows 3.x à cette époque. Dans certaines circonstances, une fois que le programme a libéré la mémoire, les données pertinentes ne sont pas immédiatement écrasées par d'autres utilisations, de sorte que lorsque le jeu continue de lire, il est toujours possible d'obtenir le contenu original.
En d'autres termes, il y a un bug dans le jeu lui-même, c'est juste le comportement de l'ancien système d'exploitation qui masque le problème.
Lorsque Microsoft a développé Windows 95, les choses ont changé. Le nouveau système a adopté un mécanisme de gestion de mémoire différent et "SimCity" a commencé à mal fonctionner dans la version bêta de Windows 95.
Microsoft était confronté à deux choix : demander aux développeurs de jeux de corriger le programme ou laisser le système d'exploitation continuer à tolérer le bug.
En fin de compte, Microsoft a choisi cette dernière solution.
Les ingénieurs ont ajouté un morceau de code de compatibilité spécifiquement pour "SimCity" à Windows 95. Lorsque le système détecte que le jeu est en cours d'exécution, il passe à un mode d'allocation de mémoire spécial qui ne libère pas immédiatement la mémoire associée.
De cette façon, même si le jeu continue de lire les données d'origine après avoir libéré la mémoire, il a plus de chances d'obtenir les résultats attendus et d'éviter les plantages.
Du point de vue du génie logiciel moderne, cette approche est tout à fait unique. En règle générale, les développeurs de systèmes d'exploitation ne souhaitent pas modifier le comportement du système pour masquer les erreurs de programmation dans des logiciels tiers. Mais l'objectif de Microsoft à l'époque était de garantir que le nouveau système puisse exécuter les logiciels existants, plutôt que d'obliger les utilisateurs à abandonner leurs programmes d'origine afin de mettre à niveau le système d'exploitation.
Cette décision est également devenue un cas typique dans l'histoire de la compatibilité Windows.
De "SimCity" à EmulateHeap : le mécanisme de compatibilité s'étend progressivement
Un traitement spécial pour SimCity n'est que le début.
Au fur et à mesure de l'évolution de Windows, Microsoft a découvert que non seulement ce jeu, mais également d'autres applications, reposaient sur certains comportements particuliers du mécanisme de gestion de la mémoire des anciennes versions de Windows.
L'ingénieur Microsoft Raymond Chen a expliqué ce problème dans une chronique sur la technologie Windows publiée en 2010. Certains programmes plus anciens continueront à lire les données de la mémoire après leur libération, en supposant que les valeurs d'origine existent toujours.
Lorsque ces programmes sont exécutés dans des versions ultérieures de Windows, en raison de changements dans l'allocation de mémoire et les méthodes de recyclage, ils peuvent lire du contenu qui a été écrasé par d'autres données, puis planter.
Si Microsoft écrit un morceau de code spécial pour chaque programme présentant de tels problèmes, non seulement le coût de maintenance sera élevé, mais il sera également difficile de faire face au nombre croissant d'anciens logiciels.
En conséquence, Microsoft a lancé un mécanisme de correction de compatibilité appelé EmulateHeap.
Contrairement au code spécifique à SimCity, EmulateHeap propose une approche plus générale. Il intercepte les appels d'application vers les interfaces liées à la gestion de la mémoire et transmet ces appels à une implémentation alternative qui émule le comportement de Windows 95.
Cela implique une série d'interfaces liées à la gestion de la mémoire tas, notamment HeapCreate, LocalLock et GlobalReAlloc. En ajoutant une couche de compatibilité entre les applications et les mécanismes sous-jacents de gestion de la mémoire, le système peut permettre à certains programmes existants de continuer à fonctionner de la manière habituelle.
Ce qui est encore plus surprenant, c'est que Microsoft a adopté une implémentation assez simple.
Selon l'explication de Raymond Chen, les ingénieurs de Microsoft ont directement copié le code source du gestionnaire de mémoire tas de Windows 95, l'ont recompilé et l'ont ajouté au cadre de compatibilité des applications Windows.
Cela signifie qu'un code de gestion de la mémoire Windows 95 très important est effectivement conservé dans l'infrastructure de compatibilité Windows moderne.
Cependant, cela ne signifie pas que Windows 11 exécute le gestionnaire de mémoire Windows 95.
EmulateHeap est un mécanisme de compatibilité activé à la demande. Ce n'est que lorsqu'une application spécifique est configurée pour utiliser ce correctif que le code hérité correspondant sera chargé. Pour les programmes ordinaires qui n'activent pas cette fonctionnalité, Windows ne basculera pas automatiquement vers la méthode de gestion de la mémoire Windows 95 en raison de ce mécanisme de compatibilité.
De plus, EmulateHeap n'a pas la même fonction que le code de compatibilité écrit spécifiquement pour "SimCity" par Microsoft. Les deux reflètent la philosophie de conception de Microsoft consistant à essayer de maintenir les anciens logiciels en fonctionnement normal, mais leurs méthodes de résolution des problèmes et leur champ d'application sont différents.
Comment trouver EmulateHeap dans Windows 11 ?
Pour les utilisateurs qui souhaitent comprendre le mécanisme de compatibilité interne de Windows, Microsoft fournit un outil appelé Compatibility Administrator pour afficher les correctifs de compatibilité des applications pris en charge par le système.
Cet outil est inclus dans le kit d'évaluation et de déploiement Windows (Windows ADK) et est principalement destiné aux administrateurs système et aux professionnels de l'informatique. La version de l'outil correspondante publiée par Microsoft en septembre 2026 prend en charge Windows 11 26H2.
Windows Latest a signalé que l'auteur avait trouvé EmulateHeap sur son ordinateur Windows 11 26H2. Les étapes spécifiques sont les suivantes :
Tout d'abord, téléchargez Windows ADK depuis le site officiel de Microsoft et démarrez le programme d'installation. Dans l'interface de sélection des fonctions, sélectionnez simplement Application Compatibility Tools, qui est l'outil de compatibilité des applications, puis terminez l'installation.
Une fois l'installation terminée, recherchez Administrateur de compatibilité dans le menu Démarrer et ouvrez la version 32 bits. Étant donné qu'un grand nombre d'anciens programmes de l'ère Windows 95 utilisent une architecture 32 bits, la version 32 bits est un outil à utiliser en premier pour vérifier de tels mécanismes de compatibilité.
Après avoir ouvert le programme, cliquez avec le bouton droit sur Nouvelle base de données dans la zone Bases de données personnalisées, sélectionnez Créer, puis passez en mode de compatibilité. Ensuite, recherchez EmulateHeap dans la liste des correctifs de compatibilité disponibles pour voir cette fonctionnalité.
Il est important de noter que trouver un correctif de compatibilité dans la liste ne signifie pas que tous les anciens programmes fonctionneront correctement.
Microsoft a déjà rencontré des problèmes similaires. Après la mise à jour de Windows 11 22H2, certains utilisateurs ont signalé que le jeu « Grand Theft Auto : Vice City » rencontrait des problèmes de perte de son et que « Need for Speed : Most Wanted » plantait après avoir activé certains correctifs de compatibilité.
Cela signifie que le correctif de compatibilité lui-même peut également provoquer des conflits avec d'autres composants du système ou le code du jeu. Même si un certain mécanisme peut résoudre un certain type de problèmes historiques, cela ne signifie pas qu’il convient à tous les programmes.
Par conséquent, les utilisateurs ordinaires n'ont pas besoin d'activer EmulateHeap juste pour essayer d'exécuter un ancien jeu. Si vous rencontrez un problème avec un logiciel plus ancien qui ne fonctionne pas, il est plus prudent de rechercher des recommandations de compatibilité spécifiques pour ce programme avant de décider d'appliquer ou non le correctif.
Pourquoi Windows ne nettoie-t-il pas simplement cet ancien code ?
De Windows 95 à Windows 11, Microsoft a apporté de nombreuses modifications au système d'exploitation. Qu'il s'agisse de la gestion de la mémoire, des systèmes graphiques, des mécanismes de sécurité ou de l'environnement d'exécution des pilotes et des applications, Windows moderne est très différent des systèmes des années 1990.
Mais le système d'exploitation n'est pas un produit qui peut être démonté et reconstruit à tout moment, quel que soit l'ancien logiciel.
Au fil des décennies de développement, des millions d'applications se sont appuyées sur les interfaces et les comportements fournis par Windows. Certains de ces programmes sont développés en stricte conformité avec la documentation officielle, tandis que d'autres s'appuient sans le savoir sur le comportement de certaines versions du système.
Tant que ces programmes seront encore utilisés, Microsoft devra considérer l'impact possible d'une modification des mécanismes sous-jacents.
Pour les logiciels ordinaires, les problèmes de compatibilité après les mises à niveau du système d'exploitation ne peuvent causer que certains inconvénients. Mais pour les logiciels d’entreprise, les outils professionnels et les programmes existants qui effectuent encore de véritables tâches commerciales, les ruptures de compatibilité peuvent causer des dommages encore plus importants.
En conséquence, Microsoft maintient depuis longtemps un vaste cadre de compatibilité des applications. Sa fonction n'est pas seulement d'indiquer à l'ancien programme sur quelle version de Windows il s'exécute, mais aussi d'intercepter certains appels système, d'ajuster des comportements spécifiques ou d'activer des correctifs de compatibilité spécialisés basés sur le programme spécifique.
Ces mesures sont généralement transparentes pour les utilisateurs. Lorsqu'un ancien programme démarre, le système appliquera les correctifs correspondants en arrière-plan et les utilisateurs peuvent ne pas se rendre compte que le système d'exploitation a modifié certains comportements du programme.
EmulateHeap est un exemple de ce système.
Son existence ne signifie pas que Microsoft pense que Windows 95 gère mieux la mémoire que les systèmes modernes, mais cela signifie que certains programmes plus anciens se sont appuyés sur des comportements passés. Pour éviter de casser ces programmes, Microsoft a choisi de conserver un ensemble d'implémentations héritées dans le cadre de compatibilité plutôt que de forcer la réécriture de tous les logiciels selon les règles des systèmes modernes.
Cette approche présente à la fois des avantages et des coûts. Cela peut prolonger la durée de vie des anciens logiciels et réduire les obstacles rencontrés par les utilisateurs pour mettre à niveau le système, mais cela augmentera également la complexité de la maintenance du système d'exploitation, entraînant la persistance d'un certain code historique dans les systèmes modernes pendant une longue période.
Tous les logiciels classiques ne bénéficient pas du même traitement
La volonté de Microsoft de conserver des codes de compatibilité spéciaux pour certains anciens programmes ne signifie pas que tous les logiciels classiques peuvent continuer à fonctionner sous Windows moderne.
Un exemple typique est 3D Pinball, autrefois intégré à Windows, qui est un jeu de flipper en trois dimensions. L'une des raisons pour lesquelles le jeu n'était plus disponible avec une version 64 bits de Windows était qu'il présentait des problèmes de compatibilité 64 bits qui nécessitaient un travail supplémentaire, et Microsoft n'a pas consacré les ressources nécessaires pour les résoudre complètement.
Cela contraste avec la situation avec EmulateHeap.
Pour certains logiciels largement utilisés, ayant une valeur commerciale importante ou pouvant continuer à fonctionner avec des modifications relativement limitées, Microsoft peut être disposé à investir des ressources pour maintenir la compatibilité. Pour d'autres programmes, Microsoft peut choisir de ne plus fournir de support si le coût de la réparation est trop élevé ou si la demande des utilisateurs a considérablement diminué.
Ainsi, la compatibilité Windows n'est pas un engagement illimité. Cela nécessite des compromis constants entre les coûts de maintenance, les besoins des utilisateurs, les risques de sécurité et la complexité technique.
Il est à noter que Microsoft a continué à moderniser l'interface Windows ces dernières années. Par exemple, l'entreprise remplace progressivement certaines boîtes de dialogue de propriétés héritées de l'ère Windows 95 par de nouvelles interfaces basées sur WinUI 3.
Mais la modernisation de l'interface et la maintenance de la compatibilité sous-jacente peuvent être effectuées en même temps. La fenêtre vue par l'utilisateur peut avoir adopté une nouvelle technologie de conception, mais du code ancien est toujours conservé à l'intérieur du système pour garantir que les applications historiques ne perdront pas leur compatibilité en raison des mises à jour de l'interface ou de l'architecture du système.
C'est également l'une des différences importantes entre Windows et de nombreuses plates-formes logicielles relativement jeunes : Windows doit non seulement prendre en charge les applications modernes, mais doit également s'adapter autant que possible à l'énorme écosystème logiciel qui s'est formé au fil des décennies.
La tradition de compatibilité qui se poursuit de Windows 95 à Windows 11
L'histoire d'EmulateHeap peut ressembler à une simple anecdote technique sur d'anciens jeux et gestionnaires de mémoire, mais elle reflète en réalité une stratégie fondamentale de longue date de Windows.
Lorsque "SimCity" a rencontré des problèmes dans la version bêta de Windows 95, Microsoft a choisi de modifier le système d'exploitation pour tolérer le bug du jeu. Depuis lors, à mesure que de plus en plus de programmes anciens étaient exposés à une dépendance au comportement historique du système, Microsoft a progressivement mis en place un mécanisme de réparation de compatibilité plus complet.
Aujourd'hui, Windows 11 conserve toujours du code capable de simuler le comportement de gestion de la mémoire de Windows 95, et les utilisateurs peuvent le trouver via les outils de gestion fournis par Microsoft.
Cela ne signifie pas que Windows moderne s'appuie toujours sur l'architecture de base de Windows 95, ni que les ordinateurs ordinaires exécutent un ancien système d'exploitation en arrière-plan. Ce qui a réellement été conservé, ce sont certains codes de compatibilité et les idées de conception de Microsoft pour éviter autant que possible de casser d'anciens logiciels.
Pour un système d'exploitation vieux de plusieurs décennies, cette approche constitue à la fois un fardeau technique et un avantage concurrentiel. Lorsque les utilisateurs effectuent une mise à niveau vers une nouvelle version de Windows, ils souhaitent souvent continuer à utiliser les logiciels qu'ils ont achetés, les outils qu'ils connaissent et les flux de travail qu'ils ont accumulés au fil des années. En conservant certains anciens codes, Microsoft a réduit les risques de compatibilité causés par la mise à niveau du système d'exploitation.
De ce point de vue, le gestionnaire de mémoire de Windows 95 caché dans Windows 11 n'est pas une simple relique historique, mais une manifestation concrète de l'engagement à long terme de Microsoft en faveur de la compatibilité logicielle. Même si les interfaces des systèmes d'exploitation continuent de changer et que les plates-formes matérielles continuent de se mettre à niveau, certains codes vieux de plusieurs décennies peuvent continuer à fonctionner simplement parce qu'ils permettent à un ancien jeu ou programme de continuer à s'exécuter sur les ordinateurs d'aujourd'hui.
Commentaires