Windows XP曾经准备了一套故障软件数据库 用“欺骗”方式让老程序继续工作

Windows XP之所以长期以来给人留下“兼容性无敌”的印象，并不完全是因为操作系统本身能够完美兼容所有老软件。微软实际上在系统内部准备了一套规模庞大的应用兼容性数据库，专门记录那些已经出现兼容问题的软件，并在检测到这些程序启动时，通过各种特殊机制改变Windows的行为，让原本无法正常运行的软件继续工作。

这套机制如今仍然存在于现代Windows中。微软官方将其称为Application Compatibility Database（应用程序兼容性数据库），数据库采用带有.sdb扩展名的索引二进制文件保存。Windows会根据程序的文件名、大小、校验值、版本、日期以及程序目录中的其他文件等信息识别具体软件，从而针对某一个特定版本的程序启用相应的兼容性修复，而不是简单地对所有同名程序采取相同处理。

在Windows XP时代，这套数据库的核心文件名为Sysmain.sdb，系统发布时大约已经包含200项兼容性修复。微软当时甚至专门在Windows的AppPatch目录中保存这些兼容性相关文件，以便操作系统能够快速扫描并找到需要处理的软件。

真正有意思的地方在于，微软发现某个程序存在兼容问题之后，并不一定要求软件开发商重新编写程序，而是可以在操作系统层面“骗”一下这个程序，让它误以为自己仍然运行在过去熟悉的Windows环境中。

微软将这种机制称为Shim，也就是兼容性垫片。它的基本工作方式是在应用程序调用Windows API时插入一层小型的中间代码，由这个中间层拦截API调用，然后根据具体程序的情况修改传递给Windows的数据、修改Windows返回给程序的结果，或者在调用真正的系统函数之前执行额外操作。

微软官方文档也明确说明，Compatibility Fix本质上就是一小段能够拦截应用程序API调用的代码，可以把程序的API请求转换成当前Windows能够以旧版本系统方式处理的形式。这样一来，程序本身甚至不知道操作系统已经发生了变化。

最典型的例子就是Windows版本检测。

一些老程序会在启动时检查Windows版本号，如果发现自己运行在没有经过官方支持的新版本Windows上，就直接拒绝启动。这在今天看起来非常奇怪，但早期Windows软件中并不少见。

微软对此提供了类似Win98VersionLie这样的兼容性Shim。如果某个程序必须看到Windows 98的版本信息才能运行，Windows就可以在这个程序运行期间告诉它：“你现在运行的是Windows 98。”

实际上电脑运行的当然还是Windows XP，只不过Windows专门对这个程序伪造了版本信息。程序无法察觉自己被“欺骗”，于是继续正常运行。

这种机制后来成为Windows兼容性体系的重要组成部分。微软工程师Raymond Chen曾专门讨论过这一机制，并指出，如果一个程序必须依靠VersionLie才能运行，那么真正应该修改的是程序本身，而不是继续依赖错误的版本检测逻辑。兼容模式存在的目的，是帮助用户继续运行旧软件，而不是鼓励开发者永远不修复自己的程序。

更令人意外的是，微软当年的兼容性处理并不只是修改一个版本号。有些老软件依赖的甚至是Windows内部更加底层的行为。

Raymond Chen曾特别提到一个名为EmulateHeap的Shim。它可以把应用程序使用的标准Windows堆管理器替换成一个与Windows 95堆管理器高度一致的实现。

所谓堆，是Windows程序动态申请和释放内存的重要机制。一些老程序在开发过程中错误地依赖了Windows 95内存管理器的某些具体行为，而这些行为在后来的Windows版本中已经发生变化。当程序进入Windows XP后，这些依赖就可能导致程序崩溃。

微软没有要求用户放弃这些程序，而是可以针对特定程序启用EmulateHeap，让它继续使用接近Windows 95时代的内存管理行为。

换句话说，Windows XP实际上可以在同一台电脑上同时扮演多个版本Windows的角色：对于普通程序，它按照XP的规则运行；对于某个存在特殊问题的老程序，则可以在后台临时模拟Windows 95或者Windows 98的一部分行为。

这种思路甚至早于Windows XP。

微软前程序员Joel Spolsky曾经讲过一个经典案例：著名游戏《模拟城市》存在一个非常危险的内存管理问题，它会读取刚刚释放的内存。正常情况下，这种行为是不可靠的，但Windows 95为了保证这款游戏能够运行，专门识别SimCity，并让内存分配器以特殊方式工作，暂时不要立即释放某些内存。

也就是说，微软甚至可以针对某一款具体软件修改操作系统的底层行为。

这种做法看起来有些荒诞，但背后其实有非常现实的商业原因。

微软当时面临的一个核心问题是：如果新Windows版本让哪怕一个关键应用程序无法运行，用户就可能因此拒绝升级整个操作系统。

Raymond Chen在2003年的文章中曾解释过这一逻辑。对于普通家庭用户而言，一个旧游戏无法运行可能只是令人失望；但对于企业来说，如果公司的核心文字处理软件、财务软件或者内部业务系统无法在Windows XP上运行，那么升级操作系统就可能意味着整个企业必须重新购买软件。

当时微软内部调查发现，几乎每家公司都至少拥有一个类似的“升级阻碍程序”。其中很多甚至是企业内部自行开发的Visual Basic程序，而最初编写这些软件的开发人员可能早已离职。

这意味着企业即使已经准备升级Windows XP，也可能因为某一个无人维护的内部程序无法运行而被迫继续使用旧版Windows。

因此，对于微软而言，让一个存在缺陷的程序继续运行，有时反而比要求软件开发商修复它更加现实。

Windows XP的兼容性机制也因此形成了一套非常特殊的设计理念：不要让一个坏程序拖垮整个Windows升级过程。

微软后来进一步改进了这种架构，将越来越多的兼容性修复程序放入AppPatch目录中的独立DLL，而不是直接修改Windows核心系统文件。这样做可以避免为了兼容某个几十年前的软件而改变整个操作系统的核心行为。

而且，这套数据库并不是Windows XP发布时固定不变的。

微软在Windows XP生命周期内持续发布Application Compatibility Update，为已经发现的新问题添加兼容性修复。2011年4月发布的一次兼容性更新甚至替换了Windows XP SP3中的Sysmain.sdb，使其达到约1.2MB。此时Windows XP已经上市接近十年，但微软仍然在继续为它添加新的软件兼容性处理。

微软的兼容性机制也并不意味着所有程序都必须被强行运行。对于某些已知会导致严重问题的软件，系统可以直接阻止程序启动；对于风险较低的问题，则可以弹出警告，让用户决定是否继续运行。微软后来将这些机制分别称为Hard Block和Soft Block。

这套设计一直延续到了今天。现代Windows仍然使用Application Compatibility Database以及Shim机制。微软官方文档显示，系统可以根据程序的文件名、大小、校验值、版本和日期等信息确定具体应用，然后针对该应用安装特定兼容性修复。Windows目前仍然通过这种方式帮助旧程序适应新版系统。

甚至现代Windows的“兼容模式”也并不是在电脑里启动一个完整的Windows 95或者Windows XP虚拟机。所谓Windows 95兼容模式，本质上仍然是由多个Shim和配置标志组成的兼容性方案，通过修改部分系统行为，让老程序继续获得它熟悉的运行环境。

当然，这种机制也有明显局限。

Shim主要作用于应用程序自己的进程，因此无法解决所有类型的兼容性问题。如果某个程序依赖已经不存在的内核级功能，或者需要一个与当前Windows不兼容的内核驱动，那么简单地修改API行为通常无济于事。

安全性也可能成为问题。某些老程序依赖的是早期Windows中已经被认为不安全的行为，而为了保证兼容性，微软有时不得不针对这些程序恢复旧规则。Raymond Chen曾将这种现象称为“bug-for-bug compatibility”，也就是为了让旧软件继续工作，Windows甚至需要保留一些历史遗留的错误行为。

这也解释了一个非常有趣的现象：Windows长期以来看起来像是一个“向后兼容能力异常强”的操作系统，但这种兼容性并不意味着微软让现代Windows天然理解几十年前所有软件的运行方式。

很多时候，真正发生的事情是Windows在后台识别出了某个程序，然后悄悄对它实施了一套专门的特殊待遇。

用户只需要双击程序，程序就启动了。

对于用户而言，这就是“Windows XP什么软件都能运行”；而在操作系统内部，实际上可能已经发生了一场精确到某一个.exe文件、某一个API调用甚至某一种内存管理行为的兼容性手术。

Windows XP之所以能够在软件生态快速变化的年代维持如此强大的兼容性，很大程度上正是因为微软没有坚持让所有旧软件必须按照新操作系统的规则重新编写，而是选择在系统内部建立一个不断扩大的“问题软件数据库”，针对每一个已知问题准备对应的解决方案。

这套思路延续至今，也是Windows能够在数十年软件生态变化之后，依然运行大量历史应用的重要原因之一。