< Day Day Up > |
Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permit the execution of 32-bit x86 applications on 64-bit Windows. It is implemented as a set of user-mode Dlls:
The relationship of these Dlls is shown in Figure 3-31. Figure 3-31. Wow64 architectureWow64 Process Address Space LayoutWow64 processes may run with 2 GB or 4 GB of virtual space. If the image header has the large address aware flag set, then the memory manager will reserve the user mode address space above the 4 GB boundary through the end of the user mode boundary. If the image is not marked large address space aware, the memory manager will reserve the user mode address space above 2 GB. (For more information on large address space support, see the section "x86 User Address Space Layouts" in Chapter 7.) System CallsWow64 hooks all the code paths where 32-bit code would transition to the native 64-bit system or when the native system needs to call into 32-bit user mode code. During process creation, the process manager maps into the process address space the native 64-bit Ntdll.dll. When the loader initialization is called, it inspects the image header and if it is 32-bit x86, it loads Wow64.dll. Wow64 then maps in the 32-bit Ntdll.dll (stored in the \Windows\System32\Syswow64 directory). Wow64 then sets up the startup context inside Ntdll, switches the CPU mode to 32-bits, and starts executing the 32-bit loader. From this point onward, execution continues as if the process is running on a native 32-bit system. Special 32-bit versions of Ntdll.dll, User32.dll, and Gdi32.dll are located in the \Windows\System32\Syswow64 folder. These call into Wow64 rather than issuing the native 32-bit system call instruction. Wow64 transitions to native 64-bit mode, captures the parameters associated with the system call (converting 32-bit pointers to 64-bit pointers), and issues the corresponding native 64-bit system call. When the native system call returns, Wow64 converts any output parameters if necessary from 64-bit to 32-bit formats before returning to 32-bit mode. Exception DispatchingWow64 hooks exception dispatching through ntdll's KiUserExceptionDispatcher. Whenever the 64-bit kernel is about to dispatch an exception to a Wow64 process, Wow64 captures the native exception and context record in user mode and then prepares a 32-bit exception and context record and dispatches it the same way the native 32-bit kernel would do. User CallbacksWow64 intercepts all callbacks from the kernel into user mode. Wow64 treats such calls as system calls; however, the data conversion is done in the reverse order: input parameters are converted from 64-bits to 32-bits and output parameters are converted when the callback returns from 32-bit to 64-bit. File System RedirectionTo maintain application compatibility and to reduce the effort of porting applications from Win32 to 64-bit Windows, system directory names were kept the same. Therefore, the \Windows\System32 contains native 64-bit images. Wow64, as it hooks all the system calls, translates all the path-related APIs, and replaces the path name of the \Windows\System32 folder with \Windows\System32\Syswow64. Wow64 also redirects \Windows\System32\Ime to \Windows\System32\IME (x86) to help 32-bit application compatibility on 64-bit systems with Far East languages installed. Also, 32-bit programs are installed in \Program Files (x86), while 64-bit programs go in the normal \Program Files folder. There are a few subdirectories of \Windows\System32 which, for compatibility reasons, are exempted from being redirected such that accesses to them made by 32-bit applications actually access the real one. These directories include:
Finally, Wow64 provides a mechanism to disable the file system redirection built into Wow64 on a per-thread basis using the Wow64EnableWow64FsRedirection function, available on Windows Server 2003 and later. Registry Redirection and ReflectionApplications and components store their configuration data in the registry. Components usually write their configuration data in the registry when they are registered during installation. If the same component is installed and registered both as a 32-bit binary and a 64-bit binary, then the last component being registered will override the registration of the previous component as they both write to the same location in the registry. To help solve this problem transparently without introducing any code changes to 32-bit components, the registry is split into two portions: Native and Wow64. By default, 32-bit components access the 32-bit view, and 64-bit components access the 64-bit view. This provides a safe execution environment for 32-bit and 64-bit components and separates the 32-bit application state from the 64-bit one if it exists. To implement this, Wow64 intercepts all the system calls that open registry keys and re-translates the key path to point it to the Wow64 view of the registry. Wow64 splits the registry at these points:
Under each of these keys, Wow64 creates a key called Wow6432Node. Under this key is stored 32-bit configuration information. All other portions of the registry are shared between 32-bit and 64-bit applications (e.g., HKLM\System). For applications that need to explicitly specify a registry key for a certain view, the following flags on the RegOpenKeyEx and RegCreateKeyEx permit this:
To enable interoperability through 32-bit and 64-bit COM components, Wow64 mirrors certain portions of the registry when updated in one view to the other. It does this by intercepting updates to any of the reflected keys, and mirrors the changes intelligently to the other view of the registry. The list of reflected keys is:
Reflection of HKLM\Software\Classes\CLSID is intelligent; only LocalServer32 CLSIDs are reflected because they run out of process, thus they can be COM-activated by 32-bit or 64-bit applications. However, InProcServer32 CLSIDs are not reflected because 32-bit COM DLLs can't be loaded in a 64-bit process and likewise 64-bit COM DLLs can't be loaded in a 32-bit process. When reflecting a key/value, the registry reflector marks the key so that it understands that it has been created by the reflector. This is to help the deletion case when deleting a key that has been reflected; thus the reflector will be able to tell if it needs to delete the reflected key if it has been written by the reflector. I/O Control RequestsBesides normal read and write operations, applications can communicate with some device drivers through device I/O control functions using the Windows DeviceIoControlFile API. The application may specify an input and/or output buffer along with the call. If the buffer contains pointer-dependent data, and the process sending the control request is a Wow64 process, then the view of the input and/or output structure is different between the 32-bit application and the 64-bit driver, since pointers are 4 bytes for 32-bit applications and 8 bytes for 64-bit applications. In this case, the kernel driver is expected to convert the associated pointer-dependent structures. Drivers can call the IoIs32bitProcess function to detect if an I/O request originated from a Wow64 process or not. 16-bit Installer ApplicationsWow64 doesn't support running 16-bit applications. However, since many application installers are 16-bit programs, Wow64 has special case code to make references to certain well known 16-bit installers work. These installers include:
Whenever a 16-bit process is about to be created using CreateProcess() API, Ntvdm64.dll is loaded and control is transferred to it to inspect whether the 16-bit executable is one of the supported installers. If it is, another CreateProcess is issued to launch a 32-bit version of the installer with the same command line arguments. Printing32-bit printer drivers cannot be used on 64-bit Windows. Print drivers must be ported to native 64-bit versions. However, since printer drivers run in the user mode address space of the requesting process, and since only native 64-bit printer drivers are supported on 64-bit Windows, a special mechanism is needed to support printing from 32-bit processes. This is done by redirecting all printing functions to Splwow64.exe, the Wow64 RPC print server. Since Splwow64 is a 64-bit process, it can load 64-bit printer drivers. RestrictionsWow64 does not support the execution of 16-bit applications (this is supported on 32-bit versions of Windows) or the loading of 32-bit kernel mode device drivers (they must be ported to native 64-bits). Wow64 processes can only load 32-bit DLLs and can't load native 64-bit Dlls. Likewise, native 64-bit processes can't load 32-bit DLLs. In addition to the above, due to page size differences, Wow64 on IA-64 systems does not support the ReadFileScatter, WriteFileGather, GetWriteWatch, or Address Window Extension (AWE) functions. Also, hardware acceleration through DirectX is not available (software emulation is provided for Wow64 processes). |
< Day Day Up > |