好文翻譯丨一文看懂Windows 命令行的演變史

一個程序員專屬的APP

參與翻譯 (4人) : 雪落無痕xdj, kevinlinkai, 邊城, whysln

歡迎來到「Windows 命令行」系列的第二篇文章。在本文中，我們將討論 Windows 命令行背後的一些背景和歷史。具體來說，我們將探索它在 MS-DOS 中的卑微起源，到它的現代化身支持工具，如 PowerShell 和 Linux 系統中的 Windows 子系統。

本系列的帖子：

1. 命令行的起源
2. Windows 命令行的演變史 (這篇文章)

在本系列的前一篇文章中，我們討論了命令行的歷史和基本原理，並了解了命令行的架構如何隨著時間的推移保持基本一致，即終端從機電式電傳演變為現代終端應用程序。

我們的旅程現在繼續沿著一條相當複雜的道路前進，從早期的 PC 開始，通過微軟與幾個操作系統的合作，到今天重新煥發活力的命令行：

簡陋的開始- MS-DOS

回顧計算機工業的早期，大部分的計算機都是通過輸入命令到命令提示行中進行操作。基於 Unix、CP/M、DR-DOS 以及其他操作系統的計算機一起爭奪領導地位及市場份額。最後，MS-DOS 脫穎而出成為 IBM 個人電腦以及組裝機上的標準操作系統，特別是在商業領域。

MS-DOS 6.0

同當時大部分的主流操作系統一樣，微軟的 MS-DOS 的「命令行解釋程序」或者「外殼程序」提供了一套簡單、奇怪、但卻相對有效的命令，以及一套用來寫批處理（.bat）文件的命令腳本語法。

MS-DOS 迅速被大大小小的業務所採用，組合創建了幾百萬個批處理腳本，有些甚至今天仍然在使用。批處理腳本被用於自動化配置用戶的機器，設置/變更安全設定，更新軟體，編譯代碼等等。

由於命令行腳本都是在後台運行，所以你可能從來沒有看到過命令行腳本運行。比如：登錄到一台工作電腦，其實每天都有幾百億的命令行腳本和命令隨同 Windows 一同運行。

由於命令行是一個需要耐心堅持學習如何使用這些絕大多數有效的命令和工具，大部分非技術用戶苦於用命令行來有效地驅動他們的電腦，而大多數不喜歡的人卻不得不學習記憶大量看起來不可思議的簡短的命令來讓他們的電腦做任何有用的事情。

所以迫切需要一個更加用戶友好，更具生產力的用戶體驗。

圖形化界面變成主流

受施樂的 Alto 啟發，圖形化用戶界面 (GUI) 變成了主流。

很多有競爭力的 GUI 快速出現，包括蘋果的 Lisa 和 Macintosh，Commodore Amiga (Workbench)，Atari ST (DRI"s GEM)，Acorn Archimedes (Arthur/RISC OS)，Sun工作站，X11/X Windows，以及其他很多，包括 Microsoft Windows：

Windows 1.0 在1985年問世, 它基本上就是一個 MS-DOS 應用程序，提供了一個簡單的窗口 GUI 環境，允許用戶同時運行多個應用程序：

Windows 1.01 運行在 MS-DOS上

Windows 2.x，3.x、95 和 98 都是在 MS-DOS 基礎上運行的。雖然後來的 Windows 版本開始取代以前由 MS-DOS 提供的功能，但它們都是基於 Windows 的替代方案（例如文件系統操作），它們都依賴於它們的 MS-DOS 基礎。

注意：Windows ME（千禧年版）是一個有趣的嵌合體！它最終取代了 MS-DOS 的基礎和以前版本的 Windows 的實模式支持，還有一些新特性（特別是遊戲和媒體技術）。一些功能是在 Windows 2000（比如新的 ip 協議棧）中加入的，在家用電腦上運行的時候，可能會很難運行。這個故事最終可能會成為一個有趣的帖子。（感謝蜜蜂對這一點的看法:)）

然而，微軟知道，到目前為止，他們只能擴展 MS-DOS 和 Windows 的架構和功能：微軟知道它需要一個新的操作系統來構建他們的未來。

Microsoft - Unix 市場的引領者！是的，我是認真的！

在開發 MS-DOS 的過程中，微軟也在忙著交付 Xenix —— 微軟的 Unix 版本 7 - 到各種處理器和機器架構，包括 Z8000、8086/80286 和 68000。

到1984年，微軟的 Xenix 已經成為世界上最流行的 Unix 變體！

然而，美國政府拆分了貝爾實驗室 —— Unix 的故鄉 —— 導致了 AT&T 的分拆，該公司開始向電腦製造商和終端用戶銷售 Unix 系統 V 。

微軟認為，如果沒有他們自己的操作系統，他們實現未來目標的能力將受到損害。這導致了從 Xenix 轉型的決定：1987年，微軟將 Xenix 的所有權轉讓給了其合作夥伴 —— 聖克魯斯運營公司（SCO），微軟曾在 Xenix 上開發過多個項目，以在不同的平台上移植和增強 Xenix 。

微軟+IBM==OS/2

1985年，微軟開始與 IBM 合作開發一種名為 OS/2 的新操作系統。OS/2 最初被設計為「一個更有能力的 DOS 」，它的設計目的是利用一些現代 32 位處理器和其他來自 OEM 廠商的技術，包括 IBM 。

然而，OS/2 的故事一直是很混亂的。1990年，微軟和 IBM 結束了他們的合作。這是由於許多因素造成的，包括 IBM 和微軟開發人員之間的顯著文化差異、日程安排的挑戰，以及 Windows 3.1 採用的爆炸性成功和增長。IBM 繼續開發和支持 OS/2 ，直到 2006 年底。

到1988年，微軟確信它未來的成功需要一個更大、更大膽、更有野心的方法。這種方法需要一個新的、現代的操作系統來支持公司的雄心勃勃的目標。

微軟的大賭注——Windows NT

1988年，微軟聘請了戴夫卡特勒，他是 DEC 廣受歡迎的 vax/vms 操作系統的創建者。卡特勒的目標 —— 創建一個新的、現代的、獨立於平台的操作系統，微軟將擁有、控制它，並將其未來的大部分時間建立在它的基礎上。

這個新的操作系統變成了 Windows NT ——它發展成為 Windows 2000、Windows XP、Windows Vista、Windows 7、Windows 8 和 Windows 10 ，以及所有版本的 Windows Server、Windows Phone 7+、Xbox 和 HoloLens ！

Windows NT 從一開始就被設計為獨立於平台，最初是為了支持英特爾的 i860 ，然後是 MIPS R3000，英特爾 80386+，DEC Alpha 和 PowerPC 。從那時起，Windows NT 操作系統已經被移植到支持 IA64「Itanium」、x64 和 ARM/ARM64 處理器架構等硬體。

Windows NT 通過其「Windows 控制台」終端應用程序提供了一個命令行界面，以及「命令提示」shell（cmd.exe）。Cmd 被設計成儘可能兼容 MS-DOS 的批處理腳本，以幫助簡化業務對新平台的採用。

PowerShell 的力量

雖然 Cmd 仍然存在於 Windows 中（並且在未來的幾十年里可能都會這樣做），因為它的主要目的是儘可能保持向後兼容，Cmd 很少得到改進。甚至「修復 bug 」有時也會很困難，如果這些「bug」存在於 MS-DOS 或早期版本的 Windows 中！

在2000年早期，Cmd shell 已經失去了動力，微軟和其客戶迫切需要一個更強大、更靈活的命令行體驗。這一需求推動了 PowerShell 的創建（這源於Jeffrey Snover的「Monad宣言」）。

PowerShell 是一種面向對象的 Shel l，與在 *NIX 世界中的基於文件/流的 Shell 不同的是：PowerShell 腳本作者能夠直接訪問和操作對象和它們的屬性，而不是處理文本流，也不必編寫和維護大量的腳本解析和操作文本(例如通過 sed / grep / awk / lex / 等等)。

建立在 . net 框架和公共語言運行時(CLR)上，PowerShell 的語言和語法是為了結合 .net 的豐富的生態系統與許多最常見的、其他有用的特性的不同的 shell ，重點確保了腳本是高度一致的，也是非常強大的。

為了解更多關於 PowerShell 的知識，我推薦閱讀「PowerShell In Action」（曼寧出版社），作者是 Bruce Payette ，他是 PowerShell 語法和語言的設計者。前幾章特別對語言設計的基本原理進行了有啟發性的討論。

PowerShell 已經被許多微軟平台技術和合作夥伴採用，包括 Windows、Exchange Server、SQL Server、Azure 和許多其他技術，並提供了管理的命令，並以高度一致的方式控制 Windows 機器和/或環境的各個方面。

PowerShell Core，是 PowerShell 的開源未來版本，它適用於 Windows 和各種版本的 Linux、BSD 和macOS ！

在 NT、Interix 和 UNIX 服務上的 POSIX

在設計 NT 時，卡特勒和團隊專門設計了 NT 內核和操作系統來支持多個子系統——用戶模式代碼和底層內核之間的介面。

當 Windows NT 3.1 在1993年首次發布時，它支持幾個子系統：MS-DOS、Windows、os/2 v1.3 和POSIX v1.2。這些子系統允許 NT 在相同的機器和基本操作系統上運行應用程序，而不需要虛擬化或模擬——即使在今天，這也是一種強大的功能！

雖然 Windows NT 的原始 POSIX 實現是可以接受的，但是它需要顯著的改進才能使它真正有能力，所以微軟收購了 Softway Systems 和它的 「Interix」 的 NT 子系統。Interix 最初是作為一個單獨的附加組件發布的，然後再結合幾個有用的實用工具和工具，並在 Windows Server 2003 R2 和 Windows Vista 中以「Unix服務」（SFU）發布。然而，SFU 在 Windows 8 之後就停止了，主要原因是客戶缺乏興趣。

然後一件有趣的事情發生了。

Windows 10 - 新時代的 Windows 命令行！

在 Windows 10 開發初期，微軟開放了一個用戶反饋的頁面，向社區徵詢在操作系統的各個方面需要什麼樣的功能。開發者社區強烈要求微軟：

1. 重點改進 Windows 控制台
2. 讓用戶可以在 Windows 下運行 Linux 的工具

基於這些反饋，微軟組建了兩個新團隊：

1. Windows 控制台&命令行團隊，接管並徹底改進 Windows 控制台&命令行底層。
2. 另一個團隊負責在 Windows 10 下運行真正的、未經修改的 Linux 二進位文件 —— Windows A的 Linux 子系統（WSL）

其他的，他們都說，那是歷史！

Linux 的 Windows 子系統（WSL）

基於 GNU/Linux 的「發行版」（Linux 內核的組合和用戶模式工具的集合）的使用率一直在穩步增長，特別是在伺服器和雲計算上。雖然 Windows 有一個 POSIX 兼容的運行時，但是 SFU 缺乏運行許多 Linux 工具和二進位文件的能力，因為後者的系統調用和行為差異與傳統的 Unix/POSIX 不兼容。

由於從 Windows 客戶和用戶那裡得到的反饋，以及微軟內部不斷增長的需求，微軟做了多次調查，並最終決定讓 Windows 運行未經修改的、真正的 Linux 二進位文件！

在2014年中期，微軟成立了一個團隊，負責開發 Linux 的 Windows 子系統（WSL）。WSL 最初是在2016年的 Build 發布會上宣布的，之後不久就在 Windows 10 的內部版本中進行了預覽。

自那以後，在大多數內部版本中，在2016年秋季發布周年紀念更新以來，WSL 的功能廣度、兼容性和穩定性都有了顯著的提高：當 WSL 首次發布時，這是一個有趣的實驗，運行了幾個常見的 Linux 工具，但未能運行許多通用的開發者工具/平台。團隊快速地迭代，並且在社區的大量幫助下（感謝所有社區！），WSL 很快獲得了許多新功能，使它能夠運行越來越複雜的 Linux 二進位文件和工作負載。

今天(2018年中期)，WSL 能夠愉快地運行大多數 Linux 二進位程序、工具、編譯器、鏈接器、調試器等等。許多開發人員，IT專業人士，devops工程師，和許多需要運行或構建 Linux 工具、應用程序、服務的人享受顯著提高的生產力，能夠在同一台機器上運行自己鍾愛的 Linux 工具與所有 Windows 工具，而不需要雙系統。

WSL 團隊繼續致力於改進 WSL 執行許多 Linux 場景的能力，並改進其性能，以及與 Windows 集成的體驗。

Windows 控制台重新啟動和大修整

在2014年年底，Linux（WSL）構建 Windows 子系統的項目正在在全力進行中，由於對命令行的興趣激增，Windows 控制台很明顯需要一些 TLC ，按照客戶和用戶的經常性需求要做許多改進。

特別是，控制台缺少許多現代 NIX 兼容系統的特性，比如解析和呈現在 *NIX 世界中廣泛使用的 ansi/vt 序列，用於呈現豐富的、彩色的文本和基於文本的 UI 。

那麼，如果用戶不能正確地查看和使用 Linux 工具，那構建 WSL 的目的是什麼呢？

下面是 Windows 7 和 Windows 10 中控制台呈現的一個例子：注意，Windows 7 的控制台（左）無法正確呈現由 tmux、htop、Midnight Commander 和 cowsay 等 Linux 工具生成的 VT ，而在 Windows 10（右）中正確呈現：

在 Windows 7 和 Windows 10 中比較控制台

因此，在2014年，一個新的、小型的「Windows 控制台團隊」成立了，負責破解、理解和改進控制台的代碼庫……控制台到這個時候已經28歲了——比開發它的開發人員還要老！

任何一個曾經不得不採用舊的、粗糙的、不太優化的代碼庫的開發人員都可以證明，對舊代碼進行現代化優化通常是「棘手的」。在不破壞現有行為的情況下這樣做更加困難。在不破壞數百萬客戶的腳本、工具、登錄腳本、構建系統、製造系統、分析和生產系統等的情況下，更新所有 windows 版本中最頻繁的可執行文件，需要大量的「小心和耐心」。

為應對這些挑戰，團隊很快就學會嚴格的客戶的期望的控制台：例如，如果團隊偏離兩個控制台性能甚至百分之一，從一個構建下，警報就會在 Windows 構建團隊中觸發，導致…嗯…「迅速和直接反饋」，通常要求立即修復。

因此，當我們在以後的文章中討論控制台的改進和新特性時，請記住，每項更改都有一些不可侵犯的原則，包括：

1. 不要引入/暴露新的安全漏洞
2. 不要破壞現有的客戶（內部或外部）、工具、腳本、命令等。
3. 不要倒退性能或增加內存消耗/IO（沒有明確和良好溝通的原因）

在過去的3年里，控制台團隊有：

• 對控制台的內部結構進行了大量的檢查
• 極大地簡化和減少了控制台中的代碼量
• 用STL容器替換幾個內部實現的集合、列表、堆棧等
• 模塊化和隔離的邏輯和功能單元，使功能能夠得到改進（有時也會被替換），而不需要「破壞世界」。
• 將幾個以前獨立的、不兼容的控制台引擎合併成一個
• 增加了許多可靠性、安全性和安全性改進
• 增加了解析和呈現ansi/vt序列的能力，使控制台能夠準確地呈現來自NIX和其他現代命令行工具和應用程序的富文本輸出
• 使控制台呈現24位顏色，而以前只有16種顏色！
• 改進控制台可訪問性，使敘事者和其他UIA應用程序能夠導航控制台窗口的內容
• 添加/改進的滑鼠和觸摸支持

工作仍在繼續！我們目前正在完成一些令人興奮的新特性的實現，我們將在本系列的最新文章中討論這些特性。

所以，現在我們在哪兒呢？

如果你讀到了這裡，恭喜你，謝謝你！

那麼，為什麼要上歷史課呢？

我希望你通過閱讀上述歷史可以理解，重要的是要了解命令行仍然是微軟戰略，平台和生態系統的關鍵組成部分。

即使微軟對終端用戶提供 Windows GUI ，微軟和它的技術客戶/用戶/合作夥伴，在很大程度上依賴於 Windows 命令行來完成大量的技術任務。

事實上，如果沒有一個快速、高效、穩定和安全的控制台，微軟根本無法構建 Windows 本身，也無法構建任何其他軟體產品。

在 MS-DOS、Unix、OS/2 和 Windows 時代的整個過程中，命令行仍然是每個技術用戶工具箱中最重要的工具！即使是許多用戶，他們很少在控制台中輸入命令，他們自己也會每天使用控制台！當你在 Visual Studio（VS）中構建您的代碼時，你的構建是在一個隱藏的控制台窗口中產生的！如果你使用 Exchange Server 或 SQL Server 的管理工具，那麼其中許多命令都是通過 PowerShell 在一個隱藏的控制台執行的！

在這篇文章中，我們討論了很多問題：我們回顧了微軟的一些操作系統歷史，因為它與命令行和 Windows 控制台有關。我們還了解了 Windows 控制台的起源。

在下一篇文章中，我們將開始深入研究這項技術本身。敬請期待！

對於技術達人來說，廣納知識點是進步的源泉。通過閱讀技術文章我們可以學到業務技能，也能了解行業動態。開源中國翻譯頻道旨在每天為用戶推薦並翻譯優質的外網文章。再也不用怕因為英語不過關，被擋在許多技術文章的門外。點擊「了解更多」閱讀原文章，查看該系列其他文章。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！