孩子想开发个RPG游戏，让我找个游戏参考，我想起了多年前玩儿过的《仙剑奇侠传》。

到Steam上找了一个，下载运行，复古的、熟悉的界面立刻出现在眼前：

《仙剑奇侠传》Windows版是1997年上市的，快30年了，它依然可以顺畅地运行在现在的Window 11之上。

这也不算啥，如果你手头有20多年前发布的Office 2000：

也可以安装在Windows 11上试试，照样能用：

除此之外，还有1995年发布著名软件Total Commander 32位，可以从Windows 95 一路运行到 Windows 11。

1998年发布的开发神器 Visual Basic 6，现在微软还在给它兜底， VB 6写出的老程序，还可以运行在Windows 11上！

2002 年经典的 Photoshop 7 ，Windows 11上还能跑:

2003 年发布的 Winamp 2.91 在 Windows 11 上秒开，音效均衡器、EQ 调节以及经典 90 年代像素皮肤完美呈现，CPU 占用率接近 0%。

这向后兼容性可以说是无敌了！

怪不得Reddit上网友感慨道：Windows是人类历史上最伟大的软件。

01

微软的兼容性绝招

Windows实现这样的兼容性，可不是一件简单的事情，微软有两个绝招：

1.为了兼容，连Bug都不放过！

有个著名的游戏叫《模拟城市》，在Windows 3.x时代有个叫 Jon Ross 的程序员无意间写错了一段代码，导致游戏在释放了一段内存以后，依然去读取它。

这本来会导致游戏立刻崩溃，但是Windows 3.x 系统的内存管理比较简单，内存被释放后，里面的数据并不会立刻被清除或被其他程序覆盖，所以虽然代码写错了，但依然能歪打正着地正常运行。

等到Windows 95发布的时候，引入了更现代、更严格的内存管理机制，《模拟城市》一运行就崩溃。

微软该怎么办呢？

最直接的办法就是拿起电话，给《模拟城市》的开发商 Maxis 打电话，让他们现在、立刻、马上修复漏洞。

但是游戏已经通过光盘卖出去了，当时又没有网络更新，即使 Maxis 修复了 Bug 也无法解决所有的问题。

于是微软决定：保留这个Bug，直接修改 Windows 95 的代码来兼容它。

当 Windows 95 检测到《模拟城市》开始运行的时候，就自动切换到一个特殊的内存分配模式，故意延迟释放该游戏用过的内存，从而让《模拟城市》顺利运行。

还有一个著名的案例，在Windows 2000 时代，当时的 DLL 搜索规则比较简单，当前工作目录在搜索 DLL 时处于比较靠前的位置，很容易造成 DLL 劫持。

后来 Windows 改进了 DLL 搜索机制，但是许多老程序（甚至包括某些商业巨头的核心软件）在设计时，“意外”地依赖了 Windows 2000 时代不安全的搜索规则。当它们在新的 Windows 系统上运行时，因为找不到特定位置的 DLL 直接崩溃。

微软的解决方案是：推出 Windows 2000 兼容模式。

当程序开启该模式时，会还原 Windows 2000 时代的 DLL 加载机制，甚至恢复老旧版本堆分配器（Heap Allocator），相当于把已经修复的Bug重新打开了。

你看，Windows 的向后兼容，连前任系统的缺陷和漏洞一并当成珍贵的遗产继承了下来。

2.程序不配合？那就想办法骗过它！

《最终幻想 7》是PlayStation 平台上的游戏，移植到 PC 平台时做得非常糟糕，在运行时甚至会检查当前操作系统是不是Windows 95。

当大量用户升级到 Windows 2000、Windows XP时，游戏出现了各个问题：第一次战斗崩溃，CG和音频异常，陆行鸟比赛时必崩。

微软的做法很简单，给《最终幻想7》配了一个叫做“Win95VersionLie”的兼容性修复，专门对这个游戏撒谎，让它“以为”自己运行在Windows 95之上。

在 Windows XP 及更早时期，大量桌面用户和应用程序运行在管理员权限下，软件可以肆无忌惮地在 C:\Program Files\MyApp\ 下创建、修改配置文件或数据库。

到了 Windows Vista，微软引入了 UAC，彻底收紧了系统盘的写入权限，非管理员权限程序是无法直接访问的。

但是如果微软严格执行这套安全规则，数以百万计写死硬编码路径的老软件会在 Vista 上瞬间报废。

微软的做法依然是“欺骗”，假装允许访问这些系统盘，但实际上写到别的目录。

02

干脆整个框架吧！

兼容性问题越来越多，也总不能一直往 Windows 核心源码中加if else （特例）吧？

于是从Windows XP 开始，微软干脆搞了一个叫做应用程序兼容性框架的东西。

这套框架会在老程序和 Windows 之间插入一些叫 Shim 的“垫片”，必要时修改 API 的返回值、文件路径、注册表、内存管理等行为；而 SDB，则负责记录“哪个程序需要套哪些垫片”。

如果你打开C:\Windows\AppPatch，能看到一系列.sdb文件，这些都是兼容性数据库，用于记录“哪个程序需要哪些Shim”。

比如 Windows 启动《最终幻想 7》时， 从SDB发现它需要修改，找到 Win95VersionLie 这个 Shim 给它垫上，这样就可以拦截程序的系统调用。

当程序问“你是不是 Windows 95？”时，Shim 负责回答：“是。”（虽然底层的操作系统可能根本就不是Windows 95），《最终幻想 7》就正确运行了。

有意思的是，SDB不仅是微软自己用，它还提供了 Compatibility Administrator 等工具，可以让企业自己创建兼容性数据库。

03

说实话，微软的各种做法有时候真的挺匪夷所思。

一个“浓眉大眼”的现代操作系统，竟然要在底层打各种补丁、做各种“障眼法”，甚至故意恢复一些旧行为，只为了让几十年前的软件还能正常跑。

这和 iOS/Android 的风格形成了鲜明的对比：平台不断往前走，旧的硬件、API 和软件该淘汰就淘汰，开发者跟着我，赶紧升级！

微软的思路感觉就是给自己挖坑 ！

但微软也很清楚，用户升级操作系统，不代表他们愿意把过去几十年的软件资产全部扔掉。

一家公司可能还在用十几年前开发的业务系统，一家工厂可能依赖着一套没人敢轻易修改的控制软件。对他们来说，能不能运行，远比代码是否优雅重要。

Windows 的向后兼容，某种程度上就是在替用户承担历史的成本，这是它的责任，也是它在桌面市场的核心护城河。