Windows 命令行：深入 Windows 控制台

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

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系统中，一切都是文件

在60年代末和70年代初Unix被第一次实现的时候，其中一个核心原则就是任何东西都可以被抽象成文件流，一个关键目标是简化对设备和外设的访问处理：如果所有的设备都在系统中以文件系统的形式存在，那么现存的代码就可以不做修改地直接访问这些设备。

这个原则影响深远：你可以通过伪文件系统或虚拟文件系统来浏览和查询大量的基于*NIX的系统和机器配置，它们仅仅是”表现得“像是“文件”或“文件夹”，实际可能是机器配置或硬件。

例如，在Linux中，你可以通过访问 /proc/cpuinfo 虚拟文件节点来查看CPU的一些信息：