源 /開(kāi)源中國         文 / OSC-協(xié)作翻譯

歡迎來(lái)閱讀Windows 命令行系列文章。在這篇，我們開(kāi)始深入Windows 控制臺和命令行，它是什么，你可以用它可以做什么……和它不能做什么！

系列文章：

1. 命令行產(chǎn)生的背景

2. Windows 命令行的發(fā)展

3. 深入Windows命令行（本篇）

在開(kāi)始開(kāi)發(fā)Windows NT操作系統的那時(shí)候，大概是1989年，那時(shí)候還沒(méi)有GUI（圖形化用戶(hù)界面），也沒(méi)有桌面操作系統，只有最原始的全屏的命令行界面，類(lèi)似于MS-DOS的可視化界面越來(lái)越重要！Windows GUI 開(kāi)始開(kāi)發(fā)的時(shí)候是在開(kāi)發(fā)團隊需要開(kāi)發(fā)一個(gè)基于控制臺的應用的背景下誕生的！Windows 控制臺是第一個(gè)Windows NT的GUI應用，并且可以保證兼容運行繼續使用已有的Windows應用。

Windows 控制臺最初的代碼到現在（2018年）已經(jīng)有30年的歷史……古老的東西，事實(shí)上，今天還有很多開(kāi)發(fā)者在使用它！

控制臺程序能做什么？

就像之前的文章說(shuō)的，終端的工作其實(shí)很簡(jiǎn)單：

• 處理用戶(hù)輸入：

• 可以支持的輸入設備包括鍵盤(pán)、鼠標、觸摸板、筆等等。

• 轉換輸入的數據到中間字符的或者ANSI/VT編碼格式

• 發(fā)送字符數據到已連接的應用程序或設備

• 處理應用程序輸出：

• 允許從已連接的應用程序輸出文本

• 更新屏幕上面的顯示，基于應用程序接受顯示（比如顯示文本，移動(dòng)光標，設置字體顏色等）

• 系統協(xié)調處理：

• 運行處理作業(yè)請求

• 管理設備和資源

• 支持調整窗口尺寸、最大化窗口、最小化窗口等

• 中斷請求或當信道關(guān)閉或結束處理

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

深入Windows控制臺內部

Windows控制臺是一種傳統的Win32可執行文件，雖然它最初是用“C”編寫(xiě)的，但隨著(zhù)團隊現代化和模塊化控制臺的代碼庫，大部分代碼都已正在遷移到現代C++了。

對于那些關(guān)心此類(lèi)事物的人：許多人都在詢(xún)問(wèn)Windows是用C還是C++編寫(xiě)的。答案是 - 盡管NT是基于對象的設計 - 像大多數操作系統一樣，Windows幾乎完全用C語(yǔ)言編寫(xiě)！為什么？ C++在內存占用和代碼執行開(kāi)銷(xiāo)方面引入了開(kāi)銷(xiāo)。即使在今天，使用C++編寫(xiě)的代碼的其所隱藏的開(kāi)銷(xiāo)也會(huì )令人大吃一驚，但早在1990年代后期，此時(shí)內存價(jià)格約為60$/MB（是的......每個(gè)MEGABYTE為60美元?。r(shí)，vtable等隱藏機制的內存開(kāi)銷(xiāo)非常高。此外，虛方法間接調用和對象解引用的開(kāi)銷(xiāo)可能導致當時(shí)的C++代碼存在非常顯著(zhù)的性能和規模損耗。雖然你仍然需要當心，現代C++在現代計算機上的性能開(kāi)銷(xiāo)并不是一個(gè)值得關(guān)注的問(wèn)題，同時(shí)考慮到其安全性、可讀性和可維護性方面的優(yōu)勢，這通常是一種可接受的折衷...這就是為什么我們將Console的代碼穩步升級到現代C++這樣做的原因！

那么，Windows 控制臺內部是什么樣？

在 Windows 7 之前，Windows 控制臺實(shí)例托管于核心的客戶(hù)-服務(wù)器運行子系統（Client Server Runtime Subsystem，CSRSS）！然而，在 Windows 7 中，考慮到安全性和可靠性因素，控制臺從CSRSS 中剝離出來(lái)，組件了一個(gè)包含如下二進(jìn)制文件的新家庭：

• conhost.exe - 用戶(hù)模式的 Windows 控制臺 UX 和命令行管道

• condrv.sys - 一個(gè)提供基礎通信結構的核心驅動(dòng)，連接 conhost 和命令行 Shell/工具/應用之間的通信

控制臺當前的內部結構總體結構圖就像這樣：

控制臺的核心組件包含如下內容（自下而上）：

• ConDrv.sys - 核心模式驅動(dòng)

• 請求執行 API 調用控制臺實(shí)例的數據呈現

• 從控制臺發(fā)送到命令行應用的文本

• 為控制臺及其連接的命令行應用提供高性能通信通道

• 在控制臺及附著(zhù)于其上的命令行應用這間反復傳遞 IO 控制 (IOCTL) 消息

• 管理控制臺 IOCTL 消息

• ConHost.exe - Win32 圖形界面（GUI）應用:

• 管理控制臺容器在屏幕上的布局、大小、位置等。

• 顯示并處理設置界面等。

• 調用 Windows 消息隊列，處理 Windows 消息并將用戶(hù)輸入轉換為鍵盤(pán)和鼠標事件，并將之存儲于輸入緩沖區。

• API Server: 轉換 API 調用時(shí)從命令行應用收到的 IOCTL 消息，并將文本記錄從控制臺發(fā)給命令行應用。

• API: 實(shí)現 Win32 控制臺 API，以及所有要求控制臺執行的操作背后的邏輯。

• Input Buffer: 保存由用戶(hù)輸入產(chǎn)生的鍵盤(pán)和鼠標事件記錄

• VT Parser: 如果啟動(dòng)，則從文本中解析 VT 序列，根據找到的信息產(chǎn)生等效的 API 調 I用

• Output Buffer: 保存控制臺呈現的文本。本質(zhì)上是一個(gè)二維的  CHAR_INFO 結構數組，其每個(gè)元素都包含了字符數據及其屬性（緩存區之下的更多信息）

• Other: 未包含在上層呈現，包含從注冊表或快捷文件中存儲/檢索基礎設置值。

• ConHost Core - 控制臺的內部控制和管道

• Console UX App Services - 控制臺的 UX 和 UI 層

Windows控制臺API

從上述的控制臺架構圖中可以看出，與NIX終端不同的是，控制臺發(fā)送/接收API調用和/或數據序列化為IO控制（IOCTL）消息，而不是序列化后的文本！ 甚至從（主要是Linux）命令行應用程序接收的文本中所嵌入的ANSI/VT序列也被提取、解析并轉換為API調用！

這種差異揭示了*NIX和Windows之間關(guān)鍵的基本哲學(xué)差異：在*NIX中，“一切都是文件”，然而在Windows中，“一切都是對象”！

兩種方法都有利有弊，我們將概括之，但避免在這里進(jìn)行長(cháng)篇大論。請記住，哲學(xué)中的這一關(guān)鍵差異是Windows和* NIX之間諸多差異的基礎！

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

在60年代末和70年代初Unix被第一次實(shí)現的時(shí)候，其中一個(gè)核心原則就是任何東西都可以被抽象成文件流，一個(gè)關(guān)鍵目標是簡(jiǎn)化對設備和外設的訪(fǎng)問(wèn)處理：如果所有的設備都在系統中以文件系統的形式存在，那么現存的代碼就可以不做修改地直接訪(fǎng)問(wèn)這些設備。

這個(gè)原則影響深遠：你可以通過(guò)偽文件系統或虛擬文件系統來(lái)瀏覽和查詢(xún)大量的基于*NIX的系統和機器配置，它們僅僅是”表現得“像是“文件”或“文件夾”，實(shí)際可能是機器配置或硬件。

例如，在Linux中，你可以通過(guò)訪(fǎng)問(wèn) /proc/cpuinfo 虛擬文件節點(diǎn)來(lái)查看CPU的一些信息：

這個(gè)模型是如此簡(jiǎn)單和一致，但它也存在一些額外開(kāi)銷(xiāo)：從這些偽文件中提取或查詢(xún)特殊的文本信息并從執行命令中返回，經(jīng)常需要一些工具的輔助，比如：sed，awk，perl，python等。這些工具經(jīng)常被用來(lái)寫(xiě)腳本和命令來(lái)解析文本內容、查找特殊模式、區域和值。這些腳本可以變得非常復雜，難以維護和碎片化。如果文本的結構、布局或格式發(fā)生變更，那么許多腳本也需要隨之更新。

在Windows中，任何事物都是對象

當Windows NT被設計和構建時(shí)，“對象”被視為軟件設計的未來(lái)：“面向對象”的語(yǔ)言比洞穴里的兔子更快出現 - Simula和Smalltalk已經(jīng)建立起來(lái)，而C ++正變得越來(lái)越流行。其他面向對象的語(yǔ)言，如Python，Eiffel，Objective-C，ObjectPascal / Delphi，Java，C＃等許多其他語(yǔ)言都在快速發(fā)展緊隨其后。

不可避免的是，它成型于面向對象大好時(shí)期（大約1989年）中，Windows NT的設計理念是“一切都是對象”。事實(shí)上，NT內核最重要的部分之一是“對象管理器”！

Windows NT公開(kāi)了一組豐富的Win32 API，可以調用這些API來(lái)從操作系統獲取和/或操作對象。開(kāi)發(fā)人員使用Win32 API來(lái)收集和呈現* NIX偽文件和工具提供的類(lèi)似信息，但是通過(guò)對象和結構。并且因為解析器，編譯器和分析器理解對象的結構，所以通?？梢愿绲夭东@許多編碼錯誤，從而幫助驗證程序員的意圖在語(yǔ)法和邏輯上是否正確。隨著(zhù)時(shí)間的推移，這也可以減少系統破損，波動(dòng)和“攪動(dòng)”。

所以，回到我們關(guān)于Windows控制臺的中心討論：NT團隊決定構建一個(gè)“控制臺”，它在幾個(gè)關(guān)鍵領(lǐng)域區別于傳統的* NIX終端：

1. 控制臺API：Windows Console可以通過(guò)豐富的Console API進(jìn)行操作和控制，而不是依賴(lài)程序員生成“難以驗證”的ANSI / VT序列的能力。
   

2. 公共服務(wù)：為避免每個(gè)命令行shell一次又一次地重新實(shí)現相同的服務(wù)（例如命令歷史記錄，命令別名），控制臺本身提供了一些這些服務(wù)，可通過(guò)Console API訪(fǎng)問(wèn)

Windows控制臺的問(wèn)題

雖然Console的API已經(jīng)證明在Windows命令行工具和服務(wù)領(lǐng)域非常流行，但以API為中心的模型對命令行方案提出了一些挑戰，

只有Windows實(shí)現了Console API

許多Windows命令行工具和應用程序廣泛使用Console API。

問(wèn)題呢？這些API僅適用于Windows。

因此，結合其他差異化因素（例如過(guò)程生命周期差異等），Windows命令行應用程序并不總是易于移植到* NIX，反之亦然。

因此，Windows生態(tài)系統開(kāi)發(fā)了自己的，通常類(lèi)似但通常不同的命令行工具和應用程序。這意味著(zhù)用戶(hù)在使用Windows時(shí)必須學(xué)習一組命令行應用程序和工具，shell，腳本語(yǔ)言等，而在使用* NIX時(shí)則需要學(xué)習另一組。

這個(gè)問(wèn)題沒(méi)有簡(jiǎn)單的快速解決方案：Windows控制臺和命令行不能簡(jiǎn)單地丟棄并被bash和iTerm2取代 - 有數以?xún)|計的應用程序和腳本依賴(lài)于Windows控制臺和Cmd / PowerShell shells。

像Cygwin這樣的第三方工具可以很好地將許多核心GNU工具和兼容性庫移植到Windows，但是它們無(wú)法運行未移植的，未經(jīng)修改的Linux二進(jìn)制文件。這非常重要，因為許多Ruby，Python，Node包和模塊依賴(lài)于或包裝Linux二進(jìn)制文件，或者依賴(lài)于* NIX運轉狀態(tài)。

這些原因促使微軟通過(guò)在 Windows的子系統Linux（WSL)上本地運行真正的，未經(jīng)修改的Linux二進(jìn)制文件和工具來(lái)擴展Windows的兼容性。使用WSL的用戶(hù)現在可以在同一臺機器上并行下載和安裝一個(gè)或多個(gè)Linux發(fā)行版，并使用apt / zypper / npm / gem / etc.安裝和運行絕大多數Linux命令行工具以及他們喜歡的Windows應用程序和工具。

但是，還有一些控制臺提供的東西尚未被非Microsoft終端采用：具體來(lái)說(shuō)，Windows控制臺提供命令歷史記錄和命令別名服務(wù)，從而無(wú)需每個(gè)命令行shell（特別是）重新實(shí)現相同的功能。

把 Windows 命令行遠程化是困難的

正如我們在 Command-Line Backgrounder 一文中所討論的那樣，終端最初與它們所連接的計算機是分開(kāi)的?？爝M(jìn)到今天，這種設計仍然存在：大多數現代終端和命令行應用程序/shell 等等是由進(jìn)程或機器邊界分隔的。

在基于 *NIX 的平臺上，終端和命令行應用程序的分離并通過(guò)簡(jiǎn)單的字符進(jìn)行通信的概念導致 *NIX 命令行易于從遠程計算機/設備訪(fǎng)問(wèn)和操作：只要終端和命令行應用程序可以通過(guò)某種類(lèi)型的有序串行通信基礎架構（TTY/PTY 等）傳輸字符流，遠程操作 *NIX 機器的命令行是非常簡(jiǎn)單的。

但是在 Windows 上，許多命令行應用程序依賴(lài)于調用 Console API，并假設它們與控制臺本身在同一臺機器上運行。這使得遠程操作 Windows 命令行 shell/工具等變得很困難：在遠程計算機上運行的命令行應用程序如何調用在用戶(hù)本地計算機的控制臺上的 API 呢？更糟糕的是，如果遠程命令行應用程序通過(guò) Mac 或 Linux 機器上的終端訪(fǎng)問(wèn)，它如何調用 Console API 呢？！

很抱歉開(kāi)個(gè)玩笑，但我們將在以后的文章中更詳細地闡釋這個(gè)主題！

啟動(dòng)控制臺或者不！

通常，在基于 *NIX 的系統上，當用戶(hù)想要啟動(dòng)一個(gè)命令行工具時(shí)，他們首先會(huì )啟動(dòng)一個(gè)終端。然后終端啟動(dòng)一個(gè)默認的 shell ，或者可以配置為啟動(dòng)一個(gè)特定的應用程序/工具。終端和命令行應用程序通過(guò)偽終端(PTY)交換字符流進(jìn)行通信，直到一個(gè)或兩個(gè)字符終止。

然而，在 Windows 系統上，事情就不一樣了:Windows 用戶(hù)永遠不會(huì )啟動(dòng)控制臺(conhost.exe)——然而他們會(huì )啟動(dòng)像是 Cmd.exe，PowerShell.exe，wsl.exe 等等這樣的命令行 shell 和應用程序。Windows 系統將新啟動(dòng)的應用程序連接到當前控制臺(如果是從命令行啟動(dòng)的話(huà))，或者連接到新創(chuàng )建的控制臺實(shí)例。

現在要說(shuō)的?

是的，在 Windows 系統中，用戶(hù)啟動(dòng)命令行應用程序，而不是控制臺本身。

如果用戶(hù)從現有的命令行 shell 啟動(dòng)命令行應用程序，Windows 通常會(huì )將新啟動(dòng)的 .exe（可執行文件） 附加到當前控制臺。否則，Windows 會(huì )將一個(gè)新的控制臺實(shí)例與新推出的應用程序綁定在一起。

小白說(shuō):很多人說(shuō)“命令行程序在控制臺運行”。這不是真的，而且導致很多關(guān)于控制臺和命令行應用程序如何工作的困惑！命令行應用程序和它們的控制臺都在各自獨立的 Win32 進(jìn)程中運行。請通過(guò)指出“命令行工具/應用程序連接到控制臺運行”(或類(lèi)似的)來(lái)幫助糾正這種誤解。謝謝！

聽(tīng)起來(lái)不錯,對吧?嗯…不;這里有一些問(wèn)題:

    1.控制臺和命令行應用程序通過(guò)經(jīng)由驅動(dòng)程序的 IOCTL 消息進(jìn)行通信，而不是通過(guò)文本流進(jìn)行通信

    2.windows 要求 ConHost.exe 必須是連接到命令行應用程序的控制臺程序

    3.Windows 控制了控制臺和命令行應用程序通信之間通信“管道”的創(chuàng )建

這些都是明顯的限制:如果你想為 Windows 創(chuàng )建一個(gè)替代控制臺的應用程序，該怎么辦?你將如何發(fā)送鍵盤(pán)、鼠標、筆等等外設的信息？如果你無(wú)法訪(fǎng)問(wèn)連接你新控制臺和命令行應用程序的通信“管道”，用戶(hù)將怎么對命令行應用程序進(jìn)行操作?

遺憾的是，這些情況并不好:有一些很棒的用于 Windows 的第三方控制臺(和服務(wù)器應用程序)(例如 ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH 等)，他們必須通過(guò)離奇的跳轉才能像正常的控制臺一樣運行!

舉例來(lái)說(shuō)，第三方控制臺必須在屏幕外啟動(dòng)一個(gè)命令行應用程序，例如(-32000，-32000)。然后，他們必須向屏幕外控制臺發(fā)送擊鍵信息，然后收集屏幕外控制臺的文本內容并在自己的 UI 上重新繪制它們!

我知道,這很瘋狂,對吧? !這證明了這些應用程序創(chuàng )造者們的獨創(chuàng )性和決心，這些程序甚至還在有效的運行!

這顯然是我們急于補救的一種情況。請繼續關(guān)注這部分內容的更多信息——在這方面有一些好消息!

Windows 控制臺 & VT

如上所述，Windows 控制臺提供了大量 API。使用控制臺 API，命令行應用程序和工具可寫(xiě)入文本，更改文本顏色，移動(dòng)光標等。并且，由于控制臺 API 的存在，Windows 控制臺幾乎不需要支持 ANSI/VT 序列，這些序列在其他平臺上提供非常類(lèi)似的功能。

實(shí)際上，在 Windows 10 之前，Windows 控制臺僅實(shí)現了對 ANSI/VT 序列的最低限度支持：

從2014年開(kāi)始，微軟組建了一個(gè)新的 Windows 控制臺團隊，使得這一切都發(fā)生了變化?？刂婆_團隊的最高優(yōu)先級事項之一是實(shí)現對 ANSI/VT 序列的全面支持，以便渲染在 Windows 子系統之Linux（WSL）和遠程 *NIX 機器上運行的 *NIX 應用程序的輸出。您可以在本系列的上一篇文章中閱讀更多關(guān)于這個(gè)故事的內容。

控制臺團隊迅速為 Windows 10 的控制臺添加了對 ANSI/VT 序列的全面支持，使用戶(hù)能夠使用和享用大量 Windows 和 Linux 命令行工具和應用程序。

該團隊繼續改進(jìn)和完善每個(gè)操作系統發(fā)布版本上的控制臺對 VT 的支持，并對您在我們的 GitHub 問(wèn)題跟蹤器上提交的任何問(wèn)題表示感謝。

處理Unicode

一個(gè)快速的Unicode回顧:

Unicode或ISO/IEC 10646是一個(gè)國際標準，定義了地球上幾乎每個(gè)書(shū)寫(xiě)系統中所使用的每個(gè)字符/字形，以及當今使用的許多非腳本符號和字符大小的圖像（例如表情符號）。目前（2018年7月），Unicode 11定義了137439個(gè)字符，包含146個(gè)現代和歷史文字系統！

Unicode還定義了幾種字符編碼，包括UTF-8, UTF-16, 和UTF-32:

• UTF-8: 前127個(gè)編碼點(diǎn)使用1字節（主要為了維持與ASCII的兼容性），其他字符可選附加長(cháng)度1-4字節

• UTF-16/UCS-2: 每個(gè)字符兩個(gè)字節。UCS-2 (被Windows內部使用)z支持對前65536編碼點(diǎn)（統稱(chēng)為基本多語(yǔ)言平面-BMP）。UTF-16通過(guò)17個(gè)額外的字符平面擴展了UCS-2。

• UTF-32: 每個(gè)字符4字節

由于UTF-8的高效的存儲要求以及在HTML頁(yè)面中的廣泛使用，它是目前最流行的編碼。

UTF-16/UCS-2都是常見(jiàn)的，盡管在已存儲文檔（例如網(wǎng)頁(yè)、代碼等）中其使用比例正在降低。UTF-32是很少使用的，因為它的效率低且存儲需要相當大的空間。

很好，所以我們有有效并且高效的方式來(lái)表示和存儲Unicode字符了！

所以？

哎呀，Windows控制臺及其API是在創(chuàng )建Unicode之前創(chuàng )建的！

Windows控制臺將文本（隨后在屏幕上繪制）存儲為每個(gè)單元需要2個(gè)字節的UCS-2字符。

命令行應用程序使用控制臺API將文本寫(xiě)入到控制臺中。處理文本的控制臺API有兩種形式 - 帶有A后綴處理的單字節/字符串的函數，帶有W后綴處理雙字節（wchar）/字符串的函數：

例如，WriteConsoleOutputCharacter()函數編譯為ASCII項目的WriteConsoleOutputCharacterA()，或Unicode項目的WriteConsoleOutputCharacterW()。如果需要指定處理方式，代碼中可以直接調用... A或...W后綴的函數。

注意：每個(gè)W API至少支持UCS-2，因為這是在進(jìn)行A/W拆分時(shí)就存在的事情，我們認為這樣做會(huì )很棒。但許多W API已更新為在同一渠道上也支持UTF-16
。并非所有W API都可以支持UTF-16，但所有W API至少可以支持UCS-2。

此外，控制臺不支持一些較新的Unicode功能，包括零寬度連接符（ZWJ），該符號被用于連接阿拉伯語(yǔ)和印度語(yǔ)中的其他單獨字符，并將表情符號字符組合成一個(gè)可視字形！

那么如果你想在控制臺上輸出一個(gè)ninjacat表情符號或復雜的多字節中文/阿拉伯字符會(huì )怎樣呢？ 糟糕的是，你做不到！

Console API不僅不支持長(cháng)度超過(guò)2字節/字形的Unicode字符（NinjaCat表情符號需要8個(gè)字節?。?，但Console內部的UCS-2緩沖區不能存儲該數據的額外字節，更糟糕的是 ，Console當前的基于GDI的渲染器甚至無(wú)法繪制字形，即使緩沖區可以存儲它！

可嘆！ 這就是遺留代碼的樂(lè )趣。

但是，我也會(huì )希望你們到此打住 - 我們將在本系列的新一篇文章中回到這個(gè)主題。 敬請關(guān)注！

所以，我們在哪里?

再一次，親愛(ài)的讀者，如果你讀過(guò)以上的所有內容，謝謝你，也祝賀你 —— 你現在比你的大多數朋友都更了解 Windows 控制臺，甚至可能比你想知道的還要多！祝你幸運！

在這篇文章中，我們涵蓋了很多內容:

Windows控制臺的主要構建模塊:

• API Server —— 通過(guò) IOCTL 消息向驅動(dòng)程序發(fā)送或從驅動(dòng)程序接收序列化的 API 調用和文本數據。

• API——控制臺的功能函數。

• Buffers —— 輸入緩沖用于存儲用戶(hù)輸入，輸出緩沖用于存儲輸出和顯示文本。

• 輸入緩沖存儲用戶(hù)輸入，輸出緩沖存儲輸出和顯示文本。

• VT Parser —— 將嵌入文本流的 ANSI/VT 序列轉換為 API 調用

• Console UX —— 控制臺的用戶(hù)界面狀態(tài)、設置和功能

• Other —— Misc 生命周期、安全性等。

• Condrv.sys —— 控制臺通信驅動(dòng)程序

• ConHost.exe —— 控制臺用戶(hù)體驗、內部構件和管道:

控制臺做什么？

• 向連接的命令行應用程序發(fā)送用戶(hù)輸入

• 接收并顯示連接的命令行應用程序輸出

控制臺與 *NIX 終端有什么不同

• *NIX：“一切都是文件/文本流”

• Windows：“一切都是對象，可以通過(guò) API 進(jìn)行訪(fǎng)問(wèn)”

控制臺存在的問(wèn)題

• 大部分都在 Windows 10 中得到了修復

• 只有 ConHost.exe 可以附加到命令行應用程序

• 第三方終端被迫創(chuàng )建屏幕外控制臺，并向它發(fā)送按鍵和屏幕信息，或從中接收按鍵和屏幕信息

• 遠程操作 Windows 命令行應用程序和工具存在困難

• 來(lái)自 Windows 的端口命令行 APP 的工作變得更多

• 控制臺和命令行應用程序通過(guò)序列化 API 調用請求和文本組成的 IOCTL 消息進(jìn)行通信

• 只有 Windows 命令行應用程序能調用控制臺 API

• 應用程序調用 Windows API 與控制臺交互

• 對 IOCTL 的依賴(lài)打破了“字符交換”原則的終端設計

• 使從非 Windows 機器操作遠程 Windows 命令行工具變得困難

• 啟動(dòng) Windows 命令行應用程序是“不常用的”

• Windows一直不識別ANSI/VT序列

• 控制臺對 Unicode 的支持有限，目前正在努力處理存儲和展現現代 UTF-8 和需要零寬度連接符的字符

在本系列的后續文章中，我們將深入探討控制臺，并討論如何處理這些問(wèn)題……和更多其他內容！

像往常一樣，請繼續關(guān)注我們。