Windows 11至今仍隐藏着Windows 95的内存管理器 微软保留了数十年前的代码

在Windows 11 26H2中，微软依然保留着名为EmulateHeap的应用程序兼容性修复机制。它能够让特定旧程序使用仿照Windows 95内存管理器设计的代码，以避免这些程序因为现代Windows改变了内存管理方式而出现崩溃。

这套机制的历史可以追溯到20世纪90年代。当时，一款名为《模拟城市》（SimCity）的经典游戏暴露出一个程序错误，而微软没有简单地要求开发者修复游戏，而是直接修改Windows 95的行为，让游戏能够继续运行。此后，微软又通过更系统化的兼容性机制，帮助其他存在类似问题的旧软件在新版本Windows中继续工作。

这段历史也揭示了Windows长期以来的一项重要设计原则：对于一个拥有庞大软件生态的操作系统而言，保持旧程序能够正常运行，有时比彻底清理历史代码更加重要。

《模拟城市》的内存错误促使微软修改操作系统

要理解EmulateHeap为何存在，需要先了解一个常见的程序错误：释放内存后继续读取。

应用程序运行时，需要向操作系统申请内存，用来保存数据。当这些数据不再需要时，程序应当释放相应的内存，以便系统将其重新分配给其他用途。

如果程序释放了一块内存，却仍然继续读取其中的数据，就会出现所谓的“释放后使用”（use-after-free）错误。这是一种典型的编程缺陷，可能导致程序读取无效数据、发生崩溃，甚至在某些情况下引发安全问题。

早期Windows环境中的部分程序却意外地依赖了这种错误行为。

根据Stack Overflow联合创始人、前微软工程师乔尔·斯波尔斯基（Joel Spolsky）在2000年发表的一篇文章，早期Windows版本的《模拟城市》就存在类似问题。该版本的开发者乔恩·罗斯（Jon Ross）后来承认，自己不小心留下了一个错误：游戏会在释放内存之后，继续读取原先存放在那里的数据。

之所以这一问题没有立即暴露，与当时Windows 3.x的内存管理方式有关。在特定情况下，程序释放内存后，相关数据并没有马上被其他用途覆盖，因此游戏继续读取时，仍然可能得到原来的内容。

换句话说，游戏本身存在错误，只是旧操作系统的行为恰好掩盖了这个问题。

当微软开发Windows 95时，情况发生了变化。新系统采用了不同的内存管理机制，《模拟城市》在Windows 95测试版本中开始出现故障。

微软当时面临两种选择：要求游戏开发者修复程序，或者让操作系统继续容忍这一错误。

最终，微软选择了后者。

工程师为Windows 95加入了一段专门针对《模拟城市》的兼容性代码。当系统发现这款游戏正在运行时，就会切换到一种特殊的内存分配模式，不会立即释放相关内存。

这样一来，即使游戏在释放内存后继续读取原有数据，也更有可能获得预期的结果，从而避免崩溃。

从现代软件工程的角度来看，这种做法颇为特殊。通常情况下，操作系统开发者并不会希望通过改变系统行为来掩盖第三方软件中的编程错误。但微软当时的目标，是确保新系统能够运行已有的软件，而不是迫使用户为了升级操作系统而放弃原有程序。

这一决定也成为Windows兼容性历史中的一个典型案例。

从《模拟城市》到EmulateHeap：兼容性机制逐渐扩大

针对《模拟城市》的特殊处理只是一个开始。

随着Windows逐渐发展，微软发现，不只是这款游戏，还有其他应用程序也依赖旧版本Windows内存管理机制中的一些特殊行为。

微软工程师雷蒙德·陈（Raymond Chen）曾在2010年发表的Windows技术专栏中解释过这一问题。一些旧程序会在释放内存后继续读取其中的数据，并假设原来的数值仍然存在。

当这些程序运行在后续Windows版本中时，由于内存分配和回收方式发生变化，它们可能读取到已经被其他数据覆盖的内容，进而发生崩溃。

如果微软为每一款存在此类问题的程序单独编写一段特殊代码，不仅维护成本很高，也难以应对数量不断增加的旧软件。

因此，微软推出了名为EmulateHeap的兼容性修复机制。

与专门针对《模拟城市》的代码不同，EmulateHeap提供了一种更通用的处理方式。它会拦截应用程序对内存管理相关接口的调用，并将这些调用转交给能够模拟Windows 95行为的替代实现。

这涉及一系列与堆内存管理有关的接口，包括HeapCreate、LocalLock和GlobalReAlloc等。通过在应用程序与底层内存管理机制之间加入兼容层，系统能够让特定旧程序继续按照它们熟悉的方式工作。

更令人意外的是，微软采用了一种相当直接的实现方式。

根据雷蒙德·陈的解释，微软工程师直接复制了Windows 95堆内存管理器的源代码，重新编译后，将其加入Windows应用程序兼容性框架。

这意味着，现代Windows的兼容性基础设施中，确实保留了一份相当重要的Windows 95内存管理代码。

不过，这并不意味着Windows 11平时一直在运行Windows 95的内存管理器。

EmulateHeap属于按需启用的兼容性机制。只有当特定应用程序被配置为使用这项修复时，系统才会加载相应的旧式代码。对于没有启用该功能的普通程序，Windows不会因为这项兼容性机制而自动切换到Windows 95的内存管理方式。

此外，EmulateHeap与微软当年专门为《模拟城市》编写的兼容性代码并不是同一项功能。两者都体现了微软尽量维持旧软件正常运行的设计思路，但它们解决问题的方式和适用范围有所不同。

如何在Windows 11中找到EmulateHeap？

对于希望了解Windows内部兼容性机制的用户，微软提供了一款名为Compatibility Administrator的工具，可以查看系统支持的应用程序兼容性修复。

该工具包含在Windows Assessment and Deployment Kit（Windows ADK）中，主要面向系统管理员和IT专业人员。微软于2026年9月发布的相关工具版本支持Windows 11 26H2。

Windows Latest报道称，作者在自己的Windows 11 26H2电脑上找到了EmulateHeap。具体步骤如下：

首先，从微软官方网站下载Windows ADK并启动安装程序。在功能选择界面中，只需选择Application Compatibility Tools，也就是应用程序兼容性工具，随后完成安装。

安装完成后，在开始菜单中搜索Compatibility Administrator，并打开32位版本。由于大量Windows 95时代的旧程序本身采用32位架构，32位版本是检查这类兼容性机制时值得优先使用的工具。

打开程序后，在Custom Databases区域中右键单击New Database，选择Create New，再进入Compatibility Mode。随后，在可用的兼容性修复列表中查找EmulateHeap，即可看到这项功能。

需要注意的是，在列表中找到某项兼容性修复，并不意味着它一定能够让所有旧程序正常运行。

微软此前就遇到过类似问题。Windows 11 22H2更新之后，一些用户报告称，启用特定兼容性修复后，游戏《侠盗猎车手：罪恶都市》出现了声音丢失的问题，而《极品飞车：最高通缉》则发生了崩溃。

这说明，兼容性修复本身也可能与其他系统组件或游戏代码产生冲突。即使某种机制能够解决一类历史遗留问题，也不代表它适用于所有程序。

因此，普通用户没有必要为了尝试运行某款老游戏，就随意启用EmulateHeap。如果确实遇到旧软件无法运行的问题，更稳妥的做法是先查找针对该程序的具体兼容性建议，再决定是否使用相关修复。

Windows为何不直接清理这些旧代码？

从Windows 95发展到Windows 11，微软已经对操作系统进行了大量改造。无论是内存管理、图形系统、安全机制，还是驱动程序和应用程序运行环境，现代Windows都与20世纪90年代的系统存在巨大差异。

但操作系统并不是一个可以随时推倒重建、完全不考虑旧软件的产品。

在数十年的发展过程中，数以百万计的应用程序依赖Windows提供的接口和行为。其中一些程序严格按照官方文档开发，另一些程序则在不知不觉中依赖了某些特定版本的系统行为。

只要这些程序仍然有人使用，微软就需要考虑修改底层机制可能造成的影响。

对于普通软件而言，操作系统升级后出现兼容性问题，可能只会带来一定的不便。但对于企业软件、专业工具以及仍然承担实际业务任务的旧程序来说，兼容性中断可能造成更大的损失。

因此，微软长期维护着一套庞大的应用程序兼容性框架。其作用不仅是告诉旧程序自己正在运行在哪个版本的Windows上，还可以根据具体程序的情况，拦截部分系统调用、调整特定行为，或者启用专门的兼容性修复。

这些措施通常对用户透明。旧程序启动时，系统会在后台应用相应的修复，用户未必能够察觉到操作系统已经针对该程序改变了某些行为。

EmulateHeap正是这一体系中的一个例子。

它的存在并不意味着微软认为Windows 95的内存管理方式比现代系统更好，而是说明有些旧程序已经依赖了过去的行为。为了避免破坏这些程序，微软选择在兼容性框架中保留一套旧式实现，而不是强迫所有软件都按照现代系统的规则重新编写。

这种做法既有优势，也有代价。它可以延长旧软件的使用寿命，减少用户升级系统时的障碍，但也会增加操作系统的维护复杂度，使部分历史代码长期存在于现代系统中。

并非所有经典软件都能获得同等待遇

微软愿意为部分旧程序保留特殊兼容性代码，并不意味着所有经典软件都能在现代Windows中继续运行。

一个典型例子是Windows曾经内置的3D Pinball，也就是三维弹球游戏。该游戏后来没有继续随64位版本Windows提供，原因之一是它存在需要额外处理的64位兼容性问题，而微软没有投入资源彻底解决这些问题。

这与EmulateHeap的情况形成了对比。

对于一些被广泛使用、具有重要商业价值或者能够通过相对有限的修改继续运行的软件，微软可能愿意投入资源维护兼容性。对于其他程序，如果修复成本过高，或者用户需求已经明显下降，微软则可能选择不再提供支持。

因此，Windows的兼容性并不是一项没有边界的承诺。它需要在维护成本、用户需求、安全风险和技术复杂度之间不断权衡。

值得注意的是，微软近年来仍在继续现代化Windows的界面。例如，公司正逐步用基于WinUI 3的新界面替换部分Windows 95时代遗留下来的属性对话框。

但界面现代化与底层兼容性维护可以同时进行。用户看到的窗口可能已经采用全新的设计技术，系统内部却仍然保留着一些旧式代码，用于确保历史应用程序不会因为界面或系统架构的更新而失去兼容性。

这也是Windows与许多相对年轻的软件平台之间的重要区别之一：Windows不仅要支持现代应用程序，还需要尽可能容纳数十年来形成的庞大软件生态。

从Windows 95延续至Windows 11的兼容性传统

EmulateHeap的故事看似只是一个关于老游戏和内存管理器的技术趣闻，实际上反映了Windows长期以来的一项核心策略。

当《模拟城市》在Windows 95测试版本中出现问题时，微软选择修改操作系统来容忍游戏中的错误。此后，随着更多旧程序暴露出对历史系统行为的依赖，微软逐步建立起更完善的兼容性修复机制。

如今，Windows 11仍然保留着能够模拟Windows 95内存管理行为的代码，而且用户可以通过微软提供的管理工具找到它。

这并不意味着现代Windows仍然依赖Windows 95的核心架构，也不代表普通电脑正在后台运行一套旧操作系统。真正延续下来的是部分兼容性代码，以及微软尽可能避免破坏旧软件的设计思路。

对于一个拥有数十年历史的操作系统而言，这种做法既是技术负担，也是竞争优势。用户升级到新版本Windows时，往往希望继续使用已经购买的软件、熟悉的工具以及多年积累的工作流程。微软通过保留部分旧代码，降低了升级操作系统带来的兼容性风险。

从这个角度看，Windows 11中隐藏的Windows 95内存管理器并不是一段单纯的历史遗迹，而是微软对软件兼容性长期承诺的一个具体体现。即使操作系统的界面不断变化，硬件平台持续升级，部分数十年前的代码仍然可能继续发挥作用，只因为它能够让一款旧游戏或旧程序在今天的电脑上继续运行。