在操作系统兼容性领域，跨内核的系统调用转发一直是一个极具技术挑战性的方向。WSL9x 项目（即 Windows 9x Subsystem for Linux）近日在技术社区引发关注，该项目实现了在 Windows 95/98/ME 系统上运行 6.19 版本 Linux 内核的能力。与现代 Windows Subsystem for Linux（WSL）基于 NT 内核的架构不同，Windows 9x 采用的是完全不同的内核机制，这使得系统调用的转发面临独特的工程挑战。本文将深入分析 WSL9x 的核心技术实现，特别是其系统调用拦截与分发机制。
项目架构概述
WSL9x 项目由三个核心组件构成：经过补丁修改的 Linux 内核、用于 Windows 9x 的 VxD（虚拟设备）驱动程序，以及一个 16 位的 DOS 客户端程序。这种架构设计反映了在古老操作系统上运行现代内核的创造性思路。Linux 内核被修改为调用 Windows 9x 的 API 而非传统的 POSIX 接口，这是实现兼容性的基础前提。VxD 驱动程序则承担了繁重的底层协调工作，包括初始化子系统、处理用户空间事件以及在需要时向内核传递页面错误和系统调用请求。
与运行在现代 Windows 上的 WSL 不同，WSL9x 无法利用 Windows NT 内核提供的完善系统调用翻译层。Windows 9x 的内核架构相对简单，其虚拟机器管理器（VMM）与现代 NT 内核的设计理念存在根本差异。这种架构差异直接影响了系统调用拦截机制的选择，也是 WSL9x 采用特殊技术方案的根本原因。
GPF 拦截机制的技术细节
Windows 9x 环境中运行 Linux 内核面临的核心技术障碍在于中断描述符表（IDT）的限制。在标准的 Linux x86 系统上，int 0x80 指令作为进入内核的系统调用入口，通过 IDT 中预设的中断处理程序实现用户态到内核态的切换。然而，Windows 9x 的 IDT 长度有限，无法为 int 0x80 安装正确的中断处理程序。这一硬件层面的限制促使开发者探索替代方案。
WSL9x 采用了 GPF（General Protection Fault）处理器来实现系统调用拦截的方案。当 Linux 内核执行 int 0x80 指令时，由于 IDT 中没有对应的有效处理程序，CPU 会触发一般保护错误而非正常执行系统调用。VxD 驱动程序通过注册 GPF 处理器来捕获这一事件，其工作流程包含以下关键步骤：首先，GPF 处理器监控导致错误的指令；当识别到 int 0x80 指令时，处理器模拟中断成功的效果，将指令指针推进到下一条指令；随后，系统调用参数被提取并分发到 Linux 内核的相关处理函数。
这种基于异常拦截的实现方式虽然巧妙，但带来了显著的性能开销。每次系统调用都需要经历完整的异常处理流程，而非直接的中断分发。此外，GPF 处理器的实现需要精确的指令识别逻辑，以区分真正的系统调用和其他可能触发 GPF 的指令。开发者 Hailey 在项目中详细记录了这一权衡：选择 GPF 拦截是因为 Windows 9x 架构的客观限制，而非技术最优方案。
工程实现的权衡与风险
WSL9x 的运行模式具有独特的风险特征：Linux 内核与 Windows 9x 内核共享相同的 CPU ring 0 特权级别，两者以协作方式运行而非抢占式隔离。在现代操作系统中，不同特权级别的代码通常通过硬件隔离实现安全边界，但 WSL9x 中这种设计意味着任何一个内核的崩溃都可能导致整个系统重启。Hailey 本人在 Hacker News 讨论中明确指出：「它们应该协作运行，但如果任意一方崩溃，双方都会宕机。」
从系统设计的角度看，WSL9x 展示了一种在极端受限环境下实现操作系统兼容性的可能路径。其核心贡献在于证明了即使面对 IDT 限制、缺乏现代内存管理功能等重大障碍，仍可通过创造性利用现有硬件机制实现目标。这种技术思路对于嵌入式系统兼容层、老旧系统模拟等场景具有参考价值。
值得注意的是，WSL9x 目前仅提供命令行界面支持，这反映了在 Windows 9x 图形环境上运行完整 Linux 子系统的额外复杂性。DOS 客户端组件负责将 DOS 提示符传递给 Linux 内核作为 TTY 设备，这一简化方案在保持功能的同时避免了图形栈的兼容性问题。
资料来源：The Register 2026 年 4 月 22 日报道、Codeberg 项目文档