如果把操作系统的发展史比作《三国演义》那么本文更像《三国演义》而不是《三国志》。本系列尝试用故事化的方式讲述 Unix、Linux、BSD、GNU、Windows、macOS、Android 等操作系统背后的发展历程。文中的人物、事件和技术演进都尽量参考公开资料但为了让故事更容易理解会适当简化一些历史细节也会加入作者自己的理解。它不是一篇学术论文而是一段程序员视角的技术故事。如果读完之后你产生兴趣愿意继续查阅官方资料那这篇文章的目的就达到了。引子Windows 不是 Unix但 Windows 里却住进了 Linux上一篇我们讲了 Windows。一路从MS-DOS ↓ Windows 3.x ↓ Windows 95 / 98讲到了另一条真正通往现代 Windows 的道路Windows NT ↓ Windows 2000 ↓ Windows XP ↓ Windows 7 ↓ Windows 10 ↓ Windows 11最后得出了一个很明确的结论Windows 不是 Unix。今天 Windows 11 的核心血统仍然来自 Windows NT而不是 Unix、BSD 或 Linux。但是。如果今天你打开一台程序员使用的 Windows 电脑。事情可能会变得非常奇怪。打开 Windows Terminal。输入wsl然后uname -a你看到的居然是Linux再输入ls grep sed awk ssh gcc python全部能跑。甚至sudo apt update也没有问题。Windows 还是 Windows。Windows NT 还是 Windows NT。可是Linux 居然真的住进 Windows 里了。这件事如果放到 1990 年代来看。多少有点魔幻。因为在那个年代微软和 Unix。Windows 和 Linux。几乎像两个世界。那么问题来了一个没有 Unix 血统、甚至长期建立自己独立生态的 Windows为什么后来反而越来越主动地拥抱 Unix/Linux 世界而且WSL 并不是这个故事的开始。在它之前。程序员已经折腾了二十多年。Cygwin。MinGW。MSYS。MSYS2。Interix。Services for UNIX。直到最后WSL。Windows 和 Unix 的这场相遇。其实远比想象中漫长。第一章两个世界最早真的很不一样今天很多程序员已经习惯Windows 上写代码。Linux 上部署。macOS 上开发。GitHub 上协作。Docker 里运行。整个工具链已经混在了一起。但在 1990 年代。Windows 和 Unix 的差异非常明显。Unix 程序员习惯ls grep sed awk make gcc shWindows 程序员则生活在C:\以及Win32 API Visual C cmd.exe里面。Unix 喜欢/home/user /usr/bin /etc /devWindows 则是C:\Users C:\Windows C:\Program FilesUnix 创建进程。很多程序天然假设fork()存在。Windows 则有自己的CreateProcess()Unix 程序喜欢 Shell。喜欢管道。喜欢一个程序只做一件事再把很多小工具组合起来。Windows 世界则成长出了另一套完全不同的 API、工具链和软件文化。结果一个问题越来越明显如果我在 Unix 上有大量现成软件怎么把它拿到 Windows 上重新写一遍理论上当然可以。可现实是一个大型 Unix 项目。里面可能到处都是fork signal pipe select pthread POSIX path shell script makefile让程序员全部改成 Win32。工程师大概只想回答要不还是算了。于是有人开始想另外一条路。第二章Cygwin——既然 Windows 不是 Unix那就在上面“造”一个 Unix1995 年。Cygnus Solutions 开始开发一个后来非常有名的项目Cygwin。它的思路非常有意思。Windows 没有 Unix 那些东西那我就在 Windows 和 Unix 程序之间加一个翻译层。Cygwin 最核心的东西之一是cygwin1.dll这套运行时提供了大量 POSIX 功能让很多原本为 Unix 编写的软件可以在 Windows 上重新编译后运行。Cygwin 官方至今仍把自己描述为“一大批 GNU/开源工具 提供大量 POSIX API 的 DLL”它并不是直接运行 Linux 二进制程序程序通常仍然需要针对 Cygwin 重新构建。于是Unix 程序觉得自己看到的是fork() signals pipes /dev /usr /homeCygwin 在下面努力把这些东西翻译成 Windows 能理解的世界。可以非常粗略地理解成Unix / POSIX 程序 ↓ Cygwin API ↓ cygwin1.dll ↓ Windows当然。真实实现远比这复杂。但从使用者角度Windows 里突然出现了bash ls cp mv grep sed awk ssh gcc make一个 Windows 用户打开 Cygwin。甚至会产生一种错觉我是不是进了一台 Unix 机器Cygwin 官方甚至直接用了一个很形象的宣传语Get that Linux feeling - on Windows不过严格来说。它并不是 Linux。甚至不能简单说它“模拟了一台 Linux”。更准确一点Cygwin 是在 Windows 上构造了一套很像 Unix/POSIX 的运行环境。Cygwin 项目的历史说明也很有意思当初与其逐个重写 GNU 工具来适配 Win32他们选择实现一个共享库补上fork、signals、select等 Unix 程序依赖的能力。这个选择非常重要。因为它解决的是怎么让 Unix 软件比较容易地来到 Windows。但新的问题也出现了。第三章Cygwin 很像 Unix可它终究生活在 Windows 上假设你在 Cygwin 里编译一个程序。它可能依赖cygwin1.dll也就是说这个程序并不是一个完全脱离 Cygwin 环境的普通 Windows 程序。与此同时。还有一些非常麻烦的问题。例如路径。Unix 喜欢/home/farseer/projectWindows 喜欢C:\Users\farseer\project于是 Cygwin 还要在两种路径世界之间做映射。例如 Windows 的C:\在 Cygwin 世界里可以表现成类似/cygdrive/c/Cygwin 官方文档也专门维护了一套 POSIX 视角的 Windows 文件系统映射因为大量 Unix 软件天然假定整个文件系统从/开始而不是从C:、D:开始。再比如fork()Unix 世界觉得这不是理所当然的吗Windows什么Windows 最接近的原生机制是CreateProcess()。但两个东西并不是一回事。所以 Cygwin 必须想办法在一个本来不是 Unix 的操作系统上尽量还原 Unix 程序期待的行为。这是一件很厉害的事情。但也注定意味着兼容层越强背后的翻译工作就越复杂。于是另一群程序员开始想等等。我们的目标真的一定是让 Windows 假装自己是 Unix有没有另一种办法比如我只是想在 Windows 上用 GCC。编译出来的东西。最好还是一个正宗的hello.exe双击就跑。不需要整个 Cygwin 世界。于是MinGW 登场了。第四章MinGW——别把 Windows 变成 Unix我只想把 GNU 工具带过来MinGW 的名字非常直白Minimalist GNU for Windows。它和 Cygwin 的思路看起来很像。都有GCC。GNU 工具。都让 Unix/Linux 程序员觉得熟悉。但两者的目标并不一样。Cygwin 更像在 Windows 上提供一个 POSIX/Unix-like 环境。MinGW 则更像让 GCC 能编译真正的 Windows 程序。也就是说源代码 ↓ GCC / MinGW ↓ Windows API ↓ hello.exe编译出来以后。这个hello.exe本质上仍然是Windows 程序。它不是“跑在一个 Unix 模拟环境里的 Linux 程序。”这点非常关键。后来出现的MinGW-w64进一步扩展了原来的 MinGW增加了 64 位支持以及更多 Windows API。MinGW-w64 官方现在对自己的定义就是一组 Windows 头文件、导入库、运行库和工具与 GCC 或 LLVM 组合后可以构成完整的原生 Windows 应用开发环境该项目在 2007 年从原 MinGW 路线分出以支持 64 位和更新 API。所以如果硬要用一句非常不严谨、但容易理解的话概括Cygwin 是把 Unix 环境搬到 Windows。MinGW 是把 GNU 编译器搬到 Windows。看起来只差一点点。实际上目标完全不同。第五章可是只有 GCC 还不够问题很快又来了。程序员用 GCC 编译大型开源项目。通常不仅仅需要gcc还需要bash make sed awk grep autoconf automake甚至各种./configure make make install可是这些东西本来就是 Unix 世界长出来的。于是 MinGW 旁边逐渐又需要一套Unix 风格的构建环境。这就是MSYS。可以粗略理解为MSYS 负责提供 Bash / Unix 构建工具 MinGW 负责生成原生 Windows 程序这套组合思路非常聪明。因为程序员可以用熟悉的 Unix 工具干活。但最后生产出来的仍然是 Windows 软件。后来MSYS 又进一步发展出今天更加常见的MSYS2。第六章MSYS2——终于有点像现代 Linux 开发环境了如果你今天安装 MSYS2。Linux 用户很容易产生一种亲切感。打开 Shell。然后pacman -Syu等等。pacmanArch Linux 用户可能突然精神起来了。没错。MSYS2 使用的包管理器就是Pacman。你可以安装gcc gdb make cmake git python bash vim以及大量开发库。整个体验越来越像一套真正可维护的软件发行环境。MSYS2 官方把自己定义为 Windows 上的软件发行和构建平台它基于现代 Cygwin 的 POSIX 兼容技术又结合 MinGW-w64主要目标不是制造一个完整 Unix而是方便构建和运行原生 Windows 软件。所以这里出现了一个非常漂亮的组合MSYS2 │ Unix 风格工具 │ Bash / Make / Pacman │ ├───────────┐ │ │ MSYS 环境 MinGW-w64 │ │ POSIX 兼容工具 原生 Windows 程序如果你曾经在 Windows 上使用Git Bash其实你已经和这条技术路线打过交道了。今天的 Git for Windows 本身就建立在 MSYS2 基础之上Git for Windows 官方甚至把自己概括成本质上是 MSYS2 的一个子集。为什么装一个 Git。结果里面有bash ssh grep less vim现在就容易理解了。因为 Git 本身就是从 Unix 世界长出来的软件。要让它在 Windows 上舒服地生活。背后其实塞进去了一小块Unix 风格的环境。第七章微软自己其实也早就尝试过 Unix故事讲到这里。很容易产生一个误会好像一直都是开源社区努力把 Unix 搬到 Windows。微软完全不管。其实并不是。Windows NT 从很早的时候。就考虑过POSIX 兼容。后来微软甚至拥有一套非常有意思的技术Interix。它最初来自 Softway Systems。1999 年。微软收购了这家公司相关资产希望加强 Windows NT 与 Unix 环境之间的互操作。后来 Interix 被整合进Windows Services for UNIX。简称SFU。它的目标之一。也是让原来的 Unix 应用和脚本比较容易地迁移到 Windows。再后来又出现Subsystem for UNIX-based Applications。简称SUA。你看这个名字是不是已经有那么一点Windows Subsystem for Linux的味道了微软在 2000 年发布 Interix 2.2 时就已经强调它可以让 Unix 应用和脚本在 Windows NT/2000 上运行而不必彻底重写。所以微软想让 Windows 和 Unix 共存并不是 WSL 才突然冒出来的想法。这件事折腾了很多年。不过 SUA 最终没有成为普通开发者每天使用的主流工具。到了 Windows Server 2012。微软已经宣布SUA 被弃用。当时微软官方给出的替代建议里。居然直接出现Cygwin。MinGW。MinGW-w64。这幅画面其实挺有意思。微软自己造过 Unix 子系统。最后告诉用户要不你试试 Cygwin但故事还没有结束。因为接下来整个计算机世界发生了一次巨大变化。第八章真正改变局面的不是桌面而是服务器和云如果只看个人电脑。Windows 的地位一直非常强。大量办公软件跑 Windows。大量游戏跑 Windows。各种商业软件跑 Windows。所以微软完全可以觉得我为什么非得把 Linux 当回事可问题是计算机世界后来越来越不只是桌面。互联网起来了。Web 服务器起来了。数据中心起来了。云计算起来了。然后Docker。Kubernetes。DevOps。微服务。云原生。一个接一个来了。而这些技术背后。大量基础设施都围绕Linux。程序员开始遇到一个越来越现实的问题。我的办公电脑Windows我的 IDEWindows公司的 OfficeWindows可是最终代码要跑的地方却是Linux Server开发机Windows。生产环境Linux。于是中间经常夹着一大堆“在我电脑上明明是好的。”Shell 不一样。路径不一样。权限不一样。换行符不一样。脚本不一样。依赖不一样。运行时行为也可能不一样。以前解决办法是什么装虚拟机。比如Windows ↓ VMware / VirtualBox ↓ Ubuntu或者双系统。Windows 一套。Linux 一套。想开发 Linux 软件重启电脑。久而久之。一个问题摆在微软面前如果越来越多开发者必须使用 Linux那么 Windows 还怎么继续成为他们最喜欢的开发桌面这一次。问题的性质已经变了。以前微软想的是怎样把 Unix 软件迁到 Windows。现在则变成怎样让 Windows 用户直接拥有 Linux 开发环境。这两个问题看起来很像。实际上完全不同。第九章2016——微软突然说Windows 可以跑 Bash2016 年。微软 Build 大会。一个消息出来。很多程序员第一反应可能都是什么微软宣布Bash on Ubuntu on Windows。也就是后来大家熟悉的WSL。Windows Subsystem for Linux。微软当时宣布Windows 10 将可以直接运行 Bash 和 GNU/Linux 命令行工具第一批公开预览随后进入 Windows 10 Insider Build。这个变化到底有多大以前 Cygwin 的思路是Unix 程序 ↓ 重新编译 ↓ Cygwin POSIX Layer ↓ Windows而 WSL 1 做了一件更激进的事情运行未经修改的 Linux ELF 二进制程序。比如/bin/bash /bin/ls /usr/bin/grep这些不再是“给 Windows 重新编译出来的类似版本。”而是真正面向 Linux 的二进制程序。这一步非常关键。第十章WSL 1——Windows 开始“听懂”Linux 系统调用但注意。最早的 WSL没有 Linux Kernel。这点非常容易搞混。WSL 1 的思路。某种程度上反而很像一位更加深入操作系统内部的“翻译官”。Linux 程序说我要创建进程。Linux 程序说我要打开文件。Linux 程序说我要申请内存。Linux 程序不断发出Linux system call。WSL 1 则尝试把这些请求转换成 Windows 能完成的操作。可以非常粗略地画成Linux ELF 程序 ↓ Linux System Call ↓ WSL 1 ↓ Windows NT Kernel所以WSL 1 能运行真正的 Linux 用户态程序。但下面依然没有真正的 Linux Kernel。微软自己的 WSL 文档今天也仍然明确说明WSL 1 使用的是由 WSL 团队实现的转换层而不是完整 Linux 内核。这个方案非常漂亮。因为没有传统虚拟机。启动快。Windows 和 Linux 文件互访也非常直接。但它有一个天然问题Linux System Call太多了。Linux Kernel还在继续发展。各种程序越来越复杂。Docker 之类的软件又高度依赖 Linux 内核行为。结果微软逐渐发现想永远追着 Linux Kernel把所有行为一条一条翻译出来实在太累了。怎么办答案非常有程序员风格。既然模拟 Linux Kernel 这么麻烦。那么为什么不干脆真的放一个 Linux Kernel 进去第十一章WSL 2——别翻译了Windows 里面直接跑 Linux Kernel2019 年。微软公布WSL 2。2020 年。WSL 2 随 Windows 10 May 2020 Update 正式进入更广泛用户手中。微软当时明确说明WSL 2 使用由微软构建和提供的真实 Linux Kernel并运行在轻量级虚拟机环境里。于是架构彻底变了。WSL 1 大概是Linux 程序 ↓ Linux System Call ↓ 翻译 ↓ Windows NT KernelWSL 2 则变成Linux 程序 ↓ Linux System Call ↓ Linux Kernel ↓ 轻量虚拟化 ↓ Windows看见区别了吗这一次中间真的有 Linux Kernel。而且这个 Kernel由微软基于上游 Linux Kernel 构建并针对 WSL 优化。官方文档今天也明确说明WSL 2 使用轻量级 Utility VM 运行完整 Linux Kernel因此获得了完整系统调用兼容性。于是很多过去 WSL 1 很难解决的问题突然容易多了。为什么因为碰到 Linux Kernel 行为时。已经不需要微软再问Windows 应该怎样模拟这个东西Linux Kernel 自己回答我来。这可能是整个故事里最有意思的一次转折。早年的思路是让 Unix 软件适应 Windows。后来变成让 Windows 模拟 Linux。最后算了把 Linux 本人请进来。第十二章所以 Cygwin、MinGW、WSL 到底有什么区别讲到这里。这几个经常一起出现的名字。终于可以放到一张图里。Cygwin核心问题怎样在 Windows 上提供 Unix/POSIX 环境大概是Unix 源代码 ↓ 重新编译 ↓ Cygwin ↓ Windows重点兼容 Unix/POSIX。MinGW / MinGW-w64核心问题怎样在 Windows 上使用 GCC 等 GNU 工具编译原生 Windows 程序大概是源代码 ↓ GCC ↓ MinGW-w64 ↓ Windows API ↓ .exe重点生成原生 Windows 软件。MSYS2核心问题怎样给 Windows 原生开发提供一套舒服的 Unix 风格构建环境所以它把Bash。Pacman。Make。Autotools。MinGW-w64。各种开源工具。组织到了一起。重点Unix 风格开发环境 原生 Windows 构建。WSL 1核心问题怎样直接运行 Linux 二进制程序又不用真的跑 Linux Kernel所以翻译 Linux System Call。WSL 2核心问题既然大家真正需要的就是 Linux。那么直接运行 Linux Kernel。微软官方目前也给出了很直接的定位如果只是需要 Linux CLI 工具或者开发的软件最终就是部署到 Linux 服务器上WSL 通常更加合适而 MSYS2 的强项仍然是构建原生 Windows 程序。所以这些工具其实并不是简单的一代淘汰一代。它们解决的是不同的问题。第十三章WSL 出现以后Cygwin 和 MinGW 就没用了吗并没有。这是另一个很容易产生的误解。今天如果你的目标是开发一个最终运行在 Ubuntu Server 上的程序。那么WSL 2 通常非常舒服。你可以直接apt install gcc直接cmake make python node go docker你的环境本身就是 Linux。但如果你的目标是编译真正的 Windows.exe。MinGW-w64 依然非常有价值。MSYS2 也依然非常活跃。如果你有大量老的 Unix/POSIX 软件。需要它们和 Windows 环境深度结合。Cygwin 同样没有消失。今天 Git for Windows。背后仍然能看到MSYS2。Cygwin。MinGW。这些技术留下来的痕迹。Git for Windows 的 Bash 和部分 POSIX 工具依赖 MSYS2 的兼容层而 Git 本身则可以作为 MinGW 原生程序构建。所以WSL 并没有把前面的历史全部推倒。它只是把“我想要一个真正 Linux 环境”这个问题解决得更加彻底了。第十四章微软为什么变了现在终于可以回到文章标题Windows 为什么最终拥抱 Unix 世界很多人喜欢把这个故事理解成早年的微软反对 Linux。后来微软突然“想通了”。其实真实原因可能没那么浪漫。更现实。也更商业。第一开发者变了以前 Windows 软件开发者的目标通常是Windows现在一个 Windows 程序员可能写的是Python。Node.js。Go。Rust。Java。Cloud Native。后端服务。AI 应用。最终运行环境却可能是Linux如果 Windows 不能很好服务这些程序员。他们最简单的选择是什么直接用 Linux 或 macOS。对于微软来说这显然不是一个理想结果。于是 Windows 必须回答怎么让一个以 Linux 为目标平台的程序员仍然愿意使用 Windows 开发WSL就是其中一个答案。第二服务器世界变了Windows 最强大的传统领地之一是 PC。但云计算时代。服务器、容器、云原生基础设施越来越重要。而 Linux 已经成为这个世界里极其重要的平台。Docker。Kubernetes。大量云原生软件。开源数据库。Web 服务。AI 基础设施。大量默认文档第一句都是sudo apt install ...微软当然可以坚持你们全部改成 Windows。问题是用户凭什么听你的更现实的做法是用户喜欢 Linux那 Azure 就跑 Linux。开发者需要 Linux那 Windows 就提供 Linux。这是一种非常典型的平台思维。第三开源已经从“对手”变成基础设施1990 年代。商业软件和自由软件之间的阵营感非常强。但后来Git。Linux。Python。Node.js。Kubernetes。PostgreSQL。OpenSSH。LLVM。各种开源项目。逐渐变成整个软件工业共同使用的基础设施。企业可以不用 Linux Desktop。但它很难做到完全不接触 Linux 和开源生态。微软自己也越来越深地进入开源世界。.NET 跨平台。PowerShell 跨平台。Windows 自带 OpenSSH。VS Code 跨平台。Azure 支持 Linux。WSL 运行 Linux。到了今天。微软自己的 WSL 官方介绍页面甚至直接有一节Microsoft loves Linux。如果把时间拨回几十年。这个画面确实很难想象。第十五章Windows 没有变成 Unix它只是学会了和 Unix 一起生活这里必须再强调一次。WSL 出现以后Windows 仍然不是 Unix。Windows 11 的核心仍然是Windows NT。Windows 程序依然大量运行在Win32体系上。Windows 仍然有注册表。盘符。NTFS。Windows Security Model。Windows Driver Model。Win32 API。它没有因为wsl就突然变成Unix。这点和上一篇讲 Windows 血统时的结论并不矛盾。上一篇最后其实已经留下了这个伏笔Windows 仍然不是 Unix但它开始把 Linux、OpenSSH、跨平台开发工具主动请进自己的生态。真正改变的是另一件事情Windows 不再要求整个世界都必须按照 Windows 的方式工作。早年的目标可能更像Unix 软件 ↓ 移植 ↓ Windows 软件后来则越来越变成Windows 软件 ──────────┐ │ Linux 软件 ────────────┤ │ Cloud / Container ─────┤ ↓ 同一台开发电脑这其实是一种很重要的平台思维变化。以前Windows 想成为目的地。现在Windows 更愿意成为平台。你最后的软件跑在 Windows可以。跑 Linux也可以。跑容器可以。部署 Azure可以。本地一边运行 Visual Studio。另一边ssh gcc docker python也可以。只要你还愿意坐在 Windows 前面开发。第十六章从“模拟 Unix”到“真的运行 Linux”现在回头看这三十年的故事。会发现一条非常清楚的路线。最开始Windows 和 Unix 是两个世界。于是 Cygwin 出现让 Windows 看起来更像 Unix。然后 MinGW 出现让 GNU 工具能够生产 Windows 软件。MSYS / MSYS2 又进一步解决怎样用 Unix 风格的工具舒服地开发 Windows 软件。微软自己也尝试过Interix。Services for UNIX。SUA。后来云计算和 Linux 彻底改变开发环境。于是 WSL 1 来了直接运行 Linux 二进制程序但自己翻译 System Call。翻着翻着。发现 Linux Kernel 越来越复杂。于是到了 WSL 2不翻译了。直接运行 Linux Kernel。整个过程可以极度简化成1990s Windows 与 Unix 是两个世界 ↓ Cygwin 在 Windows 上构造 POSIX 环境 ↓ MinGW 用 GNU 工具构建原生 Windows 软件 ↓ MSYS / MSYS2 Unix 工具链 Windows 原生开发 ↓ Interix / SFU / SUA 微软自己的 Unix 兼容尝试 ↓ 2016 WSL 1 直接运行 Linux ELF System Call 翻译 ↓ 2019 / 2020 WSL 2 真正的 Linux Kernel ↓ 今天 Windows Linux 成为同一套开发工作站如果把这几十年压缩成一句话可能就是最开始人们想办法让 Unix 软件适应 Windows。最后Windows 决定直接给 Unix/Linux 留一个位置。写在最后那个没有 Unix 血统的巨人最终把 Unix 请进了家里上一篇写 Windows 时。我把 Windows 比作Unix 家族大树旁边另一棵独立成长起来的巨树。它没有 Unix 血统。它有自己的Windows NT。Win32。注册表。驱动体系。软件生态。而且这棵树长得非常成功。它几乎统治了 PC 世界几十年。但计算机世界并没有因此停止变化。互联网来了。Linux Server 来了。开源来了。云计算来了。Docker 来了。Kubernetes 来了。DevOps 来了。AI 基础设施来了。越来越多软件最终运行的土地已经不一定是 Windows。于是微软慢慢发现真正重要的问题已经不是Windows 能不能消灭 Unix而是Unix/Linux 世界如此庞大以后Windows 怎样继续成为程序员愿意使用的平台于是Cygwin 尝试搭了一座桥。MinGW 又搭了一座。MSYS2 把桥修得更舒服。微软自己也折腾过 Interix 和 SUA。最后WSL 出现。到了 WSL 2微软甚至干脆在 Windows 里面真的运行了一个 Linux Kernel。这可能是整个故事最有戏剧性的地方。Windows 并没有输掉自己的血统。它还是 Windows NT。Linux 也没有变成 Windows。它还是 Linux。两个曾经隔得很远的世界。最终没有谁吞掉谁。而是决定住在了一台电脑里。今天一个开发者完全可以左边打开Visual Studio右边打开Ubuntu上面跑Windows 11下面藏着Linux Kernel然后git clone cmake make docker kubectl ssh再把程序部署到远处的一台 Linux Server。此时Windows 是 Windows。Linux 是 Linux。但程序员已经不太在乎这条边界了。所以如果上一篇 Windows 的故事告诉我们Windows 没有 Unix 血统也可以成长为一个庞大的操作系统帝国。那么这一篇留下的故事可能是真正成熟的平台不一定要把所有人变成自己。有时候。更强大的选择反而是让不同的世界都能在自己这里生存。从 Cygwin。到 MinGW。从 MSYS2。到 WSL。Windows 花了几十年。终于从“怎样让 Unix 软件变成 Windows 软件”走到了“既然你需要 Linux那 Linux 就住进来吧。”而这大概也是 Windows 历史上最有意思的一次转身那个没有 Unix 血统的巨人最终没有变成 Unix。它只是张开门把 Unix 世界请进了自己的家里。