Wow64

 < 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:

  • Wow64.dll: Manages process and thread creation, hooks exception dispatching and base system calls exported by Ntoskrnl.exe. It also implements file system redirection and registry redirection and reflection.

  • Wow64Cpu.dll: Manages the 32-bit CPU context of each running thread inside Wow64, and provides processor architecture-specific support for switching CPU mode from 32bit to 64-bit and vice versa.

  • Wow64Win.dll: Intercepts the GUI system calls exported by Win32k.sys.

The relationship of these Dlls is shown in Figure 3-31.

Figure 3-31. Wow64 architecture


Wow64 Process Address Space Layout

Wow64 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 Calls

Wow64 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 Dispatching

Wow64 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 Callbacks

Wow64 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 Redirection

To 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:

  • %windir%\system32\drivers\etc

  • %windir%\system32\spool

  • %windir%\system32\catroot2

  • %windir%\system32\logfiles

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 Reflection

Applications 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:

  • HKLM\Software

  • HKEY_CLASSES_ROOT

  • HKEY_CURRENT_USER\Software\Classes

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:

  • KEY_WOW64_64KEY explicitly opens a 64-bit key from either a 32-bit or 64-bit application

  • KEY_WOW64_32KEY explicitly opens a 32-bit key from either a 32-bit or 64-bit application

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:

  • HKEY_LOCAL_MACHINE\Software\Classes

  • HKEY_LOCAL_MACHINE\Software\Ole

  • HKEY_LOCAL_MACHINE\Software\Rpc

  • HKEY_LOCAL_MACHINE\Software\COM3

  • HKEY_LOCAL_MACHINE\Software\EventSystem

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 Requests

Besides 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 Applications

Wow64 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:

  • Microsoft ACME Setup version: 2.6, 3.0, 3.01, and 3.1.

  • InstallShield version 5.x (where x is any minor version number).

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.

Printing

32-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.

Restrictions

Wow64 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 > 


    Microsoft Windows Internals
    Microsoft Windows Internals (4th Edition): Microsoft Windows Server 2003, Windows XP, and Windows 2000
    ISBN: 0735619174
    EAN: 2147483647
    Year: 2004
    Pages: 158

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net