Windows 机密Windows 95 探秘

Raymond Chen

尽管 Windows® 95 的 32 位 程序可以使用您的常用 32 位编译器，16 位程序可以使用常用的 16 位编译器，但 Windows 95 本身需要一种特殊的编译器，它熟悉 32 位和 16 位两类程序，在其间搭建桥梁。Windows 95 还需要能将两类代码结合到一起的自定义链接器，以及用于 VxD（Windows 95 的驱动程序格式）的自定义链接器。

Windows 95 团队依靠语言和工具部门提供这些特殊用途的编译器和连接器。我想语言部门一定会认为这是个奇怪的请求：“你想让我编写一个能完成多项任务的编译器，将来让它一直只编译两种 DLL？”是的，就是这样。这是两种相当重要的 DLL。

尽管这一请求表面上看起来令人费解，语言和工具部门还是完成了这项任务，将这一极其特殊的编译器和链接器纳入 Windows 95 之内。当然，编译器不是一开始就完美无瑕。Windows 团队收到的是初始版本，随后以新优化的形式定期进行了更新并修复了错误。

某一天 Windows 95 突然变得奇慢无比。原来链接文件以秒计算，现在变成以分钟计算。文件仍能成功生成，但耗时甚巨。不仅在开发人员的机器上是如此—整个团队的所有成员都遇到了这一问题。是我们的代码突然击中链接器的软肋了吗？还是链接器错误在做怪？

一翻调试之后，我们找到了问题的根源。链接器的最新版本包含一些诊断代码，在将其交给 Windows 团队前，语言部的员工忘了删除这些代码。此诊断代码将其输出记入一个文件，该文件存储在编译器团队某位成员所在办公室的计算机上。这台计算机恰好关机了。（这让我们想起 Leslie Lamport，他对分布式系统的著名论述是：一旦一台你从不知晓的计算机停机，你就会一事无成。）

这一版本的链接器已正常运行了数周。构建 Windows 95 时，每次有人试图链接 VxD 时都会对开发人员计算机上的文件进行更新。只要计算机开机并连接网络，没人会注意这一点。但是一旦计算机关机，一切就变得奇慢无比。

找到问题后，负责编译器的员工没用多久就向 Windows 团队提供了一个补丁，用它删除了链接器中的诊断代码。

不同的人员讲述这个故事时，高潮各不相同。我讲述时的高潮是：“这位编译器开发人员后来调到了 Windows 团队并成为了我的老板。”我非常乐意将这个故事当成一个无伤大雅的笑话反复宣讲。

但是，我的老板对这件事的描述截然不同。“事实证明，我没写过那个诊断代码。是我的一个同事编的，并且他不把它放在自己的机器上，却占用了我的机器！”

Raymond Chen 的网站“The Old New Thing”及同名著作均讲述了 Windows 的发展史及 Win32 编程。他对无用代码所知甚深。