Linux命令行厉害，其实Windows的也很强

欢迎来阅读第三篇Windows 命令行系列文章。在这篇，我们开始深入Windows 控制台和命令行，它是什么，你可以用它可以做什么……和它不能做什么！

系列文章：

1. 命令行产生的背景
2. Windows 命令行的发展
3. 深入Windows命令行（本篇）

在开始开发Windows NT操作系统的那时候，大概是1989年，那时候还没有GUI（图形化用户界面），也没有桌面操作系统，只有最原始的全屏的命令行界面，类似于MS-DOS的可视化界面越来越重要！Windows GUI 开始开发的时候是在开发团队需要开发一个基于控制台的应用的背景下诞生的！Windows 控制台是第一个Windows NT的GUI应用，并且可以保证兼容运行继续使用已有的Windows应用。

Windows 控制台最初的代码到现在（2018年）已经有30年的历史……古老的东西，事实上，今天还有很多开发者在使用它！

控制台程序能做什么？

就像之前的文章说的，终端的工作其实很简单：

• 处理用户输入：
  • 可以支持的输入设备包括键盘、鼠标、触摸板、笔等等。
  • 转换输入的数据到中间字符的或者ANSI/VT编码格式
  • 发送字符数据到已连接的应用程序或设备
• 处理应用程序输出：
  • 允许从已连接的应用程序输出文本
  • 更新屏幕上面的显示，基于应用程序接受显示（比如显示文本，移动光标，设置字体颜色等）
• 系统协调处理：
  • 运行处理作业请求
  • 管理设备和资源
  • 支持调整窗口尺寸、最大化窗口、最小化窗口等
  • 中断请求或当信道关闭或结束处理

但是，Windows 控制台能做的事情有些不同：

深入Windows控制台内部

Windows控制台是一种传统的Win32可执行文件，虽然它最初是用“C”编写的，但随着团队现代化和模块化控制台的代码库，大部分代码都已正在迁移到现代C++了。

对于那些关心此类事物的人：许多人都在询问Windows是用C还是C++编写的。答案是 - 尽管NT是基于对象的设计 - 像大多数操作系统一样，Windows几乎完全用C语言编写！为什么？ C++在内存占用和代码执行开销方面引入了开销。即使在今天，使用C++编写的代码的其所隐藏的开销也会令人大吃一惊，但早在1990年代后期，此时内存价格约为60$/MB（是的......每个MEGABYTE为60美元！）时，vtable等隐藏机制的内存开销非常高。此外，虚方法间接调用和对象解引用的开销可能导致当时的C++代码存在非常显着的性能和规模损耗。虽然你仍然需要当心，现代C++在现代计算机上的性能开销并不是一个值得关注的问题，同时考虑到其安全性、可读性和可维护性方面的优势，这通常是一种可接受的折衷...这就是为什么我们将Console的代码稳步升级到现代C++这样做的原因！

那么，Windows 控制台内部是什么样？

在 Windows 7 之前，Windows 控制台实例托管于核心的客户-服务器运行子系统（Client Server Runtime Subsystem，CSRSS）！然而，在 Windows 7 中，考虑到安全性和可靠性因素，控制台从CSRSS 中剥离出来，组件了一个包含如下二进制文件的新家庭：

• conhost.exe - 用户模式的 Windows 控制台 UX 和命令行管道
• condrv.sys - 一个提供基础通信结构的核心驱动，连接 conhost 和命令行 Shell/工具/应用之间的通信

控制台当前的内部结构总体结构图就像这样：

控制台的核心组件包含如下内容（自下而上）：

• ConDrv.sys - 核心模式驱动
  • 请求执行 API 调用控制台实例的数据呈现
  • 从控制台发送到命令行应用的文本
  • 为控制台及其连接的命令行应用提供高性能通信通道
  • 在控制台及附着于其上的命令行应用这间反复传递 IO 控制 (IOCTL) 消息
  • 管理控制台 IOCTL 消息
• ConHost.exe - Win32 图形界面（GUI）应用:
  • 管理控制台容器在屏幕上的布局、大小、位置等。
  • 显示并处理设置界面等。
  • 调用 Windows 消息队列，处理 Windows 消息并将用户输入转换为键盘和鼠标事件，并将之存储于输入缓冲区。
  • API Server: 转换 API 调用时从命令行应用收到的 IOCTL 消息，并将文本记录从控制台发给命令行应用。
  • API: 实现 Win32 控制台 API，以及所有要求控制台执行的操作背后的逻辑。
  • Input Buffer: 保存由用户输入产生的键盘和鼠标事件记录
  • VT Parser: 如果启动，则从文本中解析 VT 序列，根据找到的信息产生等效的 API 调 I用
  • Output Buffer: 保存控制台呈现的文本。本质上是一个二维的  CHAR_INFO 结构数组，其每个元素都包含了字符数据及其属性（缓存区之下的更多信息）
  • Other: 未包含在上层呈现，包含从注册表或快捷文件中存储/检索基础设置值。
  • ConHost Core - 控制台的内部控制和管道
  • Console UX App Services - 控制台的 UX 和 UI 层

Windows控制台API

从上述的控制台架构图中可以看出，与NIX终端不同的是，控制台发送/接收API调用和/或数据序列化为IO控制（IOCTL）消息，而不是序列化后的文本！ 甚至从（主要是Linux）命令行应用程序接收的文本中所嵌入的ANSI/VT序列也被提取、解析并转换为API调用！

这种差异揭示了*NIX和Windows之间关键的基本哲学差异：在*NIX中，“一切都是文件”，然而在Windows中，“一切都是对象”！

两种方法都有利有弊，我们将概括之，但避免在这里进行长篇大论。请记住，哲学中的这一关键差异是Windows和* NIX之间诸多差异的基础！

在 *NIX系统中，一切都是文件

（编辑：ASP站长网）