为什么 Windows 在核心仍然抵制 POSIX（并且可能永远如此）
Source: Dev.to
Windows 并非源自 Unix
类 Unix 系统起源于共享机器，而 Windows 则起源于个人电脑。等 POSIX 成为标准时，Windows 已经拥有庞大的安装基数，并围绕 DOS 和早期 Windows API 构建了兼容层。重写基础以匹配 Unix 语义会破坏这种兼容性，Windows 选择了生存而非实现干净的 POSIX 实现。
POSIX 是一种哲学，而不仅仅是 API
POSIX 体现了一套关于进程管理、文件系统语义和进程间通信的假设。Windows 则围绕另一套理念设计——面向对象的句柄、统一的命名空间以及独特的安全模型。这些差异远不止表面的 API 不匹配；它们影响到操作系统的核心架构。
Windows NT 已经“走得太远”
当微软构建 Windows NT 时，团队做出了有意的设计选择，使其与 Unix 不同。NT 引入了受微内核启发的架构、不同的 I/O 模型以及基于访问令牌和自主访问控制列表（ACL）的安全子系统。那时，POSIX 兼容性只能通过仿真或兼容层来提供，而不能作为本地实现。
Microsoft 实际上曾多次尝试 POSIX
- POSIX 子系统（Windows NT 3.5） – 早期尝试，提供类 Unix 环境，但采纳率很低。
- Interix（Windows Services for UNIX） – 更完整的 POSIX 子系统，随 Windows Server 2003 及以后版本发布。
两种方案在技术上可行，但在经济上失败，因为 Windows 用户并不需要或想要在其主要工作负载中使用 Unix 语义。
兼容性陷阱（Windows 最大的优势）
Windows 最大的优势在于其向后兼容性。数十年前编写的软件仍能在现代 Windows 版本上运行。实现完整的 POSIX 合规性将需要更改系统的根本行为——进程终止、文件权限、路径处理等——这会破坏无数遗留应用程序。破坏这种兼容性的代价远大于实现 POSIX 一致性的任何好处。
为什么 WSL 存在（以及它为何不是 “POSIX Windows”）
Windows Subsystem for Linux（WSL）常被误解为 “POSIX Windows”。实际上：
- WSL 并不是在 NT 内核内部的原生 POSIX 实现。
- WSL 在 Windows 旁运行真正的 Linux 用户空间，将系统调用翻译为 Windows 内核，而不污染核心。
Microsoft 的经验教训很明确：“不要修改 NT 核心；相反要把 Unix 隔离起来。”WSL 为开发者提供 Linux 环境，同时保留 Windows 的原生架构。
POSIX vs. NT: 安全模型冲突严重
- POSIX 安全 依赖用户/组 ID、文件模式位和自主访问控制。
- Windows 安全 使用访问令牌、安全标识符（SID）以及丰富的 ACL 系统。
每种模型都有其优势和劣势，但它们在根本上不兼容。将一种模型映射到另一种不可避免地会丢失信息，使得无缝的 POSIX 安全层变得不切实际。
为什么完整的 POSIX 对 Windows 的伤害大于帮助
如果 Windows 要实现完全的 POSIX 兼容，它就必须放弃许多核心特性——基于注册表的配置、COM、NT 对象管理器以及细粒度的安全模型。这种取舍几乎没有商业价值，因为那些需要严格 POSIX 合规性的市场（高性能计算、嵌入式 Unix 系统）已经有原生的 Linux 发行版在服务。
现实：Windows 不需要 POSIX 也能胜出
Windows 在桌面生产力、企业应用、游戏以及云基础设施方面占据主导地位。POSIX 的优势主要体现在服务器端、科研和嵌入式环境——这些领域 Microsoft 已经通过 Azure、Kubernetes 和 WSL 采用了 Linux。通过在 Linux 擅长的地方进行集成，而不是重写 Windows，Microsoft 能在不放弃核心架构的前提下保持其市场地位。
开发者常忽视的重大教训
POSIX 不是一种道德标准；它是一种针对特定环境进行优化的设计选择。Windows NT 则针对另一种现实进行优化——面向大众的桌面计算、广泛的向后兼容性以及全面的安全模型。Windows 抵制 POSIX，因为采用它将需要进行根本性的重写，这会破坏它所依赖的生态系统。
Final Thought
问题不在于“为什么 Windows 没有完全支持 POSIX？”而在于“为什么 Windows 会放弃使其成功的平台？”操作系统的评价标准是它们解决了哪些问题，而不是架构的优雅程度。Windows 的依赖者太多，无法重写其核心，它通过不断适应而不是放弃核心来继续繁荣。