微软开发者博客：Windows 95安装程序团队是否忘记了MS-DOS可以处理图形？
在我们日常使用的现代操作系统中，安装过程已经变得非常复杂且功能丰富。但如果你回想起1995年发布的Windows 95，你可能会对当时的技术局限性和设计决策感到好奇。本文将探讨为什么Windows 95的安装程序选择了基于文本模式的设计，而不是利用MS-DOS的图形能力。
背景：为什么Windows 95安装程序使用了三种操作系统？
在之前的讨论中，我们提到Windows 95的安装程序实际上是依赖于三个不同的操作系统的组合来完成其任务：首先是纯DOS环境，然后是带有扩展支持的DOS，最后才是完整的Windows 95本身。这个设计选择引发了一个有趣的问题——为什么微软没有直接在MS-DOS的基础上开发一个图形化的安装程序呢？毕竟，MS-DOS确实支持图形输出。
MS-DOS真的可以做图形吗？
答案是肯定的，但问题并没有这么简单。MS-DOS本身并不主动阻止开发者使用图形，但它也没有提供任何高级的图形功能。所有的图形操作都需要开发者自行实现。除了一个用于绘制单个像素的BIOS调用之外，其他一切都需要你自己动手写代码。如果你想获得更好的性能，你就必须直接访问显存（frame buffer），而这种方式远比调用BIOS更复杂。
开发图形化安装程序需要哪些工作？
如果微软决定开发一个图形化的安装程序，他们实际上需要从零开始构建以下组件：
- 图形库：你需要编写一个能够绘制线条、矩形、文字等基本元素的图形库。幸运的是，Windows 95至少要求VGA显卡作为最低配置，所以不需要考虑更老的CGA或EGA标准。
- 窗口管理器：为了实现对话框和标准GUI界面，你需要一个简单的窗口管理器。这包括键盘支持（例如Tab键切换焦点）和热键绑定等功能。
- 多语言支持：为了支持非字母语言（如日语），你需要实现复杂的输入法系统。这通常需要专门的团队来开发，并且由于时区差异，跨地区协作可能会影响进度。
- UI控件：为了使界面更加现代化，你需要复用或重新实现一些UI团队开发的新控件。这意味着你需要与他们合作，将这些控件移植到你的自定义框架中。
- 动画和调度器：如果你希望在安装过程中加入简单的动画效果，还需要实现一个定时器调度器，以便根据硬件计时器触发事件。
结果：你实际上是在重写一个操作系统
当你把这些需求列出来后，你会发现你其实是在开发一个完整的小型操作系统！这个操作系统的目标只有一个——运行Windows 95的安装程序。虽然听起来很有趣，但从实际角度来看，这种方法会带来巨大的工作量和维护成本。
为什么不直接使用现有的解决方案？
实际上，微软已经有了一个完美的候选者：Windows 3.1运行时环境。它不仅已经经过充分调试，具备完整的视频驱动、图形库、窗口管理器、调度器以及多语言支持，而且还有专门的支持团队随时提供帮助。此外，Windows 3.1已经被广泛使用多年，拥有良好的稳定性和可靠性。
更重要的是，Windows 3.1是一个广为人知的系统，有许多现成的书籍和技术资料可以帮助新员工快速上手，而无需花费大量时间学习专为安装程序设计的小型操作系统的内部原理。
今天的教训：Windows PE
即便到了今天，Windows的安装程序依然遵循类似的模式：先安装一个小型操作系统以引导整个安装过程。现在的这个角色由Windows Preinstallation Environment（简称Windows PE）承担。这再次证明，重用现有资源往往比从头开始开发更具效率。
总结
回到最初的问题：Windows 95安装程序团队并非忘记了MS-DOS可以处理图形，而是出于实际开发成本和技术复杂性的考量，选择了更加高效和可靠的解决方案。这种权衡反映了软件工程中的一个重要原则——“不要重复发明轮子”。通过复用已有的成熟技术，开发团队可以专注于核心功能的实现，从而节省时间和资源。
希望这篇文章能帮助你更好地理解当年的技术决策背后的故事！
