从 WSL（Windows Subsystem for Linux）到 WSL9x，计算历史正在以有趣的方式自我重构。WSL9x 作为 Windows 9x Subsystem for Linux 的实现，本质上构建了一个协作式双内核运行环境：现代 Linux 内核（6.19 版本）在 Windows 9x 内核内部 cooperatively 运行。这一架构与 Windows NT 的子系统模型有着本质区别，却为理解 API 翻译层提供了绝佳的技术参照。
NT 子系统模型与协作式内核的根本差异
理解 WSL9x 的技术定位，首先要厘清 Windows NT 子系统模型与协作式内核架构的根本差异。Windows NT 从设计之初便支持多个 “子系统” 并行运作：Win32 子系统负责传统的 Windows 应用程序，POSIX 子系统则服务于 Unix 兼容应用。每个子系统都通过 NT Executive 层与内核核心交互，而应用程序调用的是子系统特定的 API 集合 ——Win32 应用程序调用 Win32 API，POSIX 应用程序调用 POSIX 接口，NT Executive 则充当统一的内核抽象层。
然而，Windows 9x 并不具备这种分层子系统架构。Windows 9x 建立在一个更简单的基础上：DOS 内核加上 16/32 位混合的 Windows 运行环境。Windows 9x 的 DOS 部分处理实模式引导和基本硬件抽象，而 Windows 运行环境（KRNL386.EXE、GDI.EXE、USER.EXE 等组件）则负责图形界面和 Win16/Win32 API 的提供。由于缺乏类似 NT Executive 的统一内核抽象层，WSL9x 无法简单地 “植入” 一个子系统层来实现 Linux 兼容；相反，它采用了完全不同的协作式内核方案。
协作式内核（Cooperative Kernel）的核心思想是让两个内核共享硬件控制权，通过协商和让渡而非硬件虚拟化来实现共存。这一范式在 Cooperative Linux（coLinux）项目中已有先例：coLinux 让 Linux 内核与 Windows NT 内核以协作方式运行于同一硬件上，通过细粒度的调度点切换实现双内核的时间片分配。WSL9x 将这一范式 “镜像化”——Windows 9x 内核作为宿主，Linux 内核作为协作子系统运行于其内部。这意味着 Windows 9x 的调度器需要被修改以支持协作式切换点，而 Linux 内核则被调整为调用 Windows 9x 的内核 API 而非传统的 POSIX/Linux syscall 接口。
API 翻译层的分层设计原理
理解了双内核协作的基本框架后，技术探索的核心转向 API 翻译层的设计。假设要构建一个能够桥接 Win32 API 调用与 Linux syscall 的系统，其核心挑战在于两个维度的语义映射：函数签名转换和数据格式规范化。
函数签名的转换涉及参数类型的重新解释。例如，Win32 的 CreateFile 函数接受一组标志位（FILE_FLAG_WRITE_THROUGH、FILE_FLAG_OVERLAPPED 等），这些标志需要被映射到 Linux open (2) 的 flags 参数。语义层面的差异更大：Win32 的 HANDLE 概念对应 Linux 的文件描述符整数，但 HANDLE 空间中同时包含文件句柄、事件句柄、进程句柄等多种类型，而 Linux 的整数描述符仅适用于文件 / 套接字等少数对象。这要求翻译层维护一张 Handle 映射表，记录每个 Win32 HANDLE 的内部类型和对应的 Linux 资源。
数据格式规范化则涉及字符串编码和结构体布局。Win32 API 广泛使用 UTF-16 编码的宽字符串（LPWSTR 类型），而 Linux syscall 使用 UTF-8 编码的字节串。这意味着每一次字符串参数的传递都需要经过编码转换。此外，Win32 API 的参数中大量使用结构体（如 STARTUPINFO、WNDCLASS 等），这些结构体的内存布局与 Linux 等效结构体（如 stat 结构）存在显著差异。翻译层必须实现结构体的字节级重新打包，将 Win32 结构体的字段顺序和类型映射到目标系统的等效表示。
在 WSL9x 的实际实现中，这种翻译被进一步复杂化：由于 Linux 内核被直接嵌入 Windows 9x 的地址空间运行，Linux 内核代码中的 syscall 入口点被替换为调用 Windows 9x 的内核 API。例如，当 Linux 程序发起 read (2) 系统调用时，这个调用被路由到 WSL9x 实现的翻译层，该层将参数解包后调用 Windows 9x 的文件读取接口（如_DosOpen 等内部 API），然后将结果重新打包返回给 Linux 一侧。
PESi 加载器的工程实现路径
如果将视角从 API 翻译层扩展到完整的程序加载流程，PESi 加载器（PE Subsystem for Linux Loader）代表了另一个关键工程挑战。PE（Portable Executable）是 Windows 可执行文件的格式标准，包括 EXE 和 DLL 两种变体。Windows 9x 程序大多是 PE 格式的 32 位可执行文件，要让它们在 Linux 环境（即使是通过协作式内核嵌入的 Linux）中运行，需要实现 PE 文件的加载和执行机制。
PE 加载器的核心职责包括：解析 PE 文件头（DOS MZ header、PE header、节表）以定位代码段和数据段；建立内存映射，将各个节加载到目标地址空间；重定位（relocation）处理，当加载地址与预设基址不匹配时修正绝对地址引用；导入表（Import Table）解析，解析 DLL 依赖并加载所需库；以及 TLS（Thread Local Storage）初始化，为线程本地存储分配槽位。
在传统 Wine 环境下，这些工作由 Wine 的 PE 加载器（winevdm、wineserver 等组件）完成。但 WSL9x 的上下文更为特殊：它运行的是完整的原生 Linux 内核，理论上不能直接执行 PE 格式代码。这意味着 WSL9x 如果要在 Linux 子系统上运行 Windows 9x 程序，需要借助某种二进制翻译或即时编译（JIT）机制来弥合 PE 与 ELF 的格式差异。
一种可能的实现路径是基于指令翻译的混合方法：PE 加载器将 PE 代码段加载到专用内存区域，当执行流进入该区域时，JIT 编译器实时将 x86 指令序列翻译为等效的 Linux syscall 调用序列。例如，一个调用 CreateFile 的 Win32 API 调用可能被翻译为一组 open、mmap 等 Linux 操作的序列。这种方法类似于早期 Macintosh 模拟器或 QEMU 的用户模式 emulation，但针对 PE-to-ELF 的特定翻译进行了优化。
另一种路径是采用 libbfd 或 LLVM MC 等工具库进行静态二进制翻译，在 PE 文件加载时离线生成等效的 ELF 中间表示，随后像本地程序一样执行。这种方法的优点是运行时开销较低，但翻译过程复杂且需要处理各种反调试和自修改代码。
协作式调度与资源争用的工程参数
协作式双内核架构中另一个不可忽视的工程挑战是资源争用和调度同步。在协作式调度模型中，内核之间的切换依赖于显式的让出点（yield points），这要求两个内核在关键路径上插入协作切换逻辑。当 Linux 内核尝试访问由 Windows 9x 内核管理的资源（如物理内存、磁盘缓存）时，必须通过精心设计的同步原语来协调。
工程实践中需要关注的参数包括：切换粒度（switching granularity），即每次协作切换允许一个内核运行的时间片长度，过短导致切换开销过大，过长则影响响应延迟；同步原语类型，可选用自旋锁、信号量或消息队列来实现跨内核同步；以及内存视图一致性，确保两个内核对物理内存内容的观察在切换点保持一致。
这些工程参数的具体取值通常依赖于目标工作负载的特性。对于以交互式 GUI 应用为主的 Windows 9x 程序，可能需要更细粒度的切换以保证图形响应的流畅性；对于计算密集型负载，则可以接受较长的片以减少切换开销。
WSL9x 项目目前仍处于实验阶段，其实际实现细节可能与上述分析有所不同。但从技术原理层面看，它提供了一个极具价值的案例，用于理解 API 翻译层、程序加载器和协作式内核调度等核心系统工程概念。这些概念在跨系统兼容层的设计中具有普遍意义，无论是 Wine 的 Win32 实现、WSL 的 Linux syscall 翻译，还是未来的其他跨平台兼容方案。
参考资料
- WSL9x 项目主页：https://codeberg.org/hails/WSL9X
- Hackaday 关于 WSL9x 的技术报道（2026 年 4 月）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。