微软资深开发者回顾：Windows 95的兼容性灾难，远比你想的更“惨烈”

4月9日，微软资深开发者Raymond Chen的一篇回顾文章，将我们的记忆拉回到了那个激动又混乱的年代——从Windows 3.1到Windows 95的迁移时期。

文章指出了一个可能被许多人遗忘的事实：当年遭遇的软件兼容性灾难，其规模和棘手程度，恐怕远超如今我们对Windows 11的诸多抱怨。

这不禁让人思考，我们对过去的评价，是否也戴上了一层名为“怀旧”的滤镜？

一部活的Windows秘史

说起Raymond Chen，在Windows开发圈里可谓传奇人物。他长期通过个人博客分享Windows底层那些不为人知的技术故事，堪称一部活的Windows秘史。

在最新的分享中，他详细拆解了Windows 95发布时，开发团队所面临的那片“兼容性雷区”。

一次“惊天飞跃”带来的噩梦

如今回看，Windows 95相比Windows 3.1，无疑是一次视觉与架构的“惊天飞跃”。

它首次引入了真正意义上的图形用户界面（GUI）。更重要的是，内核从16位升级到了32位，以支撑日益增长的硬件资源需求。

这听起来是巨大的进步。但对于当时海量的现有软件来说，却可能是一场噩梦的开始。

兼容性灾难的根源

问题出在哪？根源在于，许多Windows 3.1时代的程序，为了追求极致的性能或实现某些特殊功能，并没有老老实实地使用微软提供的标准API接口。

相反，开发者们各显神通，走了各种“捷径”。

• 例如，有些程序会将系统返回的句柄（Handle）直接转换为指针，然后去操作系统内部的数据结构。

这就好比，本来应该走大门进出房间，却非要自己撬开窗户，甚至拆掉墙壁。

这些取巧的手段，在Windows 3.1那个16位的“老房子”里，或许还能勉强运行。可一旦搬到Windows 95这座全新的32位“摩天大楼”里，原有的墙体结构、管道布局全都变了——之前撬窗户的方法，自然就彻底失效了。

啼笑皆非的真实案例

Raymond Chen举了一个令人啼笑皆非的例子。

当时有个程序，内置了一套严格的系统版本检测逻辑：如果检测到当前系统不是Windows 3.0、3.1或2.1，那么它就会默认判定你运行的是更古老的Windows 2.0。

结果呢？Windows 95是一个全新的主版本号，根本不在它的识别列表里。于是，这个程序便“聪明”地将Windows 95认作是Windows 2.0，并直接拒绝运行。

类似这样因为开发者“硬编码”而导致的兼容性故障，在当时可谓屡见不鲜。

微软的应对与局限

面对铺天盖地的兼容性问题，微软并非坐视不理。他们曾尝试通过发布补丁包的方式来缓解迁移阵痛，也确实解决了大量问题。

但必须承认，有一部分失败的案例，由于其根源在于应用程序代码对系统底层的“非法入侵”，从根本上就无法通过外部修补来修复。

Chen在文章中很客观地指出，虽然这些兼容性问题的根源在于第三方开发者的不规范写法，而非微软的系统设计缺陷。

然而，从最终用户的视角来看，体验就是一切——程序无法运行，就是糟糕的体验，这一点毋庸置疑。

结论：被滤镜掩盖的“惨烈”战场

那么，他的结论是什么呢？

Chen认为，除了微软对硬件安全标准（如TPM 2.0）的严格要求引发了一些升级门槛外，Windows 11用户在软件兼容性方面，其实并未遭遇真正意义上的、普遍性的严重问题。

当很多人觉得Windows 11是“史上体验最差”的系统时，或许我们只是在用怀旧的滤镜看待过去，而忘记了技术演进史上那些真正“惨烈”的兼容性战场。

《夸克》非常好用的免费AI浏览器

下载APP查看