脚本之家 你与百万开发者在一起 源 /开源中国 文 / OSC-协作翻译 协作翻译 原文:Windows Command-Line: Inside the Windows Console 链接: https://blogs.msdn.microsoft.com/commandline/2018/07/20/windows-command-line-inside-the-windows-console/ 译者:Tocy, 蓝水晶飞机, 云逸于海, 凉凉_, xiaoaiwhc1, 边城, ZICK_ZEON 欢迎来阅读Windows 命令行系列文章。在这篇,我们开始深入Windows 控制台和命令行,它是什么,你可以用它可以做什么……和它不能做什么! 系列文章:
在开始开发Windows NT操作系统的那时候,大概是1989年,那时候还没有GUI(图形化用户界面),也没有桌面操作系统,只有最原始的全屏的命令行界面,类似于MS-DOS的可视化界面越来越重要!Windows GUI 开始开发的时候是在开发团队需要开发一个基于控制台的应用的背景下诞生的!Windows 控制台是第一个Windows NT的GUI应用,并且可以保证兼容运行继续使用已有的Windows应用。 Windows 控制台最初的代码到现在(2018年)已经有30年的历史……古老的东西,事实上,今天还有很多开发者在使用它! 控制台程序能做什么?就像之前的文章说的,终端的工作其实很简单:
但是,Windows 控制台能做的事情有些不同: 深入Windows控制台内部Windows控制台是一种传统的Win32可执行文件,虽然它最初是用“C”编写的,但随着团队现代化和模块化控制台的代码库,大部分代码都已正在迁移到现代C++了。
那么,Windows 控制台内部是什么样?在 Windows 7 之前,Windows 控制台实例托管于核心的客户-服务器运行子系统(Client Server Runtime Subsystem,CSRSS)!然而,在 Windows 7 中,考虑到安全性和可靠性因素,控制台从CSRSS 中剥离出来,组件了一个包含如下二进制文件的新家庭:
控制台当前的内部结构总体结构图就像这样: 控制台的核心组件包含如下内容(自下而上):
Windows控制台API从上述的控制台架构图中可以看出,与NIX终端不同的是,控制台发送/接收API调用和/或数据序列化为IO控制(IOCTL)消息,而不是序列化后的文本! 甚至从(主要是Linux)命令行应用程序接收的文本中所嵌入的ANSI/VT序列也被提取、解析并转换为API调用! 这种差异揭示了*NIX和Windows之间关键的基本哲学差异:在*NIX中,“一切都是文件”,然而在Windows中,“一切都是对象”!
在 *NIX系统中,一切都是文件在60年代末和70年代初Unix被第一次实现的时候,其中一个核心原则就是任何东西都可以被抽象成文件流,一个关键目标是简化对设备和外设的访问处理:如果所有的设备都在系统中以文件系统的形式存在,那么现存的代码就可以不做修改地直接访问这些设备。 这个原则影响深远:你可以通过伪文件系统或虚拟文件系统来浏览和查询大量的基于*NIX的系统和机器配置,它们仅仅是”表现得“像是“文件”或“文件夹”,实际可能是机器配置或硬件。 例如,在Linux中,你可以通过访问 /proc/cpuinfo 虚拟文件节点来查看CPU的一些信息: 这个模型是如此简单和一致,但它也存在一些额外开销:从这些伪文件中提取或查询特殊的文本信息并从执行命令中返回,经常需要一些工具的辅助,比如:sed,awk,perl,python等。这些工具经常被用来写脚本和命令来解析文本内容、查找特殊模式、区域和值。这些脚本可以变得非常复杂,难以维护和碎片化。如果文本的结构、布局或格式发生变更,那么许多脚本也需要随之更新。 在Windows中,任何事物都是对象 当Windows NT被设计和构建时,“对象”被视为软件设计的未来:“面向对象”的语言比洞穴里的兔子更快出现 - Simula和Smalltalk已经建立起来,而C ++正变得越来越流行。其他面向对象的语言,如Python,Eiffel,Objective-C,ObjectPascal / Delphi,Java,C#等许多其他语言都在快速发展紧随其后。 不可避免的是,它成型于面向对象大好时期(大约1989年)中,Windows NT的设计理念是“一切都是对象”。事实上,NT内核最重要的部分之一是“对象管理器”! Windows NT公开了一组丰富的Win32 API,可以调用这些API来从操作系统获取和/或操作对象。开发人员使用Win32 API来收集和呈现* NIX伪文件和工具提供的类似信息,但是通过对象和结构。并且因为解析器,编译器和分析器理解对象的结构,所以通常可以更早地捕获许多编码错误,从而帮助验证程序员的意图在语法和逻辑上是否正确。随着时间的推移,这也可以减少系统破损,波动和“搅动”。 所以,回到我们关于Windows控制台的中心讨论:NT团队决定构建一个“控制台”,它在几个关键领域区别于传统的* NIX终端:
Windows控制台的问题 虽然Console的API已经证明在Windows命令行工具和服务领域非常流行,但以API为中心的模型对命令行方案提出了一些挑战, 只有Windows实现了Console API 许多Windows命令行工具和应用程序广泛使用Console API。 问题呢?这些API仅适用于Windows。 因此,结合其他差异化因素(例如过程生命周期差异等),Windows命令行应用程序并不总是易于移植到* NIX,反之亦然。 因此,Windows生态系统开发了自己的,通常类似但通常不同的命令行工具和应用程序。这意味着用户在使用Windows时必须学习一组命令行应用程序和工具,shell,脚本语言等,而在使用* NIX时则需要学习另一组。 这个问题没有简单的快速解决方案:Windows控制台和命令行不能简单地丢弃并被bash和iTerm2取代 - 有数以亿计的应用程序和脚本依赖于Windows控制台和Cmd / PowerShell shells。 像Cygwin这样的第三方工具可以很好地将许多核心GNU工具和兼容性库移植到Windows,但是它们无法运行未移植的,未经修改的Linux二进制文件。这非常重要,因为许多Ruby,Python,Node包和模块依赖于或包装Linux二进制文件,或者依赖于* NIX运转状态。 这些原因促使微软通过在 Windows的子系统Linux(WSL)上本地运行真正的,未经修改的Linux二进制文件和工具来扩展Windows的兼容性。使用WSL的用户现在可以在同一台机器上并行下载和安装一个或多个Linux发行版,并使用apt / zypper / npm / gem / etc.安装和运行绝大多数Linux命令行工具以及他们喜欢的Windows应用程序和工具。 但是,还有一些控制台提供的东西尚未被非Microsoft终端采用:具体来说,Windows控制台提供命令历史记录和命令别名服务,从而无需每个命令行shell(特别是)重新实现相同的功能。 把 Windows 命令行远程化是困难的正如我们在 Command-Line Backgrounder 一文中所讨论的那样,终端最初与它们所连接的计算机是分开的。快进到今天,这种设计仍然存在:大多数现代终端和命令行应用程序/shell 等等是由进程或机器边界分隔的。 在基于 *NIX 的平台上,终端和命令行应用程序的分离并通过简单的字符进行通信的概念导致 *NIX 命令行易于从远程计算机/设备访问和操作:只要终端和命令行应用程序可以通过某种类型的有序串行通信基础架构(TTY/PTY 等)传输字符流,远程操作 *NIX 机器的命令行是非常简单的。 但是在 Windows 上,许多命令行应用程序依赖于调用 Console API,并假设它们与控制台本身在同一台机器上运行。这使得远程操作 Windows 命令行 shell/工具等变得很困难:在远程计算机上运行的命令行应用程序如何调用在用户本地计算机的控制台上的 API 呢?更糟糕的是,如果远程命令行应用程序通过 Mac 或 Linux 机器上的终端访问,它如何调用 Console API 呢?! 很抱歉开个玩笑,但我们将在以后的文章中更详细地阐释这个主题! 启动控制台或者不!通常,在基于 *NIX 的系统上,当用户想要启动一个命令行工具时,他们首先会启动一个终端。然后终端启动一个默认的 shell ,或者可以配置为启动一个特定的应用程序/工具。终端和命令行应用程序通过伪终端(PTY)交换字符流进行通信,直到一个或两个字符终止。 然而,在 Windows 系统上,事情就不一样了:Windows 用户永远不会启动控制台(conhost.exe)——然而他们会启动像是 Cmd.exe,PowerShell.exe,wsl.exe 等等这样的命令行 shell 和应用程序。Windows 系统将新启动的应用程序连接到当前控制台(如果是从命令行启动的话),或者连接到新创建的控制台实例。 现在要说的? 是的,在 Windows 系统中,用户启动命令行应用程序,而不是控制台本身。 如果用户从现有的命令行 shell 启动命令行应用程序,Windows 通常会将新启动的 .exe(可执行文件) 附加到当前控制台。否则,Windows 会将一个新的控制台实例与新推出的应用程序绑定在一起。 小白说:很多人说“命令行程序在控制台运行”。这不是真的,而且导致很多关于控制台和命令行应用程序如何工作的困惑!命令行应用程序和它们的控制台都在各自独立的 Win32 进程中运行。请通过指出“命令行工具/应用程序连接到控制台运行”(或类似的)来帮助纠正这种误解。谢谢! 听起来不错,对吧?嗯…不;这里有一些问题: 1.控制台和命令行应用程序通过经由驱动程序的 IOCTL 消息进行通信,而不是通过文本流进行通信 2.windows 要求 ConHost.exe 必须是连接到命令行应用程序的控制台程序 3.Windows 控制了控制台和命令行应用程序通信之间通信“管道”的创建 这些都是明显的限制:如果你想为 Windows 创建一个替代控制台的应用程序,该怎么办?你将如何发送键盘、鼠标、笔等等外设的信息?如果你无法访问连接你新控制台和命令行应用程序的通信“管道”,用户将怎么对命令行应用程序进行操作? 遗憾的是,这些情况并不好:有一些很棒的用于 Windows 的第三方控制台(和服务器应用程序)(例如 ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH 等),他们必须通过离奇的跳转才能像正常的控制台一样运行! 举例来说,第三方控制台必须在屏幕外启动一个命令行应用程序,例如(-32000,-32000)。然后,他们必须向屏幕外控制台发送击键信息,然后收集屏幕外控制台的文本内容并在自己的 UI 上重新绘制它们! 我知道,这很疯狂,对吧? !这证明了这些应用程序创造者们的独创性和决心,这些程序甚至还在有效的运行! 这显然是我们急于补救的一种情况。请继续关注这部分内容的更多信息——在这方面有一些好消息! Windows 控制台 & VT如上所述,Windows 控制台提供了大量 API。使用控制台 API,命令行应用程序和工具可写入文本,更改文本颜色,移动光标等。并且,由于控制台 API 的存在,Windows 控制台几乎不需要支持 ANSI/VT 序列,这些序列在其他平台上提供非常类似的功能。 实际上,在 Windows 10 之前,Windows 控制台仅实现了对 ANSI/VT 序列的最低限度支持: 从2014年开始,微软组建了一个新的 Windows 控制台团队,使得这一切都发生了变化。控制台团队的最高优先级事项之一是实现对 ANSI/VT 序列的全面支持,以便渲染在 Windows 子系统之Linux(WSL)和远程 *NIX 机器上运行的 *NIX 应用程序的输出。您可以在本系列的上一篇文章中阅读更多关于这个故事的内容。 控制台团队迅速为 Windows 10 的控制台添加了对 ANSI/VT 序列的全面支持,使用户能够使用和享用大量 Windows 和 Linux 命令行工具和应用程序。 该团队继续改进和完善每个操作系统发布版本上的控制台对 VT 的支持,并对您在我们的 GitHub 问题跟踪器上提交的任何问题表示感谢。 处理Unicode一个快速的Unicode回顾: Unicode或ISO/IEC 10646是一个国际标准,定义了地球上几乎每个书写系统中所使用的每个字符/字形,以及当今使用的许多非脚本符号和字符大小的图像(例如表情符号)。目前(2018年7月),Unicode 11定义了137439个字符,包含146个现代和历史文字系统! Unicode还定义了几种字符编码,包括UTF-8, UTF-16, 和UTF-32:
由于UTF-8的高效的存储要求以及在HTML页面中的广泛使用,它是目前最流行的编码。 UTF-16/UCS-2都是常见的,尽管在已存储文档(例如网页、代码等)中其使用比例正在降低。UTF-32是很少使用的,因为它的效率低且存储需要相当大的空间。 很好,所以我们有有效并且高效的方式来表示和存储Unicode字符了! 所以? 哎呀,Windows控制台及其API是在创建Unicode之前创建的! Windows控制台将文本(随后在屏幕上绘制)存储为每个单元需要2个字节的UCS-2字符。 命令行应用程序使用控制台API将文本写入到控制台中。处理文本的控制台API有两种形式 - 带有A后缀处理的单字节/字符串的函数,带有W后缀处理双字节(wchar)/字符串的函数: 例如,WriteConsoleOutputCharacter()函数编译为ASCII项目的WriteConsoleOutputCharacterA(),或Unicode项目的WriteConsoleOutputCharacterW()。如果需要指定处理方式,代码中可以直接调用... A或...W后缀的函数。
此外,控制台不支持一些较新的Unicode功能,包括零宽度连接符(ZWJ),该符号被用于连接阿拉伯语和印度语中的其他单独字符,并将表情符号字符组合成一个可视字形! 那么如果你想在控制台上输出一个ninjacat表情符号或复杂的多字节中文/阿拉伯字符会怎样呢? 糟糕的是,你做不到! Console API不仅不支持长度超过2字节/字形的Unicode字符(NinjaCat表情符号需要8个字节!),但Console内部的UCS-2缓冲区不能存储该数据的额外字节,更糟糕的是 ,Console当前的基于GDI的渲染器甚至无法绘制字形,即使缓冲区可以存储它! 可叹! 这就是遗留代码的乐趣。 但是,我也会希望你们到此打住 - 我们将在本系列的新一篇文章中回到这个主题。 敬请关注! 所以,我们在哪里?再一次,亲爱的读者,如果你读过以上的所有内容,谢谢你,也祝贺你 —— 你现在比你的大多数朋友都更了解 Windows 控制台,甚至可能比你想知道的还要多!祝你幸运! 在这篇文章中,我们涵盖了很多内容: Windows控制台的主要构建模块:
控制台做什么?
控制台与 *NIX 终端有什么不同
控制台存在的问题
在本系列的后续文章中,我们将深入探讨控制台,并讨论如何处理这些问题……和更多其他内容! 像往常一样,请继续关注我们。 - END - 第22周精彩留言送书获奖名额公布 每周送书名单公布啦!请以下用户在下方留言区留下你的获奖感言,或直接加小编的微信:Zd_Daisy(记得备注哦),小编会第一时间与您联系的:
感谢大家的参与,没有中奖的用户请不要灰心,下周活动再接再励哦~ 精彩回顾 点击链接即可 ♡ 程序员马路上写代码被偷拍,网友:挣钱不容易! ♡ 各类学习视频、编程资源都在这儿,欢迎收藏~ ♡ :脚本之家粉丝福利,请查看! ♡ 学习资源 | 程序员选择哪一门编程语言入门? ♡ 听歌、看视频、下载系统等,一个网站让你少装几十款软件! ♡ 代码我只服雷布斯!分享雷军22年前写的代码 ♡ 你家里如果有一个程序员,请一定心疼他! ♡ 雷军:十年编程路,我想给程序员几点建议! ♡ 程序员都在看的这 9 篇python学习文章! ♡ 周鸿祎谈程序员创业,条条都是中肯建议 ♡ 99%的程序员都会收藏的书单,你读过几本? 长按下方图片 识别二维码 关注脚本之家 ♡ 版权声明:转载文章和图片均来自公开网络,版权归作者本人所有,推送文章除非无法确认,我们都会注明作者和来源。如果出处有误或侵犯到原作者权益与我们联系删除或授权事宜。 ---------------------------------------------------------------------------------------------------------------------- 我们尊重原创,也注重分享,文章来源于微信公众号:脚本之家,建议关注公众号查看原文。如若侵权请联系qter@qter.org。 ---------------------------------------------------------------------------------------------------------------------- |