Windows 控制台和终端生态系统路线图

本文档是 Windows 控制台和 Windows 终端产品的概要路线图。 其中包括：

• Windows 控制台和 Windows 终端如何适应跨 Windows 和其他操作系统的命令行应用程序生态系统。

• 作为构建平台以及构建此平台的一部分的产品、功能和策略的历史记录和未来路线图。

Microsoft 当前控制台/终端时代的重点是将一流的终端体验直接带给 Windows 平台上的开发人员，并逐步淘汰经典 Windows 控制台 API，将它们替换为使用伪控制台的虚拟终端序列。 Windows 终端展示了这种向一流体验的转换，邀请开发人员社区中的开源协作，支持客户端命令行和终端托管应用程序的各种混合和匹配，并将 Windows 生态系统与所有其他平台统一起来。

定义

在继续操作之前，建议你先熟悉此空间中使用的常用术语的定义。 常见术语包括：命令行（或控制台）应用程序、标准句柄 (STDIN、STDOUT、STDERR)、TTY 和 PTY 设备、客户端和服务器、控制台子系统、控制台主机、伪控制台和终端。

体系结构

系统的常规体系结构分为四个部分：客户端、设备、服务器和终端。

客户端

客户端是一个命令行应用程序，它使用基于文本的接口来使用户能够输入命令（而不是基于鼠标的用户界面），并返回结果的文本表示形式。 在 Windows 上，控制台 API 提供客户端和设备之间的通信层。 （这也可以是包含设备控制 API 的标准控制台句柄）。

设备

设备是客户端和服务器这两个进程之间的中间消息处理通信层。 在 Windows 上为控制台驱动程序。 在其他平台上为 TTY 或 PTY 设备。 如果整个事务为纯文本，或者包含虚拟终端序列但不包含 Windows 控制台 API，则其他设备（如文件、管道和套接字）可以用作此通信通道。

服务器

服务器解释来自客户端的请求的 API 调用或消息。 在 Windows 上的经典运行模式下，服务器还会创建一个用户界面，用于向屏幕展示输出。 服务器还会收集输入，通过驱动程序将响应消息发送回客户端，就像捆绑在同一模块中的终端一样。 使用伪控制台模式时，它只是一种转换器，将以虚拟终端序列的形式将这些信息呈现给附加终端。

终端

终端是向用户提供图形显示和交互服务的最后一层。 它负责捕获输入并将其编码为虚拟终端序列，该序列最终会到达客户端的 STDIN。 它还将接收从客户端的 STDOUT 接收回来的“虚拟终端序列”并对其进行解码，以便在屏幕上显示。

进一步连接

作为附录，可以通过将充当多个角色的应用程序链接到一个终结点来执行进一步的连接。 例如，SSH 会话具有两个角色：它是在一个设备上运行的命令行应用程序“终端”，但会将接收到的所有信息转发到另一台设备上的“客户端”角色。 此链接可在设备和上下文之间无限期地发生，提供了广泛的方案灵活性。

在非 Windows 平台上，“服务器”和“终端”角色是一个单元，因为在 API 集和虚拟终端序列之间不需要转换兼容性层。

Microsoft 产品

现在，所有 Microsoft Windows 命令行产品都在 GitHub 上的开源存储库 microsoft/terminal 中提供。

Windows 控制台主机

这是用于命令行应用程序的传统 Windows 用户界面。 它处理从任何附加命令行应用程序调用的所有控制台 API 服务。 Windows 控制台还代表所有这些应用程序处理图形用户界面 (GUI) 表示形式。 它以其开源形式作为 conhost.exe 或 openconsole.exe 存在于系统目录中。 它与 Windows 操作系统一起提供。 还可以在从开源存储库构建的其他 Microsoft 产品中找到它，用于伪控制台基础结构的最新实现。 根据上面的定义，它既可以按传统的服务器和终端角色进行操作，也可以通过首选的伪控制台基础架构以仅服务器的角色进行操作。

Windows 终端

这是用于命令行应用程序的新 Windows 界面。 Windows 终端作为使用伪控制台区分 API 服务和基于文本的应用程序接口之间的问题的第一方示例，非常类似于所有非 Windows 平台。

Windows 终端是适用于 Windows 的旗舰文本模式用户界面。 它演示了生态系统的功能，并推动了 Windows 开发向与其他平台统一的方向发展。 Windows 终端也是一个示例，说明了如何构建跨 Windows API 和框架的历史和范围的强大而复杂的新式应用程序。 根据上面的定义，此产品作为终端角色进行操作。

主要历史里程碑

控制台子系统的主要历史里程碑可划分为 2014 之前的实现，然后是 2014 年以来执行的工作的概述，当时在 Windows 10 时代形成了对命令行的重新关注。

初始实现

[1989 年 - 20 世纪 90 年代] 初始控制台主机系统在 Windows 操作系统内作为 DOS 环境的模拟实现。 它的代码与命令提示符cmd.exe 纠缠在一起并协作，这是该 DOS 环境的表示形式。 控制台主机系统代码与命令提示符解释器/shell 分担责任并共享权限。 它还为其他命令行实用程序提供了基本级别的服务，以类似于 CMD 的方式执行服务。

CJK 的 DBCS

[1997-1999]大约在这个时候，引入了 DBCS 支持（“双字节字符集”）来支持 CJK（中文、日文和韩文）市场。 这项工作导致控制台内许多写入和读取方法出现分叉，既提供了处理单字节字符的“西方”版本，也提供了“东方”版本的另一种表示方式，其中需要两个字节来表示大量字符。 此分叉包括将控制台环境中单元格的表示形式扩展为 1 或 2 个单元格宽，其中 1 个单元格为窄（高度大于宽度），2个单元格为宽（全宽），或为正方形，其中可书写典型的中文、日文和韩文象形文字。

安全/隔离

[2005-2009] 具有在关键系统进程 csrss.exe 中运行控制台子系统的经验，注意到将不同访问级别的各种客户端应用程序连接到单个超关键和特权进程特别危险。 在此时代，控制台子系统拆分为客户端、驱动程序和服务器应用程序。 每个应用程序都可以在其自身的上下文中运行，从而减少每个应用程序的责任和权限。 这种隔离提高了系统的总体稳定性，因为控制台子系统中的任何故障都不再影响其他关键过程功能。

用户体验改进

[2014-2016] 在组织内各种团队对控制台子系统进行了长时间的分散维护之后，组建了一支以开发人员为中心的新团队，以主导并推动控制台的改进。 此期间的改进包括：行选择、平滑窗口大小调整、重新排列文本、复制和粘贴、高 DPI 支持以及对 Unicode 的关注，其中包括融合“西方”和“东方”存储和流操作算法之间的拆分。

虚拟终端客户端

[2015-2017] 随着适用于 Linux 的 Windows 子系统的出现，Microsoft 致力于改善 Windows 上 Docker 的体验、将 OpenSSH 作为首选命令行远程执行技术的采用以及将虚拟终端序列引入控制台主机的初始实现。 这样一来，现有控制台就可以充当终端，直接连接到各自环境中的那些 Linux 本机应用程序，将图形和文本属性呈现给显示器，并以适当的方言返回用户输入。

虚拟终端服务器

[2018] 在过去的二十年里，我们创建了收件箱控制台主机的第三方替代产品，以提高开发人员工作效率，并主要关注丰富的自定义项和选项卡式界面。 这些应用程序仍需要运行并隐藏控制台主机窗口。 当主命令行客户端应用程序运行时，它们作为辅助“客户端”应用程序附加以在轮询循环中擦除缓冲区信息。 他们的目标是成为一个终端，就像在其他平台上一样，但在 Windows 世界中，终端是不可替代的。

在此时间段内，引入了伪控制台基础结构。 伪控制台允许任何应用程序在非交互模式下启动控制台主机，并成为用户的最终终端界面。 这项工作的主要限制是 Windows 的持续兼容性承诺，即将来无限期地为所有已发布的 Windows 控制台 API 提供服务，同时提供与所有其他平台上的预期内容相匹配的替代服务器托管接口：虚拟终端序列。 因此，这项工作执行了客户端阶段的镜像：伪控制台将显示在屏幕上的内容作为委派主机的虚拟终端序列进行投影，并将响应解释为 Windows 格式的输入序列，以供客户端应用程序使用。

未来的路线图

终端应用程序

[2019 - 现在] 这是控制台子系统的开源时代，主要关注新的 Windows 终端。 Windows 终端在 2019 年 5 月的 Microsoft Build 大会期间宣布发布，它完全位于 GitHub 的 microsoft/terminal 上。 在伪控制台的优化平台之上构建 Windows 终端应用程序将成为这个时代的重点，它将直接为 Windows 平台的开发人员带来一流的终端体验。

Windows 终端不仅旨在展示该平台（包括 WinUI 接口技术、MSIX 打包模型和 C++/WinRT 组件体系结构），还可作为平台本身的验证。 Windows 终端推动 Windows 组织根据需要开放和发展应用平台，以继续提升开发人员的工作效率。 Windows 终端独特的一组高级用户和开发人员要求推动了新式 Windows 平台满足这些市场对 Windows 的真正需求。

在 Windows 操作系统中，这包括从其默认位置注销经典控制台主机用户界面，以支持 Windows 终端、ConPTY 和 虚拟终端序列。

最后，无论是 Windows 终端产品还是其他替代终端，这个时代都计划在默认体验上提供全面的选择。

客户端支持库

[未来] 借助客户端上虚拟终端序列的支持和文档，我们强烈建议 Windows 命令行实用程序开发人员首先使用虚拟终端序列，而不是使用经典 Windows API，以获得所有平台的统一生态系统的优势。 但是，一个重要的缺失是，其他平台具有大量的客户端帮助程序库，用于处理输入（如 readline）和图形显示（如 ncurses）。 这个特定的未来路线图元素表示对生态系统所提供的内容的探索，以及如何通过经典的控制台 API 加快在 Windows 命令行应用程序中采用虚拟终端序列的速度。

序列传递

[未来] 虚拟终端客户端和服务器实现的组合允许客户端命令行和终端托管应用程序的完全混合和匹配。 这种组合可以与经典 Windows 控制台 API 或虚拟终端序列通信，但是，将其转换为经典兼容的 Windows 方法，然后再返回到更通用的虚拟终端方法会产生开销。

市场充分采用 Windows 上的虚拟终端序列和 UTF-8 后，可以选择禁用控制台主机的转换/解释作业。 然后，控制台主机将成为简单的 API 调用服务程序，并通过伪控制台从设备调用中继到托管应用程序。 此更改将提高性能，并最大程度地增加可在客户端应用程序和终端之间使用的序列方言。 通过此更改，将启用其他交互方案，并（最终）使 Windows 世界与命令行应用程序空间中所有其他平台的系列保持一致。