可在Windows下运行的Linux环境
2023-08-29 10:43:18 
阿炯
1、CygwinCygwin/gcc和下文的MinGW都是gcc在windows下的编译环境，在实际工作中如何选择这两种编译器。
Cygwin/gcc完全可以和在linux下的gcc化做等号，这个可以从boost库的划分中可以看出来端倪，cygwin下的gcc和linux下的gcc完全使用的是相同的Toolsets。所以完全可以和linux一起同步更新gcc版本，而不用担心问题，并且在cygwin/gcc做的东西（不用win32的）可以无缝的用在linux下，没有任何问题。是在windows下开发linux程序的一个很好的选择。
但是在cygwin/gcc下编译出来的程序，在windows执行必须依赖cygwin1.dll，并且速度有些慢，如果不想依赖这个东西的化，必须在gcc的编译选项中加入-mno-cygwin。加入这个选项其实gcc编译器就会自动的选择在安装cygwin/gcc时安上的mingw,这个mingw就是gcc的一个交叉编译。
对于mingw作为gcc在windows上的一个实现，由于不像cygwin的gcc在一个模拟linux上运行，同时相当一部分linux的工具不能够使用，不过现在已经有Msys这个模拟unix的shell，可以解决很多的问题。当然其还有一个轻量级的替代软件Gow。
2、MSYS
MSYS：Unix-like command line utilities，包括基本的bash, make, gawk and grep等。通常也可以认为是小型的UNIX on Windows，提供在windows上模拟Unix环境来使用MinGW。
MSYS在windows下模拟了一个类unix的终端，它只提供了MinGW的用户载入环境，在MSYS模拟的unix环境下使用MinGW，就像在Unix使用gcc一样。
3、MinGW
MinGW 即 Minimalist GNU For Windows（GCC compiler suite）。它是一些头文件和端口库的集合，该集合允许人们在没有第三方动态链接库的情况下使用 GCC（GNU Compiler C）产生 Windows32 程序，原来的项目似乎已经停止更新了。不过新的项目名称为Mingw-w64，很明显支持了64位环境。
MinGW是一个可自由使用和自由发布的Windows特定头文件和使用GNU工具集导入库的集合，在基本层，MinGW 是一组包含文件和端口库，其功能是允许控制台模式的程序使用微软的标准C运行时间库（MSVCRT.DLL），该库在所有的 NT OS 上有效，在所有的 Windows 95 发行版以上的 Windows OS 有效，使用基本运行时，可以使用 GCC 写控制台模式的符合美国标准化组织（ANSI）程序，可以使用微软提供的 C 运行时扩展。该功能是 Windows32 API 不具备的。下一个组成部分是 w32api 包，它是一组可以使用 Windows32 API 的包含文件和端口库。与基本运行时相结合，就可以有充分的权利既使用 CRT（C RunTime）又使用 Windows32 API 功能。
实际上 MinGW 并不仅是一个 C/C++ 编译器，而是一套 GNU 工具集合。除开 GCC (GNU 编译器集合) 以外，MinGW 还包含有一些其他的 GNU 程序开发工具 (比如 gawk bison 等等)。开发 MinGW 是为了那些不喜欢工作在 Linux(FreeBSD) 操作系统而留在 Windows 的人提供一套符合 GNU 的 GNU 工作环境。所以使用 MinGW 就可以像在 Linux 下一样使用 GNU 程序开发工具。
GCC 就是 MinGW 的核心所在，它是一套支持众多计算机程序语言的编译系统，而且在语言标准的实现上是最接近于标准的。并且其几乎可以移植到目前所有可用的计算机平台。
GCC 本身不像VC那样拥有IDE界面（但是有很多的开源的IDE支持使用MinGW，例如codeblocks，eclipse等）。源代码编辑你可以选用任何你喜欢的文本编辑器（据说微软的开发人员包括 VC 的开发都不用 VC 所带的 IDE 编辑器，而是选用 GNU 的 VIM 编辑器）。然后使用 make 等工具来进行软件项目的编译、链接、打包乃至发布。而像 cvs(svn) 源代码版本控制工具可以让世界上任何一个角落的人都可以参与到软件项目中来。
关于 MFC，微软基础库类，这个随 VC++ 携带的一个源代码公开的开发包，和其他 Windows 程序开发包是一样的。如果有 VC++ 的授权，完全可以使用 MFC 的源代码，也就是使用 GCC 来编译 MFC 程序是完全可以的。当然 GNU 下也有很多 Windows 程序开发包，甚至有一些是支持跨平台使用的。不仅仅可以直接把源代码编译为 Windows 程序，也可以不经修改编译为其他操作系统的图形程序。
它们之间的区间可做如下简述：
MinGW 只包括gcc和g++，不支持离线安装。
MinGW Distro是打包好的MinGW，可离线安装。
Cygwin 不仅提供了gcc和g++，而且实现了大量的POSIX API，不支持离线安装。
Babun是基于Cygwin的，预置git和oh-my-zsh，支持离线安装。
MSYS2是对Windows的软件发行版和构建平台，可离线安装。
VS-MSVC则是微软官方提供的nmake等工具。ReactOS 与 Wine 也是可以选择的。
4、Windows Subsystem for Linux(WSL)
适用于Linux的Windows子系统（英语：Windows Subsystem for Linux，简称WSL）是一个为在Windows 10和Windows Server 2019以上能够原生运行Linux二进制可执行文件（ELF格式）的兼容层。它提供了一个由微软开发的Linux兼容的内核接口（不包含Linux内核代码），然后可以在其上运行GNU用户空间，例如Ubuntu，openSUSE，SUSE Linux Enterprise Server，Debian 和Kali Linux。这样的用户空间可能包含Bash Shell和命令语言，使用本机GNU/Linux命令行工具（sed，awk等），编程语言解释器（Perl，Ruby，Python等），甚至是图形应用程序（使用主机端的X窗口系统）。WSL 是 Windows 的一个系统组件，能在 Windows 系统中直接运行 Linux，不需要安装虚拟机，也不用配置双系统。简单、方便，对开发者尤其友好。可以用它运行像 bash、gcc、apt、vim 这样的 Linux 命令和工具，还能直接访问 Linux 子系统的文件系统，非常适合写代码、搭环境、跑脚本，甚至运行 GUI 应用程序。WSL在版本1607之后的64位版本的Windows 10、11中可用，它也可在Windows Server 2019中使用。
虽然微软以前的项目和第三方Cygwin专注于基于POSIX标准创建自己独特的类Unix环境，但WSL的目标是原生Linux兼容性。WSL不是将非原生功能包装到Win32系统调用中，而是利用NT内核执行程序将Linux程序作为特殊的、隔离的最小进程（称为“pico-processes”）作为专用系统连接到内核模式“pico-providers”。调用和异常处理程序不同于vanilla NT进程。微软将WSL视为“主要面向开发人员的工具 — 尤其是Web开发人员以及在开源项目上工作或使用开源项目的人员”。WSL使用的资源少于完全虚拟化的机器，这是在Windows环境中运行Linux软件的最直接方式，同时还允许用户在同一组文件上使用Windows应用程序和Linux工具。
2020年9月，WSL 2开始向Windows 10 Version 1903/1909和Windows 10 May 2020（20H1/Version 2004）的用户推送。WSL 2支持GUI应用。
WSL 1
LXSS Manager Service是负责与子系统交互的服务（通过驱动程序lxss.sys和lxcore.sys），以及Bash.exe（不要与Linux发行版提供的Shell混淆）的方式启动Linux进程，以及在执行期间处理Linux系统调用和二进制锁。特定用户调用的所有Linux进程都进入“Linux实例”（通常第一个调用的进程是init）。关闭所有应用程序后，将关闭实例。
WSL 1的设计没有硬件模拟/虚拟化（与coLinux等其他项目不同），WSL直接使用主机文件系统（通过VolFS和DrvFS）和硬件的某些部分，例如网络（Web服务器，用于例如，可以通过主机上配置的相同接口和IP地址进行访问，并且对使用需要管理权限的端口或已经被其他应用程序占用的端口共享相同的限制），这保证了互操作性。即使从shell运行sudo，某些位置（例如系统文件夹）和配置的访问/修改也受到限制。必须启动具有提升权限的实例才能获得“真正的sudo”并允许此类访问。
WSL 1 无法运行所有 Linux 软件（如32位二进制文件）或需要在WSL中未实现的特定Linux内核服务的软件。由于WSL中没有“真正的”Linux内核，因此无法运行内核模块（如设备驱动程序），但是WSL 2 使用即时虚拟化的Linux内核实例。可以通过在Windows（主机）环境（例如VcXsrv或Xming）中安装X窗口系统来运行一些图形（GUI）应用程序（例如Mozilla Firefox），但是这种模式还存在一定的问题，例如缺乏音频支持或硬件加速（导致图形性能不佳）。尽管已经在计划中，但是目前还没有实现对OpenCL和CUDA的支持。
也就是说，微软明确指出WSL面向应用程序的开发者，而不是面向桌面环境或生产服务器。微软建议使用虚拟机（Hyper-V或Kubernetes）和Azure来实现这些目的。在性能测试中，WSL 1通常接近原生Linux（如Ubuntu、Debian、Intel Clear Linux或其他Linux发行版）。在某些测试中I/O是WSL的瓶颈。
WSL 2
WSL 2 引入了体系结构中的更改。微软选择了通过高度优化的Hyper-V功能子集进行虚拟化，以便运内联核和发行版（基于内核），承诺性能相当于WSL 1，为了 向下兼容，开发人员不需要更改其已发布发行版中的任何内容。 WSL 2 设置可以通过 WSL 全局设置配置进行调整，该配置位在用户配置文件文件夹中名为.wslconfig的INI文件。
发行版本安装在ext4格式的虚拟磁盘中，主机文件系统可以通过9P协议透明地访问，类似于QEMU等其他虚拟机技术。对于用户，微软承诺读写性能是WSL 1的20倍。Windows提供一个IFS网络重定向程序，使用UNC路径首码\\wsl$来访问Linux客户档。WSL 2 需要Windows 11或Windows 10版本 2004 和更新版本(组建 19041 和更新版本)。
微软声称重新设计的WSL 2后端在某些操作上的速度比WSL 1提高了20倍，2020 年 6 月，使用 AMD Threadripper 3970x 进行了 173 次测试的基准测试显示，WSL 2（20H2） 性能良好，性能仅为本机 Ubuntu 20.04.0 LTS 的 87%。这是对WSL 1的改进，在此比较中，WSL 1的性能仅为本机Ubuntu的70%。WSL 2改善了I/O性能，提供了接近本地的水准。在2020年5月，用Intel i9 10900K进行的69项测试比较显示了几乎相同的相对性能。在2020年12月，用AMD Ryzen 5900X进行的43项测试的基准显示了WSL 2（20H2）的良好性能，其性能为原生20.04.1 LTS的93%。这比WSL 1有进步，后者在这种比较中只有73%。
微软宣布 WSL 正式开源
微软于2025年5月中旬宣布正式开源 Windows Subsystem for Linux（WSL），包括其命令行工具（wsl.exe 和 wslg.exe）、后台服务（wslservice.exe）以及用于启动联网、启动其他守护进程和设置端口转发的 Linux 端守护进程。作为 Windows 的一部分，Lxcore.sys（WSL 1 的内核驱动程序）以及用于 “\\wsl.localhost” 文件系统重定向的 P9rdr.sys 和 p9np.dll 组件没有进行开源。
从第一天起就拥有一个强大的社区支持 WSL。我们很幸运，人们分享他们的知识，并花费无数的时间来帮助追踪错误，找到实现新功能和改进 WSL 的最佳方法。如果没有社区的支持，WSL 就不可能有今天的成就。即使无法访问 WSL 的源代码，人们也能够做出重大贡献，最终成就 WSL 的今天。这就是为什么我们今天对 WSL 开源感到无比兴奋。我们已经看到社区在没有源代码的情况下为 WSL 做出了巨大的贡献，我们迫不及待地想看到，在社区能够直接为项目贡献代码之后，WSL 将如何发展。
WSL 的架构概述：
WSL 是 Windows 的 Linux 子系统，首次是在 Microsoft BUILD 2016 上推出，并随 Windows 10 周年更新一起发布。
起初 WSL 基于一个微进程提供程序 lxcore.sys，使得 Windows 能够原生运行 ELF 可执行文件，并在 Windows 内核中实现 Linux 系统调用，被称为 “WSL 1”，且至今仍受支持。随着时间的推移，WSL 2 于 2019 年首次发布，引入了完整的 Linux 内核。之后，WSL 逐渐获得了更多功能，例如 GPU 支持、图形界面支持（通过 wslg）和对 systemd 的支持。
为了跟上日益壮大的社区和功能需求，加快 WSL 开发节奏。微软在 2021 年将 WSL 从 Windows 代码库中剥离，并将其迁移到独立的代码库中。新的 WSL 于 2021 年 7 月首次以 0.47.1 版本在 Microsoft Store 上线。当时，该软件包仅支持 Windows 11，并标记为预览版，仅推荐给想要体验 WSL 最新、最强大功能的用户。
2022 年 11 月 WSL 1.0.0 发布，增加了对 Windows 10 的支持，也是这个新 WSL 的第一个 “稳定” 版本。此后，另一个里程碑版本 WSL 2.0.0 发布，引入了包括镜像网络、DNS 隧道、代理支持和防火墙兼容等改进。目前最新可用版本为 v2.5.7。
发展过程：从兼容层到原生内核的蜕变
微软对 Linux 的态度曾一度备受争议，但从 2016 年推出 WSL 以来，它一步步改变了人们的看法。下面简单回顾一下它的发展历程：
2016 年：WSL 1 问世
与 Windows 10 周年更新一同推出。它通过名为 lxcore.sys 的兼容层把 Linux 系统调用转化为 Windows 可识别的指令，是微软对“在 Windows 上跑 Linux”的首次尝试。
2019 年：WSL 2 上线，换上真正的 Linux 内核
WSL 2 使用轻量级虚拟机（基于 Hyper-V 技术），并搭配微软维护的 Linux 内核，大幅提升了兼容性和性能。GPU 加速、图形界面（WSLg）、systemd 支持等特性也陆续加入。
2021 年：WSL 独立于系统，在 Microsoft Store 上发布
这让更新更加灵活、迅速。用户可以像更新普通应用一样获取新版 WSL，而不必等待 Windows 系统大版本升级。
开源了哪些内容，哪些还没开源？
微软此次开源的是 WSL 的“用户态”组件，代码已托管在 GitHub 上。主要包括：
已开源的部分：
1.命令行工具：如 wsl.exe、wslconfig.exe、wslg.exe。
2.WSL 服务进程（wslservice.exe）：用于启动虚拟机、管理 Linux 发行版、挂载文件系统等。
3.Linux 子系统守护进程：启动器（init）、网络服务（gns）、本地端口转发器（localhost 转发）。
Plan 9 协议的文件共享服务：用于实现 Windows 与 Linux 之间的文件共享。
尚未开源的部分：
1.lxcore.sys：WSL 1 所依赖的驱动。
2.p9rdr.sys：Plan 9 文件共享协议在 Windows 的实现，用于支持 \\wsl.localhost 路径访问。
微软表示尚未开源的部分可能在未来某个时间点继续推进。
开源 WSL 意味着什么
本着“打不过就加入”的法则，对于普通用户和开发者来说，这并不仅仅是“能看代码”那么简单，它带来的实际好处非常多：
1.更高质量的产品
过去社区发现问题后，只能通过 issue 反馈，微软来处理；现在可以自己查代码、提交修复，响应效率更高，质量也更容易保证。
2.更强的安全性和透明性
开源让企业和开发者能审查代码安全性，避免黑盒行为，便于合规性审核。
3.更多创新可能
开发者可基于 WSL 做定制、优化甚至二次开发。比如可以打造一个为教育场景优化的 WSL 分支，或者做更轻量的容器集成。
开发者如何参与？
微软为 WSL 项目准备了清晰的贡献指南和开发流程，现在可以：
1.在 GitHub 上 克隆源码；
2.本地构建和测试 WSL 用户态组件；
3.提交改进建议或 bug 修复的 pull request；
4.参与 issue 讨论，为 WSL 的未来方向出谋划策。
微软也表示会认真对待社区的贡献，并持续保持项目活跃度。
这是一次开放姿态的重大转变，WSL 开源不仅是微软拥抱开源的又一次实质性进展，也意味着 Windows 与 Linux 的边界更加模糊、协作更加紧密。这让开发者能真正选择最适合自己的工具与环境，而不被平台限制。未来可能会看到：
1.更多企业和社区加入 WSL 生态；
2.更多基于 WSL 的工具、扩展、优化版诞生；
3.Windows 作为开发平台的竞争力进一步提升。
WSL 2 优化 Windows 文件系统访问速度
WSL 2 的文件访问性能优化经历了一个漫长的技术迭代过程。最初的 WSL 1（2016）使用 DrvFs，这是一种直接运行在 Windows NT 内核上的自定义文件系统驱动，使 /mnt/c 下的文件操作几乎直接到达 NTFS，延迟极低。WSL 2（2019）切换到完整 Linux 内核运行在轻量级 Hyper-V VM 中后，跨系统文件访问面临新的技术挑战 —— 微软在 Windows 端 WSL 服务中构建了一个 Plan 9 文件服务器，Linux 会话在启动时通过 Hyper-V socket 连接，9P 协议成为了两者之间的桥梁。问题在于 9P 协议有固有缺陷：每次操作的消息大小被限制在 64 KB 参数以内，对于文件 heavy 的工作负载 —— 比如涉及大量小文件的操作 —— 会产生显著的开销。2021 年左右，virtiofs 作为实验性功能登场，用户可以通过在 .wslconfig 文件的 [wsl2] 部分设置 virtiofs=true 来启用。virtiofs 使用 VirtIO 传输进行共享内存文件访问，相比 9P 减少了序列化开销。但它一直是 opt-in 的可选功能 —— 默认传输仍然是 Plan 9 over Hyper-V socket。
2026 年 5 月，一个重要的变化通过 PR#40654 合并到 WSL 2 主线。这个由 Ben Hillis 编写的变更，为每个 virtio 设备提供了独立的 DMA 池，而不是共享一个全局 SWIOTLB 池。在此之前，WSL 2 会话中的所有 virtio 设备 —— 包括不同驱动器的 virtiofs 挂载点和 virtio 网络适配器 —— 都在同一个 bounce buffer 区域（下限 4GB DMA 边界）排队，在重 I/O 操作期间造成争用。对于同时使用多个驱动器挂载点的用户，这个争用尤为明显。
该优化需要 Microsoft.WSL.Kernel 6.18.26.3-1 或更高版本，结合 WSL 2 DeviceHost 1.2.29-0 使用。运行旧内核的用户会看到一条消息："The running kernel is missing a patch that significantly improves virtio device performance. Update to a more recent WSL kernel to enable this optimization." 这是一个非破坏性的变更 —— 没有独立 DMA 池功能的系统仍然可以正常运行 virtiofs，只是无法享受性能优化。
受益最大的场景是跨系统文件 heavy 的工作流：项目存储在 Windows 驱动器上，但构建在 Linux 中运行。从 /mnt/c 执行 cargo build、npm install 或 mvn package 等命令，都会因这个优化而改善性能。VirtioProxy 网络也受益，因为它共享同一个 DMA 基础设施。用户应当确保 WSL 2 会话的 RAM 保持在 1GB 以上，以提供至少 64MB 的 SWIOTLB 池空间余量 —— 这是让优化生效的前提条件。virtiofs 仍然是 opt-in 的默认选项。对于大多数用户，这意味着如果当前 virtiofs 没有打开，这个优化暂时还与你无关。但它代表了 WSL 2 在文件访问性能这个议题上持续改进的路径 —— 微软正在逐步解决过去几年社区反馈最多的痛点之一。
WSL9x工具包开源发布：支持Win95/98运行Linux 6.19内核
引用科技媒体 WinAero 2026年4月下旬消息称独立开发者 Hailey Somerville 上线推出 WSL9x 工具包，可以在 Windows 95、98 以及 Windows ME 系统上，运行现代 Linux 内核。该开源项目名为 Windows 9x Subsystem for Linux，使用 C 语言和汇编语言编写，源代码已按 GPLv3 协议开源。不同于 Windows 10、11 系统中的 WSL2 架构，WSL9x 不依赖虚拟化技术，而是让 Linux 内核在 ring 0 保护层级与 Windows 内核直接并行运行。通过这项架构设计，用户可以在搭载 Intel i486 处理器的老旧系统上，不依赖虚拟化支持运行软件。
项目使用修改版的 Linux 6.19 内核（专为 User-mode Linux 构建），为简化两个操作系统间的通信，开发者将翻译层的 POSIX（可移植操作系统接口）API 调用替换为 Windows 9x 内核 API 调用。此外该工具核心操作由专用 VxD（虚拟设备驱动程序）驱动管理，负责初始化环境、将 Linux 内核加载至系统内存、调度中断及切换控制权。
驱动采用协作式多任务模式维持环境间稳定性，并处理用户空间事件，如系统调用执行和页面错误管理。由于 Windows 9x 内核缺乏中断向量表，开发者利用通用保护故障处理器拦截 SYSCALL 指令执行时的异常。
可在 Linux 上运行 Windows 应用-WinBoat
WinBoat 是一款 Electron 应用，由TypeScript编写开发并在MIT协议下授权使用。它允许使用容器化方法在 Linux 上运行 Windows 应用。Windows 以虚拟机的形式在 Docker 容器内运行，使用 WinBoat Guest Server 与其通信，从 Windows 中检索所需的数据。为了将应用程序合成为原生操作系统级窗口，将 FreeRDP 与 Windows 的 RemoteApp 协议结合使用。其在2025年10月处于测试阶段。
特性：
优雅的界面：时尚直观的界面，将 Windows 无缝集成到你的 Linux 桌面环境中，让你感觉像原生体验。
自动安装：通过界面进行简单的安装过程 - 选择偏好和规格，然后自动处理其余部分。
运行任何应用程序：只要能在 Windows 上运行，就能在 WinBoat 上运行；在 Linux 环境中，像原生操作系统级窗口一样畅享各种 Windows 应用程序。
完整的 Windows 桌面：在需要时访问完整的 Windows 桌面体验，或运行无缝集成到 Linux 工作流程中的单个应用程序。
文件系统集成：主目录安装在 Windows 中，允许在两个系统之间轻松共享文件，没有任何麻烦。
还有更多：智能卡直通、资源监控以及定期添加的更多功能。
小结
MinGW是windows版本的gcc集合，不需要依赖中间层。
MSYS是小型的linux的环境的模拟，可以与MinGW结合来模拟linux环境下使用MinGW的gcc。
Cygwin是功能强大的linux环境，由于有cygwin1.dll实现了底层的windows api到linux api的转化。所以在Cygwin里开发就相当于在linux上开发，对于开发人员来说就相当于调用linux类型的api，所以这样开发的程序也可以直接移植到linux上。但是如果这样的程序要在windows上执行的话，运行时必须要cygwin1.dll支持。
根据以上的分析，如果在windows开发linux跨平台的程序，linux模拟器Cygwin以及所包含的gcc是很好的选择，但是开发的程序必须依赖一个cygwin1.dll。如果你只是想在windows下使用gcc编译器也不想依赖其他的dll，mingw是很好的一个选择。在无法完全转换到Linux系统的前提下，可一直在 Cygwin 下工作，使用全套的Linux移植工具，学习Bash编程；Cygwin由于工作在模拟模式下，速度较慢，相比而言，MinGW 就要快不少。
| 特点 | Cygwin | MinGW/MSYS | MSYS2 |
|---|---|---|---|
| 是否GNU | 否 | 是 | 是 |
| 更多软件支持？ | 支持绝大多数的 GNU 软件 | 支持常用软件，git、Vim等软件需要独立支持 | 支持大多数 GNU 软件 |
| 更类Linux？ | Cygwin在Windows中就好像Wine在Linux中 | 实现了Bash等主要的Linux程序 | 原生64/32bit支持 |
| GCC编译 | 内含MingGW32交叉编译功能，既支持依赖cygwin1.dll的程序编译，也支持独立的Windows程序编译；可以直接编译Linux下的应用程序 | 支持独立的Windows程序编译 | 支持独立的Windows程序编译 |
| 中文支持 | 直接支持中文显示和输入法 | 需要配置才能支持中文显示和输入，删除一个中文字符需要删除2次 | 支持中文显示和输入法，中文帮助系统和中文提示（部分软件） |
| 运行速度 | 慢 | 快 | 快 |
再来较为详细的小结
1).Cygwin和MSYS2——作为项目有着显著不同的目标。
Cygwin试图将POSIX兼容的环境引入Windows，以便在unix上运行的大多数软件都可以在Cygwin上构建和运行，而无需进行任何重大修改。Cygwin提供了大量包含此类软件的软件包，以及用于其开发的库。MSYS2试图为构建本机Windows软件提供一个环境。
MSYS2提供了大量包含此类软件的软件包，以及用于其开发的库。由于大部分软件使用与unix世界紧密耦合的GNU构建工具，因此该环境也与POSIX兼容，并且实际上基于Cygwin。MSYS2提供了运行autotools和其他构建系统所需的最小要求，这些系统从不同的存储库从Internet获取软件源，配置并构建它们。shell和core工具的存在主要是为了允许移植Unix程序在Windows上本机运行（即不需要POSIX仿真层）。MSYS2并不试图复制Cygwin的工作，因此提供的POSIX仿真软件数量非常少。
2).MSYS2使用Pacman（来自Arch Linux）来管理其软件包，并附带三个不同的软件包存储库：
msys2：包含依赖msys2的软件
mingw64：包含64位本机Windows软件（使用mingw-w64 x86_64工具链编译）
mingw32：包含32位本机Windows软件（使用mingw-w64 i686工具链编译）
Cygwin只附带依赖Cygwin的软件。它使用自己的包管理系统，通常称为setup.exe。
3).Cygwin提供了一个名为cygwin1.dll，在必要时提供POSIX兼容层。该库的MSYS2变体称为msys-2.0.dll，包括以下更改以支持使用本机Windows程序：
(1).动态地将命令行参数和环境变量的路径自动分配到Windows窗体。（这可以有选择地关闭。）
(2).能够使用环境变量（MSSYSTEM，值为MSYS2、MINGW32和MINGW64）更改报告的操作系统。这使得mingw-w64软件可以在本机构建模式下构建（与交叉编译模式相反）。
(3).通过删除尾随“\r”字符，将本机Windown应用程序的输出从Windows行结尾转换为POSIX行结尾，以便如bb=$（gcc--打印搜索目录）按预期工作。
(4).用复制替换符号链接，这样Windows程序就不会在这些文件上出错。MSYS2还支持创建本机NTFS符号链接，但在其他方面受到限制。
(5).删除自动装载的/cygdrive前缀。这是为了保持与支持MSYS的软件的兼容性，该软件假设/c/等同于c:/，并且节省了一点输入。
(6).在默认挂载上切换到noacl。这可以防止来自MSYS2的任何权限损坏。
MSYS2版本可能在Cygwin版本之前或之后。
4).其他显著差异：
(1).系统根目录是/usr，不是/。
(2).删除系统集成内容，例如cyglsa、cygserver、cygstart。
(3).动态库的前缀是msys而不是cyg（大多数其他平台，包括mingw-w64，都使用lib）。
(4).在shell中的pwd命令中添加“-W”选项，以与旧的MSYS兼容。
实用程序中的各种更改有助于保持兼容性和互操作性。例如Perl将msys报告为$^O，或者Sed将CRLF识别为行尾。
MinGW与Cygwin
MinGW和Cygwin是两个在Windows平台上广泛使用的开发工具，它们各自具有不同的特点和适用场景。Cygwin率先于1995年诞生，目标是让Windows具备完整的Linux开发环境；而MinGW出现在1998年，是对Cygwin“太重”的一种反思和简化。
MinGW 的主要方向是让GCC的Windows移植版能使用Win32API来编程，其几乎支持所有的Win32API。Cygwin 的主要方向是让Unix-like下的程序代码在Windows下能被编译成功。使用Cygwin可以在Windows下调用Unix-like的系统函数，如进程函数等。虽然Cygwin是运行在Windows下的，但是它还是使用的是Unix-like系统的函数和思想。
MinGW是一个极简主义派。它的目标很明确：让GNU工具链在Windows上原生运行，生成纯粹的Windows原生可执行文件；而Cygwin则是一个兼容主义派，它致力于在Windows上构建一个完整的POSIX兼容层，通过cygwin1.dll这个“魔法翻译层”，让Linux程序几乎无需修改就能在Windows上编译运行。
1、定义与目标：
MinGW是一个用于Windows平台的开发工具集，提供了一组GNU工具和库，比如GCC，从而让Windows 用户可以用上GNU 工具。主要目标是允许开发者在Windows环境下编写和编译C、C++等程序，生成本地的Windows应用程序，而不需要第三方C运行时库。
Cygwin 提供完整的类Unix 环境，是一个在Windows平台上运行的类UNIX模拟环境，它提供了一个UNIX模拟DLL以及在其上层构建的多种可以在Linux系统中找到的软件包。Windows 用户不仅可以使用GNU 工具，理论上Linux 上的程序只要用Cygwin 重新编译，就可以在Windows 上运行。其主要目标是模拟UNIX/Linux环境，使得开发者可以在Windows上进行与UNIX/Linux相似的开发工作，或者将UNIX/Linux下的应用程序移植到Windows上。
2、功能与组件：
MinGW主要包括GCC（GNU Compiler Collection）编译器套件和运行时库。GCC用于编译和生成Windows平台下的可执行文件，而运行时库则提供了Windows下所需的C和C++运行时环境。如果程序只用到C/C++ 标准库，可以用MinGW或Cygwin编译。
Cygwin则提供了更广泛的UNIX环境模拟，包括shell、文件系统、网络等功能。它允许开发者在Windows上运行许多原本只能在UNIX/Linux上运行的工具和程序。如果程序还用到了POSIX API，则只能用Cygwin 编译。
3、依赖
程序经MinGW编译后可以直接在Windows上面运行。MinGW环境下编译出来的程序，只能在Windows下跑，源码在Linux环境下编译多半通不过，因为使用到了Windows下的API。
程序经Cygwin编译后需要依赖安装时附带的cygwin.dll才能在Windows下运行，源码放到Linux环境下重新编译就可以在其上跑起来。
4、适用场景
MinGW更适合那些只需要在Windows上编写和编译C、C++等程序，且希望保持与Windows环境紧密集成的开发者。它提供了本地化的开发体验，生成的程序也是针对Windows平台的。
Cygwin则更适合那些需要在Windows上模拟UNIX/Linux环境进行开发或移植工作的开发者。它允许开发者在Windows上使用熟悉的UNIX工具和命令，提高了跨平台开发的便利性。
5、性能与部署
在性能方面，两者的差异十分明显：
MinGW程序：由于直接调用Windows API，运行时开销极小，性能接近Visual Studio编译的程序；
Cygwin程序：每次系统调用都需要经过cygwin1.dll的转换，性能损失通常在10%-30%之间。
部署成本的现实考量
依赖关系决定了选择：
MinGW程序可以独立运行，直接拷贝exe文件即可；
Cygwin程序必须携带cygwin1.dll，或者确保目标系统已安装Cygwin运行环境。
MinGW更专注于Windows平台的本地开发，而Cygwin则更侧重于为Windows环境提供UNIX/Linux环境的模拟。而随着技术的发展，新的竞争者正在改变格局：
WSL/WSL2：提供了真正的Linux内核兼容性；
MSYS2：结合了MinGW的轻量和Cygwin的软件包丰富性。
但MinGW和Cygwin依然在特定场景下不可替代：嵌入式交叉编译、遗留项目维护、特定行业的合规要求等；另外需求也是一项因素：运行时环境、复杂的编译选项、性能要求。它俩各有其不可替代的价值。MinGW以其简洁高效赢得了原生应用开发者的青睐，Cygwin凭借其强大兼容性成为Linux程序移植的首选。在这个Docker和WSL盛行的时代，理解这些经典工具的区别，不仅是为了解决当下的问题，更是为了培养正确选择技术方案的能力。
Linux has officially won
Apple Container v1.0.0 与微软的 WSL Containers。
Apple 做出了一个 Linux 容器运行时。2026年6月上旬，Apple 在 GitHub 上发布了 Container v1.0.0，Apache 2.0 协议，用 Swift 写成，专为 Apple Silicon 设计。截至2026年7月上旬已收获超过 26000 个 Star。其工作方式也很 Apple：每个容器跑在独立的轻量级虚拟机里，完整实现 OCI 兼容。这意味着你可以在 macOS 上直接运行 Docker/OCI 镜像，不需要 Docker Desktop，不需要 Podman，不需要任何第三方工具。Apple 自己下场给 macOS 做了原生 Linux 容器支持。可以拉一个 Ubuntu、Debian、Alpine，在 macOS 上原生跑起来 ——Apple 帮你管内核，管隔离，管网络。不过微软那边也没闲着。
微软在 Build 2026 上宣布了 WSL Containers，7 月开始公开预览。核心命令是 wslc.exe，本质是在 Windows 11 里原生运行 Linux 容器，同样不需要 Docker。还放出了 WSL Containers API，支持 C、C++ 和 C#，开发者可以把容器管理能力直接嵌入自己的应用。
macOS 和 Windows 这两个加起来占桌面操作系统 99% 以上的平台，现在都把 Linux 容器作为一等公民来支持。不是通过 Docker 这种第三方中间层，而是操作系统级别的原生集成。Reddit 评论区最高亮的回复一针见血：「Linux 赢了，只是赢的方式和大家想的不一样。它不是取代了 Windows 或 macOS，而是变成了它们都愿意为之提供原生支持的通用运行时。」
还有一个角度值得玩味：两家公司做这件事的动机完全不同。Apple 是为了让开发者能在 Mac 上构建和测试 Linux 工作负载，巩固 Mac 作为开发者首选工具的地位。微软则是为了把 Windows 变成云原生开发的第一站。但不管动机是什么，结果是一样的 ——Linux 容器成为了跨平台的通用语言。
「Linux 已经赢了」这种话被说了二十年，每次说的理由都不一样。但这次可能是最站得住脚的一次。不是因为它打败了谁，而是因为所有人都选择支持它。从评论区的反应看，多数人认同这个判断。有人调侃「下一步是 Apple 把 XNU 换成 Linux 内核」，有人认真讨论这个趋势对 Docker 公司意味着什么。但质疑声也有 ——「WSL 本来就是跑 Linux 的，这不算新闻」；不过反驳的人更多：WSL 是虚拟机里跑 Linux，WSL Containers 是原生容器运行时，两者的技术路径完全不同。
Apple Container 和 WSL Containers 都还年轻。前者目前只支持 Apple Silicon，后者还在预览阶段；但它们都指向同一个方向：在这个方向上，Linux 不是操作系统的选择之一，而是所有操作系统的底层共识。