你看，这并不是什么大问题，毕竟，32位版本的不同Windows操作系统都用来同时运行32位和16位代码。(技术上说，并不是同时运行，相关解释在以后的技巧中会展示给大家)
32位版本的Windows在如何允许32为和16位代码并肩运行方面有着很复杂的机制。然而，这个系统被设计成无论你是系统管理员还是临时用户，你都不需要知道这些机制如何运行。
但是64位版本的Windows就不同了。从一个用户的立场上看，64位应用程序和32位应用程序简单地同时运行，没有什么特殊的。但是对于一个管理员(和帮助桌面用户的人员)来说，这其中就有很大不同了:32位代码与64位代码相隔离。这个隔离是如此重要以至于64位版本的Windows有两个注册表，一个是针对64位，一个是针对32位。
尽管64位版本的Windows XP和Windows Server 2003看起来在操作时候和它们32位的版本几乎同样的，但是在表象之下其实是有很大不同的。如果你在64位版本的Windows下按照32位版本一样来执行某些程序，你可能引起一些麻烦。
DLL 存放到何处?
64位应用程序的第一条规则是:你绝对不能把32位和64位代码混和在同一个应用程序内。如果你有一个64位应用程序，所有与这个应用程序相关的东西，包括DLL文件，必须是64位的。这就有一个有趣的挑战，因为有时候很多应用程序都依靠一个共同的DLL文件。幸运的是，Windows保持32位的DLL文件和64位的DLL文件处于隔离状态。
如果你查看一下在32位操作系统内的\Windows文件夹，你会发现两个子目录:一个名为SYSTEM，还有一个名为SYSTEM32。SYSTEM目录是Windows 3.x遗留下来的，用来保持Windows的对一些旧的应用程序的向下兼容性。一般说来，16位的DLL文件(以及其它的支持文件)被存放在\Windows\System文件夹里，32位DLL文件和不同支持文件被存放在\Windows\System32文件夹里。
32位版本的Windows保持16位和32位DLL文件的方式是非常简单的，但是64位版本的Windows保持64位和32位DLL文件的方式就不这么简单了。
理论上说，微软将要创建一个名为\Windows\System64的文件夹来用其存放64位DLL文件，但是取而代之的是，微软创建了一个新的名为SysWOW64的文件夹来存放32位的DLL文件。第一眼看起来，让人感觉这个文件夹应该存放64位应用程序的，但是注意，32位应用程序本来应该存放它们的DLL文件到\Windows\System32文件夹里面。
\Windows\System32文件夹在64位版本的Windows内仍然存在。但是微软使用这个文件夹做为64位DLL的仓库，而不是32位DLL文件的。我不清楚微软使用\Windows\System32文件夹来存放64位DLL的原因，但是我听说这么做是为了向下兼容性。
那么是不是所有32位应用程序该存放它们的DLL文件到\Windows\System32文件夹呢?这又让事情变得混乱。
如我之前所提及的，32位代码不能默认在64位版本的Windows内运行。为了运行32位的应用程序，Windows使用WOW64 emulator，来让这些应用程序还认为它们在32位版本的Windows内运行。
当你安装一个32位的应用程序，安装向导通过WOW64 emulato运行。32位和64位代码并不混和。一旦一个应用程序(包括一个安装向导)从WOW64 emulator开始运行，它必须接着在WOW64内继续运行。这意味着当你安装一个应用程序，安装向导并不知道这个程序被安装到64位版本的Windows内，并且和它运行在32位操作系统一样把DLL文件写到\Windows\System32文件夹里面。
当然，WOW64知道安装向导通过emulator来运行的32位应用程序。同时也知道64和32位代码不能混合在一起。所以，WOW64 emulator 给\Windows\SysWOW64创建一个别名。这意味着任何时候32位应用程序要写入到\Windows\System32文件夹或者从\Windows\SysWOW64文件夹读取，WOW64 emulator都能使其改道到\Windows\SysWOW64文件夹。
所有这些都意味着如果你需要手动操作\Windows\System32文件夹内的内容，你可能要非常的麻烦。我最近了解到一个管理员需要安装一些小的支持脚本到一个已经安装的应用程序，这个脚本的指导上说明这些脚本需要被存放到\Windows\System32文件夹。当然这些脚本的说明假定这个应用程序是在32位操作系统上运行的。
这些脚本没有引起系统崩溃。然而Windows给人幻想永远不用进行更新。当管理员运行应用程序，它将被改道到\Windows\SysWOW64文件夹。管理员知道他自己把这些脚本放到\Windows\System32文件夹并且能通过Windows浏览器看到这些脚本，但是不能指出为什么应用程序不能看到这些脚本。考虑到这个问题是和权限相关的，他花费了一些时间来研究这个，所以知道了关于64位版本的Windows保存DLL文件隔离的方法，所以他能够把这些脚本放到\Windows\SysWOW64文件夹。
64位版本的Windows对于一个管理员来说，了解底层系统结构非常重要
Applications running under WOW64 can be debugged two ways:
- Use an x86-hosted debugger such as NTSD, WinDbg, or Visual Studio. The 32-bit NTSD is installed to %systemroot%\syswow64 on retail installations. Note that x86 debuggers can be used to debug x86 code, but cannot be used to disassemble or set breakpoints within the WOW64 thunk layer because it is 64-bit native code.
- Use a native debugger such as NTSD or WinDbg and the WOW64 debugger extensions, Wow64exts.dll and W64cpuex.dll. These debugger extensions are installed with the operating system. If the native debugger breaks while the processor is in x86 mode, the debugger presents the process as an x86 process. If the processor is in native mode, the debugger presents the process as native. The !wow64exts.sw command switches the debugger between the two modes.
The registry redirector isolates 32-bit and 64-bit applications by providing separate logical views of certain portions of the registry on WOW64. The registry redirector intercepts 32-bit and 64-bit registry calls to their respective logical registry views and maps them to the corresponding physical registry location. The redirection process is transparent to the application. Therefore, a 32-bit application can access registry data as if it were running on 32-bit Windows even if the data is stored in a different location on 64-bit Windows.
A subset of keys under redirected registry paths are shared. 32-bit registry calls to shared keys are not redirected. Instead, one physical copy of the key is mapped into each logical view of the registry. For a list of redirected keys and shared keys, see Registry Keys Affected by WOW64.
Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: To enable application interoperability through COM and other mechanisms, a subset of redirected registry keys are also reflected. The process of registry reflection copies registry keys and values between two registry views to keep them synchronized. Registry reflection was removed starting with Windows 7 and Windows Server 2008 R2. For more information, see Registry Reflection.
The following scenario illustrates the use of these logical views:
- A 32-bit application checks for the existence of the following registry key: HKEY_LOCAL_MACHINE\Software\Hello. If the key does not exist, the application creates it with a default value of "Hello 32-bit world"; otherwise, it reads and displays the value.
- The same application is modified to write "Hello 64-bit world" instead of "Hello 32-bit world" and recompiled as a 64-bit application.
- When the 32-bit application is run on 64-bit Windows, it displays "Hello 32-bit world". When the 64-bit application is run, it displays "Hello 64-bit world". Both applications call the same registry functions with the same predefined handle and the same key name; the difference is that each application operates on its logical view of registry, and each view is mapped to a separate physical location of the registry, which keeps both versions of the string intact.
Redirected keys are mapped to physical locations under Wow6432Node. For example, HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. However, the physical location of redirected keys should be considered reserved by the system. Applications should not access a key's physical location directly, because this location may change. For more information, see Accessing an Alternate Registry View.
To help 32-bit applications that write REG_SZ or REG_EXPAND_SZ data containing %ProgramFiles% or %commonprogramfiles% to the registry, WOW64 intercepts these write operations and replaces them with "%ProgramFiles(x86)%" and "%commonprogramfiles(x86)%". For example, if the Program Files directory is on the C drive, then "%ProgramFiles(x86)%" expands to "C:\Program Files (x86)". The replacement occurs only if the following conditions are met:
- The string must begin with %ProgramFiles% or %commonprogramfiles%. If the string begins with a space or any character other than %, it is not replaced.
- The case of %ProgramFiles% or %commonprogramfiles% must be exactly as shown because the string comparison is case-sensitive. For example, if the string begins with %CommonProgramFiles% instead of %commonprogramfiles%, it is not replaced.
- The string cannot exceed MAX_PATH*2+15 characters. If it exceeds this length, it is not replaced.
- The key cannot be opened with KEY_WOW64_64KEY. This flag specifies that operations on the key should be performed on the 64-bit registry view, so it is not replaced. For more information, see Accessing an Alternate Registry View.
Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: The KEY_WOW_64_64KEY flag does not affect whether a key is replaced. This flag affects replacement starting with Windows 7 and Windows Server 2008 R2.
In addition, REG_SZ or REG_EXPAND_SZ keys containing system32 are replaced with syswow64. The string must begin with the path pointing to or under %windir%\system32. The string comparison is not case-sensitive. Environment variables are expanded before matching the path, so all of the following paths are replaced: %windir%\system32, %SystemRoot%\system32, and C:\windows\system32.
#include <windows.h>
BOOLEAN bRet = Wow64EnableWow64FsRedirection(FALSE);
if (bRet)
{
// Open the file handle
CreateFile("c:\\windows\\system32\\notepad.exe",
GENERIC_EXECUTE,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
// Enable WOW64 file system redirection.
Wow64EnableWow64FsRedirection(TRUE);
}
Wow64DisableWow64FsRedirectionWow64EnableWow64FsRedirection
Wow64RevertWow64FsRedirection