Windows 命令行的演变史

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

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

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

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

1、不要引入/暴露新的安全漏洞

2、不要破坏现有的客户（内部或外部）、工具、脚本、命令等。

3、不要倒退性能或增加内存消耗/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 控制台的起源。

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