Windows NT vs. Unix: A design comparison

September 27, 2024

翻译自：https://blogsystem5.substack.com/p/windows-nt-vs-unix-design
Windows NT vs. Unix: A design comparison — by Julio Merino

NT 经常被吹捧为“非常先进”的操作系统。这是为什么呢？是什么让 NT 比 Unix 更好？现在还是这样吗？

多年来，我反复听说 Windows NT 是一个非常先进的操作系统，作为一名 Unix 用户，我一直被不知道 为什么 （它很先进）而困扰。多年来，我一直想回答这个问题，现在我可以回答了，这意味着我想向你们介绍我的发现。

我对 NT 内部结构的渴望始于 2006 年，当时我申请了 Google Summer of Code 计划来开发 Boost.Process。我需要为 ATF 开发这样一个库，但我也将该项目视为学习 Win32 API 的机会。然后，这段旅程在 2020 年继续，我在 Google 工作了很长时间后选择加入 Microsoft，并在 2021 年购买了 Windows Internals 第 5 版书（由于其令人难以置信的细节和篇幅，我从未完全阅读过这本书）。然而，这些都没有让我学到我想要的东西：NT 与 Unix 的根本区别（如果有的话）。

然后，在 2023 年底，Showstopper 这本书再次激发了（我的）这种好奇心。很快，一个新的想法浮现在脑海中：Windows Internals 第 5 版这本书太晦涩了，但是……第一版呢？当然，这本书肯定更容易消化，因为上世纪 90 年代初的系统要简单得多。于是，我搜索到了这一版本，并在标题 Inside Windows NT 下找到了它，从头到尾读了一遍，并做了笔记，来评估 NT 与 Unix 的对比。

这就是我写这篇文章的初衷 —— 将 NT 的设计（1993 年 7 月）与当代 Unix 系统（如 4.4BSD 系统（1994 年 6 月）或 Linux 1.0 系统（1994 年 3 月））进行比较的一些想法。请注意，由于我的背景，这篇文章是从一个 Unix “专家”和一个 NT “无知者”的角度来写的，因此它侧重于描述 NT 的不同之处。

任务

Unix 的历史很长 —— 比 NT 的历史要长得多。Unix 的开发始于 1969 年，其主要目标是为程序员提供一个方便的平台。Unix 的灵感来自 Multics，但与其它系统相比，Unix 专注于简单性，这是它战胜 Multics 的一个特质。不过，可移植性和多任务处理并不是 Unix 设计的最初目标：这些功能在几年后 Unix 的许多 “分叉” 和重塑中得到了改造。

反观 Microsoft 这边，MS-DOS 的第一个版本于 1981 年 8 月推出，“旧版 Windows”（基于 DOS 的版本）的第一个版本于 1985 年 11 月推出。虽然 MS-DOS 取得了广泛的成功，但直到 1990 年 5 月的 Windows 3.0 才真正开始变得重要。Windows NT 构思于 1989 年，并在 1993 年 7 月问世发布 NT 3.1。

这个时间线给了 Microsoft 一个优势：NT 的设计比 Unix 晚了 20 年，凭借 MS-DOS 和旧版 Windows，Microsoft 已经拥有庞大的用户群。设计 NT 的 Microsoft 团队对这些发展有后见之明，以前有开发其它操作系统的经验，并且可以使用更现代的技术，因此他们可以在创建 NT 时“一步登天”。

特别是，作为其使命的一部分，NT 从以下设计目标开始，这些目标与 Unix 的形成鲜明对比：

可移植性；
支持多处理器系统（SMP）；
与 DOS、旧版 Windows、OS/2 和 POSIX 兼容。

这些目标不容小觑，这意味着 NT 从一开始就有着坚实的设计准则。换句话说：这些功能从第一天起便已存在，而不像许多 Unix 系统那样在后期才被添加进去。

内核

现在我们知道了其中一些设计目标和约束，让我们看看它们实现的细节。

除了 Minix 或 GNU Hurd 等少数例外，Unix 是作为宏内核实现的，它暴露一系列系统调用来与操作系统提供的功能进行交互。另一方面，NT 是宏内核和微内核的混合体：其特权组件，被称为 执行体（executive），以模块化组件的集合形式呈现给用户空间 子系统（subsystems）。用户空间子系统是特殊的进程，它将应用程序使用的 API（POSIX、OS/2 等）“翻译”为执行体的系统调用。

NT 执行体的一个重要部分是硬件抽象层（HAL），这是一个提供抽象原语以访问机器硬件的模块，也是内核其余部分的基础。这一层是让 NT 能在各种架构上运行的关键，包括 i386、Alpha 和 PowerPC。要理解 HAL 的重要性，我们可以看看同时期的 Unix：是的，Unix 作为一个概念是可移植的，因为存在许多针对不同机器的不同变体，但其实现并不可移植。 SunOS 最初只支持 Motorola 68000；386BSD 是首个移植到 Intel 架构的 BSD；IRIX 是为 Silicon Graphic 基于 MIPS 的工作站设计的 Unix 变体；诸如此类。这解释了为什么 NetBSD 主要关注通过在硬件之上提供最小 shim 来实现可移植性，在当时是如此有趣：除了 NT ，其它操作系统内部都没有这种清晰的设计，而 NT 在这方面早已有了领先。

NT 执行体的另一个重要组成部分是它对多处理系统的支持和它的抢占式内核。内核有各种中断级别（在 BSD 术语中称为 SPLs ）来决定什么可以中断什么（例如，时钟中断比磁盘中断有更高的优先级），但更重要的是，内核线程可以被其它内核线程抢占。这“当然”是如今每个高性能 Unix 系统所做的，但这并不是许多 Unix 系统最初的样子：最初的内核不支持抢占也不支持多处理；然后添加了对用户空间多处理的支持；最后才添加了内核抢占。后者是所有步骤中最困难的，这解释了 FreeBSD 5.0 的惨痛经历。因此，看到 NT 从一开始就有正确的基础是很有趣的。

对象

NT 是面向对象的内核。你可能会认为 Unix 也是：毕竟，进程是由结构体定义的，文件系统实现处理的是 vnode（“虚拟节点”，不要与 inode 混淆，后者是特定于文件系统的实现细节）。但这与 NT 所做的并不完全相同：NT 强制所有这些不同的对象在系统中有一个共同的表示方式。

你可能会对此持怀疑态度，因为……如何能对进程和文件句柄这样截然不同的东西提供一个有意义的抽象呢？实际上是很难做到的，但 NT 强制所有这些都继承自一个共同的对象类型，令人惊讶的是，这带来了一些不错的特性：

集中式访问控制：对象只能由 对象管理器 创建，这意味着在代码中只有一个地方来执行策略。这很强大，因为例如权限检查的语义可以只在一个位置定义，并在整个系统中统一应用。NetBSD 也得出这是个好主意的结论，但直到 2001 年才获得其内核授权（kauth）框架。
共同身份：对象有身份，它们都在一个单一的树中表示。这意味着所有对象都有一个唯一的命名空间，无论我们谈论的是进程、文件句柄还是管道。树中的对象可以通过名称（路径）来寻址，树的不同部分可以由不同的子系统拥有。例如，树的一部分可以代表一个挂载的文件系统，因此遍历该子树的根节点将导致文件系统解析路径的剩余部分。这类似于 Unix 系统的 VFS 层，区别在于 VFS 专门用于文件系统，而对象树是关于每一个内核对象的。诚然，Unix 试图通过 /proc/、/sys/ 等将其它类型的非文件对象塞进文件系统，但与 NT 提供的相比，这些感觉像是事后想法。
统一的事件处理：所有对象类型都有一个“信号状态”，其语义对每种对象类型都是特定的。例如，当进程退出时，进程对象进入信号状态；当 I/O 请求完成时，文件句柄对象进入信号状态。这使得在用户空间编写事件驱动代码（咳咳，异步代码）变得很简单，因为单个等待式系统调用可以等待一组对象改变它们的状态 — 无论它们是什么类型。试图在 Unix 系统上同时等待 I/O 和进程完成是非常痛苦的。

对象是 NT 特有的构造，然而它们并不能很好地泛化到 NT 打算支持的所有 API。POSIX 子系统就是一个例子：POSIX 没有与 NT 相同的对象概念，但 NT 必须为 POSIX 应用程序提供某种兼容性。因此，虽然 POSIX 子系统从执行体分配对象，但这个子系统必须保持自己的簿记（译注：bookkeeping）来表示相应的 POSIX 实体，并在运行时进行两者之间的逻辑转换。另一方面，Win32 子系统则直接将对象交给客户端，没有中间层。

进程

进程在 NT 和 Unix 中都是常见的实体，但它们并不完全相同。在 Unix 中，进程以树状结构表示，这意味着每个进程都有一个父进程，且一个进程可以有零个或多个子进程。然而在 NT 中，并不存在这种关系：进程可以从其创建者“继承”资源 — 基本上是任何类型的对象 — 但在创建后它们就是独立的实体。

在 NT 设计时，线程并不常见：Mach 在 1985 年成为第一个集成线程的类 Unix 内核，这意味着其它 Unix 系统后来才采用这个概念，并不得不将其改造到现有的设计中。例如，Linux 在 1996 年 6 月发布的 2.0 版本中选择将线程表示为进程，每个线程都有自己的 PID；而 NetBSD 直到 2004 年的 2.0 版本才引入线程，将其表示为与进程分离的实体。与 Unix 相反，NT 从一开始就选择支持线程，因为知道线程是 SMP 机器（译注：多处理器系统）上高性能计算的必要条件。

NT 在传统 Unix 意义上并没有信号。然而，它确实有 alert（警报），并且可以分为内核态和用户态。用户态警报像其它对象一样必须被等待，而内核态警报对进程是不可见的。POSIX 子系统使用内核态警报来模拟信号。值得注意的是，信号在 Unix 中常被称为一种缺陷，因为它们会干扰进程的执行：正确处理信号是一项非常困难的任务，所以 NT 的替代方案看起来更优雅。

在 NT 领域中最近一个有趣的发展是引入了 picoprocess（微进程）。在添加这个功能之前，NT 中的进程是相当笨重的：新进程在启动时会将一大堆 NT 运行库映射到它们的地址空间中。在微进程中，进程与 Windows 架构的联系极少，这种设计被用来在 WSL 1 中实现与 Linux 兼容的进程。某种意义上，微进程比原生 Windows 进程更接近 Unix 进程，但由于向 WSL 2 的过渡，微进程目前的应用已经不多了，尽管它们自 2016 年 8 月才存在。

最后，尽管我们经常批评 Windows 的安全问题，NT 起初在早期互联网标准方面就采用了先进的安全设计，因为该系统基本上是一个基于能力（capability-based）的系统。登录后启动的第一个用户进程会从内核中获得一个访问令牌，代表用户会话的权限，该进程及其子进程必须向内核提供此令牌以断言它们的权限。这与 Unix 不同，Unix 进程只具有标识符，内核需要在进程表中跟踪每个进程的权限。

兼容性

正如简介中提到的，NT 的一个主要目标是与为旧版 Windows、DOS、OS/2 和 POSIX 编写的应用程序兼容。其中一个原因是技术上的，因为这迫使系统具有优雅的设计；另一个原因是政治上的，因为 NT 是与 IBM 的联合开发，NT 必须支持 OS/2 应用程序，即使 NT 最终成为 Windows。

这种对兼容性的需求迫使 NT 的设计与 Unix 的设计截然不同。在 Unix 中，用户空间应用程序通过其系统调用接口直接与内核通信，这个接口就是Unix 接口。通常（但并非总是），C 库提供了调用内核的粘合剂（胶水代码），而应用程序本身从不发出系统调用，但这只是一个小细节。

与此相反，在 NT 中，应用程序不直接与执行体（内核）通信。相反，每个应用程序都与一个特定的受保护子系统通信，而这些子系统是实现 NT 希望与之兼容的各种操作系统的 API 的子系统。这些子系统作为用户空间服务器实现（它们不在 NT “微内核”中）。对 Windows 应用程序的支持来自 Win32 服务器，这很特殊，因为它是唯一一个用户可以直接看到的服务器：它控制控制台程序和 DOS 终端，并且出于性能原因具有某些权限。

与传统的 Unix 相比，NT 的设计非常不同，因为 BSD 和 Linux 具有宏内核。这些内核通过系统调用接口向用户空间应用程序暴露，使它们可以直接与系统交互。然而，BSD 系统长期以来提供了运行不同二进制文件的支持，所有这些都在宏内核中完成：其工作原理是根据正在运行的二进制文件向用户空间暴露不同的系统调用表，然后将这些“外来的”系统调用翻译成内核可以理解的形式。Linux 也通过 personality 提供了有限的支持。

尽管 BSD 的方法与 NT 处理其它系统的方式大不相同，WSL 1 的设计却非常相似，并不符合子系统的原始定义。在 WSL 1 中，NT 内核将 Linux 进程标记为微进程（picoprocess），然后向它们暴露不同的系统调用接口。在 NT 内核中，这些特定于 Linux 的系统调用被转换为 NT 操作，并在同一内核中提供，就像 BSD 的 Linux 兼容性一样。唯一的问题是，NT 不是 Unix，它对 Linux 的“模拟”很棘手，而且比 BSD 所能提供的要慢得多。遗憾的是，WSL 2 失去了这种设计的精髓，转而采用了全面的 VM 设计……

在结束这一节之前，还有两个有趣的细节：NT 设计的一个目标是允许在单个 shell 中实现子系统之间的无缝 I/O 重定向；子系统通过 port 暴露给应用程序，这些 port 当然是 NT 对象，类似于 Mach 允许进程和服务器之间通信的方式。

虚拟内存

NT 和 Unix 一样，依赖于内存管理单元（MMU）和分页来提供跨进程的保护和虚拟内存。在用户空间进程中进行分页是一种常见机制，可以使它们拥有比机器上的物理内存更大的地址空间。但是，NT 提前于当代 Unix 系统的一件事是内核本身也可以被分页到磁盘上。显然不是整个内核 —— 如果所有内容都可以分页，那么当解析内核页错误时，可能需要从已分页的文件系统驱动程序中获取代码 —— 但其中的大部分是可以分页的。这在当今并不特别有趣，因为与机器上典型的安装内存相比，内核很小，但在过去，每个字节都是宝贵的，这当然会产生很大的差异。

此外，虽然我们现在认为虚拟内存和分页的工作方式是理所当然的，但在设计 NT 时，这是一个重要的研究领域。旧的 Unix 实现为文件系统和虚拟内存分别设置了内存缓存，直到 1987 年 SunOS 才实现了统一的虚拟内存架构，以减少这种旧设计的开销。

相比之下，NT 从一开始就采用了统一的内存架构。你可能会说这很容易做到，因为他们可以看到 Unix 中发现的低效率，并且在 NT 设计开始之前就可以看到 SunOS 实现的解决方案。但是不管怎样，这使得 NT 在当时比许多其它操作系统“更先进”，必须指出的是，其它系统如 NetBSD 直到 2002 年才在 NetBSD 1.6 中实现了统一缓冲区缓存（UBC）。

NT 和 Unix 之间一个有趣的区别是它们如何管理和表示共享内存。在 NT 中，共享内存段是（令人惊讶的）对象，因此受到与任何其它对象相同的访问验证检查的影响。此外，它们可以像任何其它对象一样寻址，因为它们是单个对象树的一部分。与之相反，Unix 中的这个特性是后来添加的：共享内存对象有一个不同的命名空间。

I/O 子系统

Unix 的早期版本仅支持一种文件系统。例如，直到 1990 年的 4.3BSD 版本，BSD 才获得了虚拟文件系统（VFS）抽象，以支持 UFS 之外的其它文件系统。另一方面，NT 一开始就采用了允许多种文件系统的设计。

为了支持多种文件系统，内核必须以某种方式公开它们的命名空间。Unix 通过挂载点将文件系统组合在一个文件层次结构下：VFS 层提供了识别哪些节点对应于文件系统根目录的机制，并在遍历路径时将请求重定向到这些文件系统驱动程序。NT 有类似的设计，即使从标准用户界面来看，文件系统看起来像是不连续的驱动器：在内部，执行体将文件系统表示为对象树中的对象，每个对象负责解析路径的其余部分。这些文件系统对象被重新映射为 DOS 驱动器，以便用户空间可以访问它们。而且，你猜怎么着？DOS 驱动器也是一个单独子树下的对象，它将 I/O 重定向到它们引用的文件系统。

对于文件系统，NT 最终使用了 NTFS。NTFS 在当时是一个非常先进的文件系统，即使我们喜欢因其性能差而抨击它（其实这是一个错误的说法）。NT 的 I/O 子系统与 NTFS 相结合，带来了 64 位寻址、日志记录，甚至是 Unicode 文件名。Linux 直到 1990 年代末才获得了 64 位文件支持，直到 2001 年 ext3 的推出才获得了日志记录。FreeBSD 直到 1998 年才出现了另一种容错机制 Soft updates。并且 Unix 将文件名表示为 nul 结尾的字节数组，而非 Unicode。

NT 在发布时包含的其它功能包括磁盘分割和镜像（我们今天所知道的 RAID）和设备热插拔。鉴于 SunOS 自 1990 年代初以来就确实包括 RAID 支持，这些功能并不是什么新鲜事，但有趣的是，这些功能都是作为 NT 原始设计的一部分考虑的。

在更高层次上，使 NT 的 I/O 子系统比 Unix 的 I/O 子系统先进得多的是，它的接口是异步的，并且从一开始就是这样。从这方面来看，FreeBSD 直到 1998 年的 FreeBSD 3.0 才支持 aio(7)，Linux 也是直到 2002 年的 Linux 2.5 才支持。即使异步 I/O 的支持在 Unix 系统中已经存在了 20 多年，它仍然不是普遍的：很少有人知道这些 API，绝大多数应用程序不使用它们，且它们的性能很差。Linux 的 io_uring 是一个相对较新的功能，它改进了异步 I/O，但它一直是安全漏洞的一个重要来源，而且并没有得到广泛使用。

联网

今天互联网无处不在，但在设计 NT 时，情况并非如此。回顾微软生态系统，DOS 3.1（1987 年）包含了 FAT 文件系统中的文件共享基础，但“操作系统”本身并未提供任何网络功能：一个名为 Microsoft Networks（MS-NET）的单独产品提供了这些功能。Windows 3.0（1990 年）包含了对 NetBIOS 的支持，这允许在本地网络上进行原始的打印机和文件共享，但是对 TCP/IP 的支持却无处可寻。

相比之下，Unix 简直就是互联网：所有基础互联网协议都是为它编写、用它编写的。因此，在设计 NT 时，考虑到良好的网络支持至关重要，事实上 NT 确实带有网络功能。因此，NT 支持互联网协议和传统的 LAN 协议，这使其在企业环境中领先于 Unix。

以 NT 的网络域为例。在 Unix 中，网络管理员通常手动跨计算机同步用户帐户，他们可能会使用 X.500 目录协议（1988 年）和 Kerberos（1980 年代）进行用户身份验证，像 SunOS 这样的系统实现了这些技术，但这些技术并不特别简单。相反，NT 从一开始就提供了域，它集成了目录和身份验证功能，我认为这些在公司网络中“赢得了胜利”，因为它们更容易设置，并且内置在系统中。

同步用户帐户的目标是跨计算机共享资源，主要是文件，当共享时，表示权限的方式很重要。很长一段时间以来，Unix 只为每个文件提供了简单的读/写/执行权限集。另一方面，NT 从一开始就提供了高级 ACL — 这在 Unix 上仍然是一个痛点。尽管 Linux 和 BSD 现在也有 ACL，但它们的接口在系统之间不一致，感觉像是对系统设计的外来附加组件。在 NT 上，ACL 在对象级别工作，这意味着它们在所有内核功能中始终保持一致。

说到共享文件，我们必须谈论网络文件系统。在 Unix 中，事实上的文件系统是 NFS，而在 NT 上是 SMB。SMB 是从 MS-NET 和 LAN Manager 继承而来的，并通过一个名为 重定向器（redirector）的组件在内核中实现。本质上，重定向器“只是”另一个文件系统，就像 NFS 在 Unix 上一样，它会捕获文件操作并将其发送到网络上，这使我们可以比较 RPC 系统。

尽管 protobuf 和 gRPC 可能由于广泛使用而看起来像新颖的想法，但它们是基于旧想法的。在 Unix 上，我们从 1980 年代初就有了 Sun RPC，主要用于支持 NFS。同样，NT 通过自己的 DSL（称为 MIDL）提供了内置的 RPC 支持，用于指定接口定义并为远程过程生成代码，以及实现 RPC 客户端和服务器的自己的工具。

从堆栈中往下看，Unix 系统从来都不擅长支持任意驱动程序：请记住 Unix 系统通常与特定的机器和供应商耦合。另一方面，NT 旨在成为“任何”机器的操作系统，并由软件公司出售，因此支持他人编写的驱动程序至关重要。因此，NT 配备了网络驱动程序接口规范（NDIS），这是一个轻松支持网卡驱动程序的抽象层。直到今天，制造商提供的驱动程序在 Linux 上依然很少见，这带来了像 ndiswrapper 这样的有趣解决方案，这是 2000 年代初非常流行的一个 shim，可以在 Linux 上重用 Windows 驱动程序的 WiFi 卡。

最后，NT 和 Unix 之间的另一个区别在于它们对命名管道的实现。在 Unix 中，命名管道是一个本地构造：它们为同一台机器上的两个进程提供了一种机制，使它们可以通过磁盘上的持久文件名相互通信。NT 具有相同的功能，但其命名管道可以通过网络操作。通过将命名管道放在共享文件系统上，不同计算机上的两个应用程序可以相互通信，而无需担心网络细节。

用户空间

我保证，我们已经接近尾声了。这里仅简单介绍几个用户空间的主题：

配置：NT 将系统和应用程序配置集中在一个名为“注册表”的数据库中，摆脱了旧的 CONFIG.SYS、AUTOEXEC.BAT 和传统 Windows 使用的无数 INI 文件。这让一些人很生气，但最终，统一的配置接口对每个人都有好处：应用程序更容易编写，因为只有一个基础需要支持，用户更容易调整系统，因为只有一个地方需要查看。

另一方面，Unix 仍然受到数十种 DSL 和不一致的文件位置的困扰。每个支持配置文件的程序都有自己编制的语法，知道程序读取的位置很困难，而且并不总是有很好的文档。Linux 生态系统通过 XDG 和 dconf（以前是 GConf）推动了一种更像 NT 的方法，但是……这是一场艰苦的战斗：虽然桌面组件专门使用这些技术，但系统的基础组件可能永远不会采用它们，留下不一致的混乱。
国际化：作为一家已经在全球范围内交付 Windows 3.x 的大公司，微软理解本地化的重要性，并从一开始就使 NT 支持这一功能。相比之下，Unix 直到 1990 年代末才开始支持 UTF ，支持不同语言是通过可选的 gettext 附加组件实现的。
C 语言：FreeBSD 和 NetBSD 等 Unix 系统一直梦想自己创造一种 C 语言方言，以更安全地实现内核。然而，除了 Linux 依赖的 GCC 专有扩展，这种设想从未取得过实质性进展。另一方面，微软拥有 C 编译器的特权，因此他们确实在 NT 中使用了这种方法，NT 是用 Microsoft C 编写的。例如，NT 依赖于结构化异常处理（SEH），这是一种添加 try/except 子句以处理软件和硬件异常的功能。我不会说这是一个很大的优点，但这确实是一个区别。