本文是《深入理解Windows操作系统 (第六版) 》关于64位Windows操心系统有关Wow64部分的读书笔记，因为之前很少有接触到关于Wow64的部分，记录一下。
Wow64是允许在64位Windows上执行32位x86应用程序的软件。它的实现方式是一组用户模式dll，外加一些来自内核的支持，此内核支持是为了创建32位版本的数据结构，例如进程环境块（PEB）和线程环境块（TEB），这些数据结构正常情况下只有64位版本，通过Get/SetThreadContext 来改变Wow64环境下也是由内核实现的，下面是负责Wow64的用户模式DLL：
- Wow64.dll：管理进程和线程的创建，勾住异常分发和Ntoskrnl.exe导出的基本系统调用。它也实现了文件重定向以及注册表重定向。
- Wow64Cpu.dll：位每个正在Wow64内部运行的线程，管理他们的32位的CPU环境，针对从32位到64位或者从64位到32位的CPU模式切换，提供了与处理器体系结构相关的支持。
- Wow64Win.dll：截取了Win32k.sys导出的GUI系统调用
- IA64系统上的IA32Exec.bin和Wow32ia32x.dll：包含了IA-32软件仿真器和它的接口库，因为Itanium处理器不能以原生方式高效地执行x86的32位指令，所以通过这两个额外的组件来实现软件仿真（通过二进制翻译）。
各个组件的依赖关系如图：
Wow64进程地址空间布局
Wow64进程可以在2GB虚拟空间中运行，也可以在4GB虚拟空间中运行。如果映像文件的头部设置了大地址空间感知标志，则内存管理将4GB边界之上至用户模式边界末尾之间保留为用户模式地址空间。如果映像文件没有被标记为大地址空间感知的，则内存管理器将保留2GB之上的用户模式地址空间。
系统调用
Wow64勾住了所有从32位代码转变至原生64位系统的代码路径，也勾住了64位原生系统需要调用至32位用户模式代码的所有路径。在进程创建的过程中，进程管理器（process manager）将原生的64位Ntdll.dll和针对Wow64进程的32位Ntdll.dll映射到进程地址空间中。当加载器的初始化过程被调用时，它调用Wow64.dll内部的Wow64初始化代码。然后Wow64建立起32位Ntdll所要求的启动环境，将CPU模式切换至32位下，并开始执行32位加载器。从这个点开始，执行过程继续执行，就如同该进程运行在原生的32位系统之上。
Ntdll.dll，User32.dll和Gdi32.dll的特殊32位版本位于\Windows\Syswow64文件夹下。它们调用到Wow64.dll中，而不是发出原生的32位系统调用指令。Wow64转变到原生的64位模式下，并捕获到与系统调用有关的参数（将32位指针转化为64位指针），并发出对应的原生64位系统调用。当原生的系统调用返回时，Wow64把任何输出参数，如果有必要的话，在返回至32位模式之前从64位转换成32位格式。
异常分发
Wow64通过Ntdll.dll的KiUserExceptionDispatcher勾住了异常分发过程。无论何时当64位内核将要给一个Wow64进程分发一个异常时，Wow64会捕获住原生的异常以及用户模式下的环境记录（context record），然后准备一个32位异常和环境记录，并且按照原生32位内核所做的那样将他分发出去。
用户APC分发
Wow64通过Ntdll的KiUserApcDispatcher也勾住了用户模式APC的递交过程。无论何时当64位内核将要给一个Wow64进程分发一个用户模式APC时，Wow64把32位APC地址映射到一个更高的64位地址空间范围中。然后64位Ntdll捕获住原生的APC以及用户模式下的环境记录，将它映射到一个32位地址。然后为它准备一个32位用户模式APC和环境记录，并且按照原生32位内核所做的那样将它分发出去。
控制台支持
因为控制台是由Csrss.exe在用户模式下实现的，它只是单个原生二进制可执行文件，所以，32应用程序在64位Windows上执行不能执行控制台I/O。类似于专门有一个特殊的rpcrt4.dll用来将32位RPC适配成64位RPC，Wow64的32位kernel32.dll中有专门的代码来调用到Wow中，以便在与Csrss与Conhost.exe交互过程中对参数进行适配。
用户回调
Wow64截取了所有从内核到用户模式的回调。Wow64将这样的回调也按照系统调用来对待；然而，根据转换规则是按相反的顺序来完成的：输入参数从64位转换为32位，而输出参数则是在该次回调返回时从32位转换至64位。
文件系统重定向
为了维护应用程序的兼容性，已经降低从Win32到64位Windows的应用程序移植代价，系统目录名称仍然保持不变。因此，\Windows\System32文件夹包含了原生的64位映像文件。因为Wow64勾住了所有的系统调用，所以它会解释所有与路径相关的API，将\Windows\System32文件夹的名称替换为\Windows\Syswow64。Wow64也将\Windows\LastGood重定向到\Windows\LastGodd\Syswow64，将\Windows\Regedit.exe重定向到\Windows\syswow64\Regedit.exe。通过使用系统环境变量，%PROGRAMFILE%环境变量对于32位程序被设置为\Program File (x86)，而对于64位应用程序被设置为\Program File文件夹，CommonProgramFiles和ComonProgramFiles(x86)也存在，它们总是指向32位的位置，而ProgramW6432和CommonProgramWP6432则无条件指向64位位置。
注：因为有些特定的32位程序可能真的需要知晓或者能够处理64位映像文件，所以有一个虚拟的目录，\Windows\Sysnative，使得任何从32位程序发出的针对此目录的I/O，都免于被文件重定向。这个目录实际上并不存在，它只是一个允许访问到真正的System32目录的虚拟路径而已，即使运行在Wow64下的程序也不例外。
Windows System32中有一些目录，由于兼容性的原因，这些子目录没有被重定向，所以32位程序访问这些目录的时候实际上访问的是真正的目录。这些目录包括：
- %windir%\system32\drivers\etc
- %windir%\system32\spool
- %windir%\system32\catroot和%windir%system32\catroor2
- %windir%\system32\logfiles
- %windir%\system32\driverstore
注册表的重定向
应用程序和组件程序将它们的配置数据保留在注册表中。组件程序在安装的过程中，当它们被注册的时候，通常将配置数据写到注册表中。如果同样的组件即安装注册了一个32位二进制文件，又安装了一个64位二进制文件，那么，最后被注册的组件将会覆盖掉以前组件的注册，因为他们填写在相同的位置上。
为了以透明的方式解决这个问题，并且无须对32位组件进行任何代码修饰，注册表被分成了两个部分：原生的和Wow64的。在默认情况下，32位组件访问32位视图，64位组件访问64位视图，这为32位和64位组件提供了一个安全的环境，并且将32位应用程序的状态与64位应用程序的状态隔开来。
为了实现这一点，Wow64截取了所有要打开注册表的系统调用，并且重新解释这些注册表键的路径，将它们指向注册表的64位视图。Wow64在以下这些点上分裂注册：
- HKLM\SOFTWARE
- HKEY_CLASSES_ROOT
但是许多子键实际上在32位和64位之间是共享的——也就是说，并不是并非整个键巢都被分裂了。在以上的每个键下面，Wow64创建了一个称为Wow6432Node的键。在该键下面保存的是32位的配置信息。注册表的所有其他部分对于32位程序和64位程序都是共享的（比如：HKLM\SYSTEM）。
还有一个额外的帮助，如果一个32位应用程序向注册表中写入一个以数据“%ProgramFiles%”或者“%commonprogramfiles%”为开头的REG_SZ或者REG_EXPAND_SZ值，那么Wow64将实际的值修改为”%ProgramFiles(x86)”或“commonprogramfiles(x86)”以便符合前面介绍过的文件重定向和布局结构。32位程序必须正确的写这些字符串——其他的数据都被忽略，按普通的方式写入。最后，任何包含”system32”的键被替换为“syswowo64”（针对所有的大小写），也不管大小写标志是否敏感，除非使用了KEY_WOW64_64KEY，以及该键位于“反射键”列表中。
如果应用程序需要显示的指定一个注册表键位于某个特定的视图中，那么，在RegOpenKeyEx,RegCreateKeyEx,RegOPenKeyTransacted,RegCreateKeyTransacted和RegDeleteKeyEx函数中使用以下标志可以做到这一点：
- KEY_WOW64_64KEY —— 从一个32位或者64位程序显示的打开一个64位键，并禁止REG_SZ或者REG_EXPAND_SZ截取转换处理。
- KEY_WOW64_32KEY —— 从一个32位或者64位程序显示的打开一个32位键。
控制请求
除了普通的读和写操作外，应用程序可以利用Windows 的DeviceIoControl API与某些设备驱动程序通过设备I/O控制函数进行通信。应用程序可能会在调用时指定一个输入或输出缓冲区。如果该缓冲区包含了与指针相关的数据，并且发送该控制请求的进程是一个Wow64进程，那么输入或输出结构的视图在32位应用程序和64位驱动程序之前是不相同的。驱动程序可以调用IoIs32bitProcess()函数来检测一个I/O请求是否从一个Wow64进程发出。
可以参考MSDN上的《Supporting 32-Bit I/O in Your 64-BitDriver》。
限制
Wow64不支持16位应用程序的执行（32位Windows支持），也不支持加载32位内核模式的设备驱动程序。Wow64进程只能加载32位dll,不能加载原生的64位dll。类似的，原生的64位进程不能加载32位的DLL。唯一列外的是，在跨越体系结构差异时，能够加载仅包含资源或数据的Dll，这是允许的，因为这些Dll只包含数据，不包含代码。
