Windows 命令行演变史

Windows命令行| 2018-07-21

在本文中，我们将讨论 Windows 命令行背后的一些背景和历史。具体来说，我们将探索它在 MS-DOS 中的卑微起源，到它的现代化身支持工具，如 PowerShell 和 Linux 系统中的 Windows 子系统。

本系列的帖子：

命令行的起源
Windows 命令行的演变史 (这篇文章)

在本系列的前一篇文章中，我们讨论了命令行的历史和基本原理，并了解了命令行的架构如何随着时间的推移保持基本一致，即终端从机电式电传演变为现代终端应用程序。

我们的旅程现在继续沿着一条相当复杂的道路前进，从早期的 PC 开始，通过微软与几个操作系统的合作，到今天重新焕发活力的命令行：

简陋的开始- MS-DOS

回顾计算机工业的早期，大部分的计算机都是通过输入命令到命令提示行中进行操作。基于 Unix、CP/M、DR-DOS 以及其他操作系统的计算机一起争夺领导地位及市场份额。最后，MS-DOS 脱颖而出成为 IBM 个人电脑以及组装机上的标准操作系统，特别是在商业领域。

MS-DOS 6.0

同当时大部分的主流操作系统一样，微软的 MS-DOS 的“命令行解释程序”或者“外壳程序”提供了一套简单、奇怪、但却相对有效的命令，以及一套用来写批处理（.bat）文件的命令脚本语法。

MS-DOS 迅速被大大小小的业务所采用，组合创建了几百万个批处理脚本，有些甚至今天仍然在使用。批处理脚本被用于自动化配置用户的机器，设置/变更安全设定，更新软件，编译代码等等。

由于命令行脚本都是在后台运行，所以你可能从来没有看到过命令行脚本运行。比如：登录到一台工作电脑，其实每天都有几百亿的命令行脚本和命令随同 Windows 一同运行。

由于命令行是一个需要耐心坚持学习如何使用这些绝大多数有效的命令和工具，大部分非技术用户苦于用命令行来有效地驱动他们的电脑，而大多数不喜欢的人却不得不学习记忆大量看起来不可思议的简短的命令来让他们的电脑做任何有用的事情。

所以迫切需要一个更加用户友好，更具生产力的用户体验。

图形化界面变成主流

受施乐的 Alto 启发，图形化用户界面 (GUI) 变成了主流。

很多有竞争力的 GUI 快速出现，包括苹果的 Lisa 和 Macintosh，Commodore Amiga (Workbench)，Atari ST (DRI’s GEM)，Acorn Archimedes (Arthur/RISC OS)，Sun工作站，X11/X Windows，以及其他很多，包括 Microsoft Windows：

Windows 1.0 在1985年问世, 它基本上就是一个 MS-DOS 应用程序，提供了一个简单的窗口 GUI 环境，允许用户同时运行多个应用程序：

图1：Windows 命令行演变史

Windows 1.01 运行在 MS-DOS上

Windows 2.x，3.x、95 和 98 都是在 MS-DOS 基础上运行的。虽然后来的 Windows 版本开始取代以前由 MS-DOS 提供的功能，但它们都是基于 Windows 的替代方案（例如文件系统操作），它们都依赖于它们的 MS-DOS 基础。

注意：Windows ME（千禧年版）是一个有趣的嵌合体！它最终取代了 MS-DOS 的基础和以前版本的 Windows 的实模式支持，还有一些新特性（特别是游戏和媒体技术）。一些功能是在 Windows 2000（比如新的 ip 协议栈）中加入的，在家用电脑上运行的时候，可能会很难运行。这个故事最终可能会成为一个有趣的帖子。（感谢蜜蜂对这一点的看法:)）

然而，微软知道，到目前为止，他们只能扩展 MS-DOS 和 Windows 的架构和功能：微软知道它需要一个新的操作系统来构建他们的未来。

Microsoft – Unix 市场的引领者！是的，我是认真的！

在开发 MS-DOS 的过程中，微软也在忙着交付 Xenix —— 微软的 Unix 版本 7 – 到各种处理器和机器架构，包括 Z8000、8086/80286 和 68000。

到1984年，微软的 Xenix 已经成为世界上最流行的 Unix 变体！

然而，美国政府拆分了贝尔实验室 —— Unix 的故乡 —— 导致了 AT&T 的分拆，该公司开始向电脑制造商和终端用户销售 Unix 系统 V 。

微软认为，如果没有他们自己的操作系统，他们实现未来目标的能力将受到损害。这导致了从 Xenix 转型的决定：1987年，微软将 Xenix 的所有权转让给了其合作伙伴 —— 圣克鲁斯运营公司（SCO），微软曾在 Xenix 上开发过多个项目，以在不同的平台上移植和增强 Xenix 。

微软+IBM==OS/2

1985年，微软开始与 IBM 合作开发一种名为 OS/2 的新操作系统。OS/2 最初被设计为“一个更有能力的 DOS ”，它的设计目的是利用一些现代 32 位处理器和其他来自 OEM 厂商的技术，包括 IBM 。

然而，OS/2 的故事一直是很混乱的。1990年，微软和 IBM 结束了他们的合作。这是由于许多因素造成的，包括 IBM 和微软开发人员之间的显著文化差异、日程安排的挑战，以及 Windows 3.1 采用的爆炸性成功和增长。IBM 继续开发和支持 OS/2 ，直到 2006 年底。

到1988年，微软确信它未来的成功需要一个更大、更大胆、更有野心的方法。这种方法需要一个新的、现代的操作系统来支持公司的雄心勃勃的目标。

微软的大赌注——Windows NT

1988年，微软聘请了戴夫卡特勒，他是 DEC 广受欢迎的 vax/vms 操作系统的创建者。卡特勒的目标 —— 创建一个新的、现代的、独立于平台的操作系统，微软将拥有、控制它，并将其未来的大部分时间建立在它的基础上。

这个新的操作系统变成了 Windows NT ——它发展成为 Windows 2000、Windows XP、Windows Vista、Windows 7、Windows 8 和 Windows 10 ，以及所有版本的 Windows Server、Windows Phone 7+、Xbox 和 HoloLens ！

Windows NT 从一开始就被设计为独立于平台，最初是为了支持英特尔的 i860 ，然后是 MIPS R3000，英特尔 80386+，DEC Alpha 和 PowerPC 。从那时起，Windows NT 操作系统已经被移植到支持 IA64“Itanium”、x64 和 ARM/ARM64 处理器架构等硬件。

Windows NT 通过其“Windows 控制台”终端应用程序提供了一个命令行界面，以及“命令提示”shell（cmd.exe）。Cmd 被设计成尽可能兼容 MS-DOS 的批处理脚本，以帮助简化业务对新平台的采用。

PowerShell 的力量

虽然 Cmd 仍然存在于 Windows 中（并且在未来的几十年里可能都会这样做），因为它的主要目的是尽可能保持向后兼容，Cmd 很少得到改进。甚至“修复 bug ”有时也会很困难，如果这些“bug”存在于 MS-DOS 或早期版本的 Windows 中！

在2000年早期，Cmd shell 已经失去了动力，微软和其客户迫切需要一个更强大、更灵活的命令行体验。这一需求推动了 PowerShell 的创建（这源于Jeffrey Snover的“Monad宣言”）。

PowerShell 是一种面向对象的 Shel l，与在 *NIX 世界中的基于文件/流的 Shell 不同的是：PowerShell 脚本作者能够直接访问和操作对象和它们的属性，而不是处理文本流，也不必编写和维护大量的脚本解析和操作文本(例如通过 sed / grep / awk / lex / 等等)。

建立在 . net 框架和公共语言运行时(CLR)上，PowerShell 的语言和语法是为了结合 .net 的丰富的生态系统与许多最常见的、其他有用的特性的不同的 shell ，重点确保了脚本是高度一致的，也是非常强大的。

为了解更多关于 PowerShell 的知识，我推荐阅读“PowerShell In Action”（曼宁出版社），作者是 Bruce Payette ，他是 PowerShell 语法和语言的设计者。前几章特别对语言设计的基本原理进行了有启发性的讨论。

PowerShell 已经被许多微软平台技术和合作伙伴采用，包括 Windows、Exchange Server、SQL Server、Azure 和许多其他技术，并提供了管理的命令，并以高度一致的方式控制 Windows 机器和/或环境的各个方面。

PowerShell Core，是 PowerShell 的开源未来版本，它适用于 Windows 和各种版本的 Linux、BSD 和macOS ！

在 NT、Interix 和 UNIX 服务上的 POSIX

在设计 NT 时，卡特勒和团队专门设计了 NT 内核和操作系统来支持多个子系统——用户模式代码和底层内核之间的接口。

当 Windows NT 3.1 在1993年首次发布时，它支持几个子系统：MS-DOS、Windows、os/2 v1.3 和POSIX v1.2。这些子系统允许 NT 在相同的机器和基本操作系统上运行应用程序，而不需要虚拟化或仿真——即使在今天，这也是一种强大的功能！

虽然 Windows NT 的原始 POSIX 实现是可以接受的，但是它需要显著的改进才能使它真正有能力，所以微软收购了 Softway Systems 和它的 “Interix” 的 NT 子系统。Interix 最初是作为一个单独的附加组件发布的，然后再结合几个有用的实用工具和工具，并在 Windows Server 2003 R2 和 Windows Vista 中以“Unix服务”（SFU）发布。然而，SFU 在 Windows 8 之后就停止了，主要原因是客户缺乏兴趣。

然后一件有趣的事情发生了。

Windows 10 – 新时代的 Windows 命令行！

在 Windows 10 开发初期，微软开放了一个用户反馈的页面，向社区征询在操作系统的各个方面需要什么样的功能。开发者社区强烈要求微软：

重点改进 Windows 控制台
让用户可以在 Windows 下运行 Linux 的工具

基于这些反馈，微软组建了两个新团队：

Windows 控制台&命令行团队，接管并彻底改进 Windows 控制台&命令行底层。
另一个团队负责在 Windows 10 下运行真正的、未经修改的 Linux 二进制文件 —— Windows A的 Linux 子系统（WSL）

其他的，他们都说，那是历史！

Linux 的 Windows 子系统（WSL）

基于 GNU/Linux 的“发行版”（Linux 内核的组合和用户模式工具的集合）的使用率一直在稳步增长，特别是在服务器和云计算上。虽然 Windows 有一个 POSIX 兼容的运行时，但是 SFU 缺乏运行许多 Linux 工具和二进制文件的能力，因为后者的系统调用和行为差异与传统的 Unix/POSIX 不兼容。

由于从 Windows 客户和用户那里得到的反馈，以及微软内部不断增长的需求，微软做了多次调查，并最终决定让 Windows 运行未经修改的、真正的 Linux 二进制文件！

在2014年中期，微软成立了一个团队，负责开发 Linux 的 Windows 子系统（WSL）。WSL 最初是在2016年的 Build 发布会上宣布的，之后不久就在 Windows 10 的内部版本中进行了预览。

自那以后，在大多数内部版本中，在2016年秋季发布周年纪念更新以来，WSL 的功能广度、兼容性和稳定性都有了显著的提高：当 WSL 首次发布时，这是一个有趣的实验，运行了几个常见的 Linux 工具，但未能运行许多通用的开发者工具/平台。团队快速地迭代，并且在社区的大量帮助下（感谢所有社区！），WSL 很快获得了许多新功能，使它能够运行越来越复杂的 Linux 二进制文件和工作负载。

今天(2018年中期)，WSL 能够愉快地运行大多数 Linux 二进制程序、工具、编译器、链接器、调试器等等。许多开发人员，IT专业人士，devops工程师，和许多需要运行或构建 Linux 工具、应用程序、服务的人享受显著提高的生产力，能够在同一台机器上运行自己钟爱的 Linux 工具与所有 Windows 工具，而不需要双系统。

WSL 团队继续致力于改进 WSL 执行许多 Linux 场景的能力，并改进其性能，以及与 Windows 集成的体验。

Windows 控制台重新启动和大修整

在2014年年底，Linux（WSL）构建 Windows 子系统的项目正在在全力进行中，由于对命令行的兴趣激增，Windows 控制台很明显需要一些 TLC ，按照客户和用户的经常性需求要做许多改进。

特别是，控制台缺少许多现代 NIX 兼容系统的特性，比如解析和呈现在 *NIX 世界中广泛使用的 ansi/vt 序列，用于呈现丰富的、彩色的文本和基于文本的 UI 。

那么，如果用户不能正确地查看和使用 Linux 工具，那构建 WSL 的目的是什么呢？

下面是 Windows 7 和 Windows 10 中控制台呈现的一个例子：注意，Windows 7 的控制台（左）无法正确呈现由 tmux、htop、Midnight Commander 和 cowsay 等 Linux 工具生成的 VT ，而在 Windows 10（右）中正确呈现：

图2：Windows 命令行演变史

在 Windows 7 和 Windows 10 中比较控制台

因此，在2014年，一个新的、小型的“Windows 控制台团队”成立了，负责破解、理解和改进控制台的代码库……控制台到这个时候已经28岁了——比开发它的开发人员还要老！

任何一个曾经不得不采用旧的、粗糙的、不太优化的代码库的开发人员都可以证明，对旧代码进行现代化优化通常是“棘手的”。在不破坏现有行为的情况下这样做更加困难。在不破坏数百万客户的脚本、工具、登录脚本、构建系统、制造系统、分析和生产系统等的情况下，更新所有 windows 版本中最频繁的可执行文件，需要大量的“小心和耐心”。

为应对这些挑战，团队很快就学会严格的客户的期望的控制台：例如，如果团队偏离两个控制台性能甚至百分之一，从一个构建下，警报就会在 Windows 构建团队中触发，导致…嗯…“迅速和直接反馈”，通常要求立即修复。

因此，当我们在以后的文章中讨论控制台的改进和新特性时，请记住，每项更改都有一些不可侵犯的原则，包括：

不要引入/暴露新的安全漏洞
不要破坏现有的客户（内部或外部）、工具、脚本、命令等。
不要倒退性能或增加内存消耗/IO（没有明确和良好沟通的原因）

在过去的3年里，控制台团队有：

对控制台的内部结构进行了大量的检查
- 极大地简化和减少了控制台中的代码量
- 用STL容器替换几个内部实现的集合、列表、堆栈等
- 模块化和隔离的逻辑和功能单元，使功能能够得到改进（有时也会被替换），而不需要“破坏世界”。
将几个以前独立的、不兼容的控制台引擎合并成一个
增加了许多可靠性、安全性和安全性改进
增加了解析和呈现ansi/vt序列的能力，使控制台能够准确地呈现来自NIX和其他现代命令行工具和应用程序的富文本输出
使控制台呈现24位颜色，而以前只有16种颜色！
改进控制台可访问性，使叙事者和其他UIA应用程序能够导航控制台窗口的内容
添加/改进的鼠标和触摸支持

工作仍在继续！我们目前正在完成一些令人兴奋的新特性的实现，我们将在本系列的最新文章中讨论这些特性。

所以，现在我们在哪儿呢？

如果你读到了这里，恭喜你，谢谢你！

那么，为什么要上历史课呢？

我希望你通过阅读上述历史可以理解，重要的是要了解命令行仍然是微软战略，平台和生态系统的关键组成部分。

即使微软对终端用户提供 Windows GUI ，微软和它的技术客户/用户/合作伙伴，在很大程度上依赖于 Windows 命令行来完成大量的技术任务。

事实上，如果没有一个快速、高效、稳定和安全的控制台，微软根本无法构建 Windows 本身，也无法构建任何其他软件产品。

在 MS-DOS、Unix、OS/2 和 Windows 时代的整个过程中，命令行仍然是每个技术用户工具箱中最重要的工具！即使是许多用户，他们很少在控制台中输入命令，他们自己也会每天使用控制台！当你在 Visual Studio（VS）中构建您的代码时，你的构建是在一个隐藏的控制台窗口中产生的！如果你使用 Exchange Server 或 SQL Server 的管理工具，那么其中许多命令都是通过 PowerShell 在一个隐藏的控制台执行的！

在这篇文章中，我们讨论了很多问题：我们回顾了微软的一些操作系统历史，因为它与命令行和 Windows 控制台有关。我们还了解了 Windows 控制台的起源。

在下一篇文章中，我们将开始深入研究这项技术本身。敬请期待！