Le 19 octobre 2026, Abhijith M B, journaliste chez Windows Latest, a signalé avoir repéré EmulateHeap dans Compatibility Administrator sur un PC sous Windows 11 26H2. Ce correctif de compatibilité reproduit le comportement du tas mémoire de Windows 95 lorsqu’il est activé pour un processus, selon l’explication de l’ingénieur Microsoft Raymond Chen.

Une entrée repérée dans Compatibility Administrator

Windows Latest repère EmulateHeap sur un PC sous Windows 11 26H2

La capture publiée par Windows Latest montre une ligne EmulateHeap dans la liste des correctifs de compatibilité. Compatibility Administrator fait partie du Windows Assessment and Deployment Kit (Windows ADK). La documentation Microsoft de l’ADK 10.1.26100.9457, publiée en septembre 2026, indique sa prise en charge de Windows 11 26H2, 25H2 et 24H2.

Pour retrouver l’entrée, Windows Latest décrit cette démarche : installer le Windows ADK, sélectionner Application Compatibility Tools, puis ouvrir Compatibility Administrator 32 bits. Dans l’outil, il faut créer une base de données via Custom Databases > New Database > Create New > Compatibility Mode, puis parcourir la liste des correctifs. La documentation de Microsoft sur le Windows ADK détaille les outils inclus dans le kit.

EmulateHeap reproduit le tas de Windows 95 pour un processus

Un tas mémoire, ou heap, est une zone que les programmes utilisent pour allouer et gérer de la mémoire pendant leur exécution. Raymond Chen explique qu’EmulateHeap redirige les appels du système d’exploitation liés au tas vers des fonctions de remplacement qui reproduisent le comportement de Windows 95. Microsoft a intégré à son infrastructure de compatibilité une copie du code source du gestionnaire de tas de Windows 95, recompilée pour cet usage. Le code est chargé quand le correctif est activé pour un processus, selon l’explication de Chen sur Microsoft Learn.

C’est une réponse à de vieux logiciels qui ont fini par dépendre de particularités de leur environnement d’origine. Un programme peut, par exemple, compter sur la réutilisation d’une adresse mémoire précise lors d’une allocation ultérieure, ou lire une zone après l’avoir libérée en s’attendant à ce que son contenu reste identique, ou change d’une certaine manière. Ces habitudes peuvent fonctionner par coïncidence avec un gestionnaire de mémoire, puis provoquer des problèmes avec un autre.

Le tas de Windows 95 n’est pas pour autant intrinsèquement meilleur ou plus robuste, précise Chen. Émuler ses particularités a un coût : lorsque le correctif est actif pour un processus, les nouvelles fonctions du tas à faible fragmentation doivent être désactivées pour préserver les comportements dont le logiciel dépend.

Le correctif de SimCity était différent

Dans un récit publié le 24 mai 2000, Joel Spolsky attribue à Jon Ross, auteur du SimCity original pour Windows 3.x, l’explication d’un bogue qui amenait le jeu à lire de la mémoire déjà libérée. Spolsky raconte que Windows 95 utilisait pour SimCity un mode d’allocateur spécifique qui ne libérait pas immédiatement la mémoire. Ce correctif propre à un jeu est distinct d’EmulateHeap, qui reproduit le comportement du tas de Windows 95 pour les processus auxquels le correctif de compatibilité est appliqué. Le récit de Spolsky décrit cette histoire de SimCity.