深入研究 Windows WOW64
兼容层的原理与应用

WOW64 的历史沿革与设计目标

WOW64 的设计初衷在于兼容与平滑过渡。面对海量的32位软件生态，完全要求用户迁移到64位版本并不现实，因而需要一种机制承载旧有应用。WOW64 通过在64位 Windows 上提供一个32位的接口层，承担起翻译32位应用调用、隔离运行环境差异的职责，使32位应用"误认为"自己仍运行在32位系统上。

总的来说，WOW64 的历史演进体现了 Windows 对向后兼容的高度重视。其设计目标始终围绕着让32位应用"零修改"运行在新平台上，同时充分利用新硬件能力保证性能不至于大幅退化。

注册表访问的重定向与反射机制

WOW64 的"注册表重定向器"负责将32位应用对某些注册表节点的访问自动指向一个平行的32位视图下。具体而言，Windows 在注册表中引入了 HKLM\Software\Wow6432Node 分支，作为32位应用看到的 HKLM\Software 的映射。

// 当32位应用尝试访问：
HKEY_LOCAL_MACHINE\Software\SomeKey

// WOW64 会将请求重定向到：
HKEY_LOCAL_MACHINE\Software\Wow6432Node\SomeKey

对于应用来说，并不知道这个重定向的存在，它仍以为访问的是正常的路径，但实际数据被隔离存储在Wow6432Node子树中。这种机制保证了32位应用读取/修改注册表不会影响64位应用的配置，双方各有各的"视图"。

需要注意的是，并非注册表的所有部分都实施了重定向，Windows 针对哪些键需重定向、哪些键对齐共享做了策略区分。例如，一些与系统密切相关的键或用于跨位交互的键可能标记为共享，从而不做隔离。

对于开发人员而言，一般无需关心WOW64的注册表重定向发生了什么，因为这一过程对应用是透明的。但在特定情况下，可能需要访问另一视图的注册表数据。Windows 提供了特定的注册表访问标志（如 KEY_WOW64_64KEY 和 KEY_WOW64_32KEY）允许一个应用显式指定访问64位或32位视图的键值。

文件系统访问管理与路径重定向

类似于注册表，文件系统方面WOW64也采取了路径重定向策略，以保证32位应用访问系统目录时得到正确的文件。最典型的例子就是 System32 目录的重定向。

在64位Windows中，%SystemRoot%\System32 实际上存放的是64位版本的系统DLL和可执行文件。然而，历史上许多应用默认认为 System32 下是系统组件所在位置，并直接构建该路径访问。例如，一个32位应用调用系统API尝试加载 C:\Windows\System32\kernel32.dll。如果不加干预，它将会错误地加载到64位的kernel32，从而无法运行。

因此，WOW64 针对系统目录引入了透明的文件系统重定向：当32位应用访问 %Windir%\System32\... 时，操作系统会自动将路径替换为 %Windir%\SysWOW64\...（对32位ARM应用则是 %Windir%\SysArm32\...）。例如，32位应用请求打开 C:\Windows\System32\notepad.exe，实际上被重定向去打开 C:\Windows\SysWOW64\notepad.exe —— 后者是32位版本的记事本程序。

文件系统重定向也有一些特殊情况和例外：

• 某些特殊子目录是豁免的，例如系统的驱动程序存储 (System32\DriverStore)、日志 (System32\logfiles)、驱动配置 (System32\drivers\etc) 等目录，Windows 不对其进行重定向。
• 当某些操作触发UAC（用户帐户控制）的权限提升提示时，如果一个32位应用试图启动系统管理工具，如 regedit.exe，Windows会考虑管理员意图，可能直接运行64位版本而跳过重定向。

在极少数情况下，应用可能需要访问真实的64位系统目录（对于32位进程而言默认被重定向了）。Windows 提供了两种方式：

通过文件系统路径重定向，WOW64 最大程度保障了32位应用对系统文件的访问兼容性。大多数情况下，开发者编写32位应用无需为64位环境特地修改文件路径。但是也要避免硬编码某些路径假设，比如不要假定 System32 下一定是与你进程同位宽的DLL。

内存管理细节：地址空间布局与数据结构差异

WOW64 在内存管理方面也体现出与纯64位或纯32位环境的不同之处。这里包括32位进程在64位系统上的地址空间划分、关键数据结构（PEB/TEB 等）的差异，以及内存地址和句柄在32/64位之间的映射处理等。

在32位 Windows 上，每个进程的虚拟地址空间上限通常为 4GB（其中用户态2GB，内核态2GB；若开启/3GB开关则用户态可达3GB）。而在64位 Windows 上，地址空间理论上极其巨大，但32位应用并不能利用超过4GB的空间，因为它的指针仍是32位的。

对于在WOW64下运行的32位进程，Windows 默认仍给予其最多4GB的用户态地址空间，以保持与32位环境相符。如果该应用未标记为"大地址感知"（LARGEADDRESSAWARE），则操作系统依然按照传统限制其可用地址空间为2GB（其余部分保留不使用），从而模拟32位Windows的典型环境；而如果应用启用了 LARGEADDRESSAWARE 标志，则WOW64 会为其提供完整4GB的用户空间。

具体来说，操作系统为32位应用部分维护了"伪造"的32位 PEB/TEB，以便32位代码可以按照它熟悉的结构(offset和字段大小)来读取信息；同时，系统自身仍有实际的64位 PEB/TEB 用于内核和64位部分管理。实际上，在调试符号中可以看到存在 _PEB32 和 _PEB64 两种结构。两者字段大体相同，但64位版本的指针和大小是8字节，32位的是4字节，因而结构长度和字段偏移也不同。

当WOW64创建一个进程时，会初始化64位 PEB，然后由WOW64层填充出一个对应的32位 PEB供32位代码使用。例如，32位应用调用 Windows API 获取PEB地址（通常通过 FS段寄存器定位）时，得到的是32位PEB的地址。在这块32位PEB中，包含着该进程的32位模块链表、环境变量指针等等（它从64位PEB转换而来，但在地址和格式上伪装成32位）。

同样，每条线程也有一个32位 TEB（由 FS:0x18 引用）和对应的64位 TEB（由 GS:0x30 引用，在x64上）。WOW64利用处理器段寄存器的切换来让不同模式下的代码各自指向正确的TEB。

WOW64 在用户态实现了一系列"thunk"（桩函数）来完成这些转换。例如，当32位应用调用 CreateFile，最终会调用到内核的NtCreateFile系统调用。WOW64拦截到这个调用后，读取32位调用栈上的各参数（比如一个结构指针、缓冲区长度等），将其中的指针从32位地址空间翻译为对应的64位指针值，将32位整数扩展为64位长整数。

这种扩展有符号和无符号之分：对于无符号的数或指针，直接零扩展填充高32位；对于有符号的整数，需符号扩展以保持正负号。然后WOW64调用对应的64位NT接口，将扩展后的参数传给内核处理。内核执行后返回结果（例如一个句柄值或状态码）到64位WOW64层，WOW64再将结果缩小或转换回32位格式给应用。

// 32位结构体的指针参数
HANDLE h = CreateFileW(L"C:\\file.txt", ...);

// WOW64内部转换过程
// 1. 捕获32位调用
// 2. 将32位路径指针扩展为64位
// 3. 调用64位版本的NtCreateFile
// 4. 获取64位句柄返回值
// 5. 返回给32位调用方(无需转换，句柄值在低32位范围内)

由于WOW64运行在64位内核上，32位应用实际上可以利用64位内核的某些优势。例如，64位系统的内核对象（如句柄、窗口、GDI对象等）全局容量更大，因此32位应用在WOW64下理论上可以打开更多的把柄而不受32位系统内核限制。

另一方面，WOW64在内存管理上做了多层透明化处理：从地址空间大小的模拟、双份关键结构的维护，到调用参数/返回值的按需扩展或截断，所有这些都保证了32位应用几乎感觉不到自己身处一个64位操作系统中。

应用兼容性支持策略与技术

WOW64不仅在底层实现了重定向和转换，还包含一系列应用层面的兼容性策略，以确保32位应用可以在64位环境中顺畅运行。这部分涵盖API调用的转换机制、DLL 加载的映射规则，以及针对兼容性的特殊措施等。

在传统32位Windows中，应用程序调用 Windows API（例如 Kernel32.dll 中的函数）最终会触发软中断或SYSENTER指令进入内核执行服务。而在64位Windows上，进入内核的指令约定和参数都变了。如果让32位应用直接执行老的进入内核序列，将无法为64位内核识别。

因此，微软对32位系统DLL（特别是 NTDLL.DLL）进行了重新编译，使其中不再使用直接触发内核的指令序列，而是改为调用WOW64提供的用户态入口。

概括来说，Windows 将32位系统调用的路径改造成：32位应用 -> 32位 NTDLL (调用WOW64入口) -> 64位 WOW64 (转换参数) -> 64位 NTDLL (实际syscall) -> 内核。这种纯用户态的截获和转换机制极大地降低了开销和复杂性。

这一点通过几个途径实现：首先，操作系统维护了分别针对32位和64位的系统DLL搜索路径。例如，当一个32位进程调用 LoadLibrary("kernel32.dll") 时，系统会在SysWOW64目录下找到32位的Kernel32.dll加载，而64位Kernel32.dll则在System32目录下，仅对64位进程可见。

此外，Windows 的KnownDlls 机制（管理系统常用DLL的全局映射）也区分了32位和64位版本。在注册表中 HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs 列出64位系统DLL名单，而 KnownDLLs32 键下则列出32位DLL名单。

WOW64进程是个混合体：主要执行单元是32位的，但它本身也加载了一些64位模块（WOW64的一些实现DLL）。Windows 特殊地允许这少数几个64位DLL注入32位进程地址空间。除了这些特例，其他任何64位DLL都不会被加载到32位进程中，反之亦然。

对于开发者而言，如果需要在应用中显式加载不同位宽组件，可以考虑进程外组件 或独立进程桥接。例如，COM 组件可以设计为 Out-of-process（独立于主进程运行），这样32位应用也可与64位COM服务器通信（通过RPC机制），反之亦然。

例如，全局钩子（Windows Hooks）机制要求DLL注入其他进程来执行钩子代码。在WOW64场景下，微软规定32位DLL只能注入32位进程，64位DLL只能注入64位进程，不能跨位注入。因此，当一个32位应用安装了一个全局钩子，例如键盘钩子，系统只会将32位钩子DLL注入到所有32位进程中；对于64位进程，则需要单独有一个64位版本的钩子DLL才能注入。

对于某些涉及进程间通信的场景，也需考虑WOW64。例如，一些应用通过窗口消息或内存映射文件与外部辅助进程通信，如果辅助进程是64位而主应用32位（或相反），通常仍可工作，因为Windows的很多IPC机制本身是位宽无关的（消息队列、管道、socket等都不区分位宽）。但如果涉及结构共享（比如WM_COPYDATA传递结构，或共享内存里放结构），则需要确保结构定义在两种位宽下二进制一致，否则就要分别处理。

WOW64的存在使得大多数32位应用无需修改即可运行在64位系统上，这对于过渡时期的软件生态是至关重要的。然而，从长远看，64位应用才是趋势。如果开发者有机会，仍应将应用升级为原生64位，以充分利用64位系统优势并避免某些WOW64局限（例如上面提到的不能加载32位驱动的问题等）。

WOW64关键系统组件及协同工作

WOW64 的功能由几大关键组件协作完成。它们主要以DLL形式存在于系统中，包括：Wow64.dll、Wow64win.dll、Wow64cpu.dll，另外在非x86_64平台还有其他对应组件。下面我们介绍这些组件的角色，以及它们如何协同实现WOW64的整体功能。

这些组件各司其职，又紧密合作，使WOW64子系统得以有条不紊地运行。当创建一个WOW64进程时，系统首先加载64位的 NTDLL.dll 和上述WOW64相关DLL（wow64.dll, wow64win.dll, wow64cpu.dll 等）进入新进程，并调用WOW64的初始化例程。

Wow64.dll接管控制后，加载32位版本的NTDLL.dll和必要的用户态DLL（Kernel32.dll、User32.dll等）。当32位代码开始执行，它们就绪妥当，可以像往常一样运行。当应用进行系统调用或GUI调用时，WOW64相关DLL发挥作用，在幕后完成转接和沟通：

• Wow64cpu.dll 执行模式切换
• Wow64.dll/Wow64win.dll 提取并转换参数、调用内核
• 内核处理完返回再经由WOW64转换结果回32位世界

需要强调的是，WOW64所有这些组件都运行在用户态，这保证了良好的隔离性和可控性。例如，如果WOW64的转换出现问题，最多导致该进程崩溃，而不会影响内核态的稳定。64位内核本身并不了解也不关心WOW64的存在，只是将32位进程标记为特殊，由用户态的WOW64组件来负责调用转换。

通过以上各组件的紧密协作，WOW64实现在处理器架构演进过程中对老应用程序环境的无缝延续。对于Windows平台的专业开发者而言，理解这些模块及其交互，可以帮助更好地调试跨位宽问题、优化应用兼容性，甚至在必要时利用这些机制（例如通过Wow64DisableFilesystemRedirection等函数）实现特定需求。

x64 平台上32位指令的执行策略

这意味着，当CPU处于兼容模式时，大部分x86指令集可以不加修改地直接在处理器上执行，其速度与在32位处理器上相当。因此，Windows在x64平台的WOW64实现策略就是尽量利用硬件的能力直接执行32位指令，而不做动态翻译。

这一点使x64上的WOW64性能优势明显——微软指出，在x64处理器上运行32位程序的速度与在32位Windows上运行时几乎相同。只有在涉及系统调用切换模式时才会有额外开销，但那相对调用本身的成本而言是很小的开销。

这个过程充分利用了x64处理器的硬件特性：相比软件模拟，硬件切换模式的成本非常低（大致类似一次函数调用跳转），在x86-64机器上执行32位代码被认为是"计算上廉价的"。因此AMD64平台上的WOW64没有采用例如动态二进制翻译（如WINE或虚拟机那样）的方法，完全没有必要。硬件已经提供了近乎原生的支持，我们只需在恰当时机切换模式即可。

具体而言，x64处理器的段寄存器（如CS代码段寄存器）含有决定模式的标志位。当CS寄存器加载一个特殊的选择子（Selector）指向64位代码段描述符时，CPU将跳转到64位长模式执行；反之，跳转到指向32位代码段的选择子则进入兼容模式执行32位代码。

WOW64利用这一机制，在32位代码需要调用64位例程时执行了一次"远跳转"切换段寄存器，从而让CPU切换模式。例如，在Windows的实现中，Wow64cpu.dll 提供了一个名为KiFastSystemCall的例程，其中通过ljmp（远跳转）指令跳转到段选择子0x33，该选择子在GDT（全局描述符表）中对应一个64位代码段。

; 简化的KiFastSystemCall代码示例
mov eax, ServiceNumber   ; 设置系统服务号
mov edx, ArgumentPtr     ; 参数指针
ljmp 0x33:0x7FFE0300     ; 远跳转，切换到64位模式
; 执行后CPU进入64位模式，开始执行64位代码

处理器执行这条指令后，就从兼容模式切换到了64位模式，并在跳转目标地址开始执行64位代码。这就是WOW64进入64位世界的大门。相应地，当需要从64位返回32位时，也有一条对称的远跳转回到32位段选择子的指令。整个切换过程对应用透明，而且非常快速，基本等同于一次普通的函数跳转。

WOW64在进行模式切换时，需要保存和恢复这些CPU状态。例如，当从32位转到64位时，要把32位应用的通用寄存器内容保存下来，以免64位代码执行破坏它们；当处理完再返回32位时，再把保存的32位寄存器值恢复。

微软实现这一点的方式是利用一个结构体 WOW64_CONTEXT，其中能够存储所有32位CPU状态（寄存器、EFLAGS等）。在进入64位WOW64代码时，Wow64cpu.dll中的汇编会把当前32位寄存器值填入WOW64_CONTEXT中做保存，然后建立新的栈和环境用于64位执行。当稍后要切回32位时，再把这些值恢复到寄存器并返回32位模式。

一个典型场景是异常处理：如果32位应用在兼容模式下发生异常（例如访问无效内存），处理器会转到64位内核，随后内核调度回用户态的WOW64异常处理机制。WOW64需要构造一个32位风格的异常信息并调用32位的处理程序。这其中就涉及保存/恢复和转换异常时的CPU上下文，以便32位应用的异常处理函数能获取正确的异常寄存器状态。

这也是为什么在早期很多用户觉得32位程序在64位系统上跑并不比原生版慢多少。然而，需要认识到WOW64并非毫无代价：模式切换以及参数转换还是会增加一些开销。如果应用频繁调用系统API，大量进行内核对象操作，那么WOW64环境下这些调用每次都要多执行额外的指令去转换和切换模式，时间累积起来可能比直接在32位系统上稍慢。

另一方面，WOW64在x64上基本没有功能性的限制，除了前述的不能调用64位插件/驱动等。32位应用甚至可以利用64位系统提供的新指令（如果通过特殊手段执行的话）。

其他架构上的WOW64执行机制

虽然x64平台是当前WOW64的主要战场，但为了完整性，我们也简要回顾WOW64在其他CPU架构（特别是Itanium和ARM64）上的执行机制，因为它们体现了与x64不同的技术取向。

通过比较可以发现，WOW64在x64、ARM64等平台上主要依靠硬件兼容模式（x64对x86，ARM64对ARM32）来运行相应的32位应用，而对于跨架构（x86在ARM64）则不得不采用软件模拟。无论哪种情况，WOW64都提供了统一的接口和行为，把这些底层差异屏蔽在翻译层之下。

对应用而言，无论是在x64还是ARM64上跑，32位应用的接口行为应该是一致的。这体现了WOW64作为抽象层的价值。随着硬件技术的发展，我们也可能看到WOW64进一步演进。例如，如果将来主流CPU架构本身就具备多架构解码能力，WOW64的实现可能会更简单。

然而，从长远看，WOW64终究是一个过渡方案。当64位应用全面普及时，对于某些平台（如Windows服务器核心版、Windows Nano、特定IoT版），WOW64组件可能被完全移除以节省资源。一旦没有32位应用的需求，WOW64的历史使命也就结束了。