2026 年 5 月，微软 Azure 首席技术官 Mark Russinovich 对着镜头说了一句话：
"90 年代有谁会预料到，Win32 在 2026 年仍然是一等 API？我可以安全地回答——没有。"
他顿了顿，又补了一句：
"2026 年应该有飞行汽车了，而不是 Win32。"
这句话在开发者社区炸了锅。
不是因为他说错了。
而是因为，一个市值三万亿美元的公司，它的首席技术官，亲口承认：
我们花了三十年，没能换掉自己最老的那块地基。
你有没有想过，为什么？
一个从 DEC 挖来的人
故事要从 1988 年讲起。
那一年，比尔 · 盖茨做了一件当时很多人看不懂的事：他从 DEC 公司挖走了 Dave Cutler。
Cutler 是谁？
VMS 操作系统的首席架构师。那个年代，VMS 是企业级操作系统的天花板。抢占式多任务、虚拟内存、对称多处理——这些概念在 80 年代末，绝大多数程序员听都没听过。
盖茨要他做一件事：
给微软写一个 " 真正的 " 操作系统。
注意，是 " 真正的 "。
因为当时的 Windows 3.x，说白了，只是 DOS 上面套了一层图形壳子。没有内存保护，没有真正的多任务，一个程序崩溃，整个系统跟着死。
Cutler 带了二十多个 DEC 的老部下，在雷德蒙德扎了五年。
花了 1.5 亿美元。
1993 年，Windows NT 3.1 发布。
Win32 API，就是在那一刻诞生的。
它本来应该被替换掉
事情真的是这样吗？
Win32 从设计之初，就不是一个 " 永恒方案 "。
Cutler 的团队很清楚，这套 C 风格的 API 笨重、啰嗦、充满历史包袱。光是创建一个窗口，你就得写几十行模板代码。
微软自己比谁都清楚这一点。
所以从 1998 年开始，他们启动了一轮又一轮的 " 替代计划 "：
MFC，封装 Win32，让 C++ 程序员少写点代码。
WinForms，.NET 时代的 GUI 方案。
WPF，号称 " 下一代 Windows 界面 "。
Silverlight，跨平台富客户端。
WinRT，Windows 8 的全新运行时。
UWP，" 通用 Windows 平台 "，微软押上全部身家的未来。
你数数，六次。
二十年间，微软至少六次试图埋葬 Win32。
结果呢？
全部失败。
MFC 成了遗产代码的代名词。Silverlight 2021 年彻底停止支持。UWP？连微软自己的应用都在往回迁。
如果你是当年的工程师，你会怎么选？
你面前有两条路：
一条，花三年重写所有东西，赌用户愿意跟着你迁移。
另一条，在老地基上继续盖楼，丑是丑了点，但不会塌。
微软选了六次第一条路。
市场替它选了六次第二条。
真正的问题不是技术
看到这里，也许你会觉得：
是不是 Win32 设计得太好了？好到不需要替换？
不是。
Win32 的设计有很多问题。调用约定混乱，ANSI 和 Unicode 双版本并存，错误处理靠返回值而不是异常，文档里到处是 " 此函数已弃用，但仍可用 "。
Raymond Chen ——那个在微软干了三十多年、写了 "The Old New Thing" 博客的传奇工程师——讲过无数这样的故事：
某个游戏在 Windows 95 上依赖了一个未定义行为。
到了 Windows XP，团队修了这个行为。
游戏崩了。
用户投诉信像雪片一样飞来。
最后怎么办？
Windows 团队加了一段特殊代码：如果检测到是这个游戏的进程，就恢复那个 " 错误 " 的行为。
这不是段子。这是真实发生的工程决策。
真正的问题来了：
为什么微软不能像苹果那样，说一句 " 旧应用不兼容了，大家重新适配 "？
答案只有一个词：
生态。
一份三十年的合同
1995 年，Windows 95 发布。
那一年，全球有几十万开发者用 Win32 API 写软件。银行系统、医院管理系统、工厂控制软件、会计软件、ERP ……
这些软件，不是写一次就扔的。
一家德国工厂 1997 年用 Win32 写的产线控制系统，到 2020 年还在跑。
一家日本银行 2001 年开发的柜台终端程序，到 2025 年还在用。
它们不会重写。
因为重写的成本，远远超过继续运行的成本。
因为写这些程序的人，可能已经退休了。
因为文档可能已经丢了。
因为没有人敢碰一个 " 正在正常运行 " 的系统。
Windows 的兼容性，不是一项技术特性。
它是一份合同。
微软对全世界几百万开发者说：你在我这里写的代码，我保证它十年后、二十年后、三十年后还能跑。
这份合同，没有写在任何法律文件里。
但它比任何法律文件都有约束力。
因为一旦撕毁，开发者就会离开。
而开发者一旦离开，Windows 就不再是 Windows。
代价是什么？
如果故事到这里结束，它就不会改变世界。
代价是巨大的。
Windows 11 的安装包里，藏着大量你永远不会用到的兼容层。SysWOW64 目录里跑着 32 位模拟。注册表里塞满了为特定应用准备的 shim。
每一次 Windows 更新，测试团队要验证的不只是 " 新功能能不能用 "，还有 " 三十年前的老程序会不会挂 "。
这就是为什么 Windows 更新总是那么慢、那么谨慎、那么让人焦虑。
不是工程师不行。
是他们背着一座山在跑步。
苹果可以轻装上阵，因为 macOS 的用户基数小，企业渗透率低，开发者社区相对集中。
Linux 可以更激进，因为它的用户大多是自己编译、自己折腾的技术人群。
Windows 不行。
Windows 的用户是全球十五亿台设备。是医院、是学校、是政府窗口、是你妈的电脑。
它不能 " 快速迭代，打破常规 "。
它只能背着三十年的包袱，一步一步往前走。
今天，这个思想还活着吗？
2026 年的技术世界，到处都在讲 " 颠覆 "。
Rust 要颠覆 C。
容器要颠覆虚拟机。
LLM 要颠覆编程本身。
但你仔细看——
Docker 的核心思想是什么？
是 " 我保证你的应用在任何机器上行为一致 "。
这不就是 Win32 当年做的事吗？
Kubernetes 的 API 为什么从 1.0 到现在几乎不破坏兼容性？
因为 Google 知道，一旦破坏，几百万个 YAML 文件就变成废纸。
Linux 内核为什么坚持 " 永远不破坏用户空间 ABI"？
Linus Torvalds 说过一句著名的话：
" 我们不破坏用户空间。这是规则。"
这不是保守。
这是对生态的敬畏。
当然，也有人在走另一条路。
Apple 从 Intel 切到 ARM，干脆利落。
Google 的 Android 每个大版本都在改 API。
Rust 社区每年都在讨论 " 要不要稳定 1.0 之前的某些行为 "。
两种选择，没有对错。
但 Windows 的故事告诉我们一件事：
当你承诺了兼容，你就不再只是一家公司。你成了一种基础设施。而基础设施，是不能随便拆的。
Win32 活到今天，不是因为它优雅。
不是因为它高效。
不是因为没人想杀它。
而是因为杀它的代价，比养它更大。
这才是工程世界最残酷的真相：
真正决定一个技术生死的，从来不是技术本身。而是有多少人，把命运押在了它上面。
