locked
Information required : WOW64 RRS feed

  • Question

  • What is WOW64? How it helps to run 32-bit applications on 64-bit processor? Where could I get it?

    • Moved by Max Wang_1983 Tuesday, April 26, 2011 6:15 PM forum consolidation (From:Architecture, Tools, and Process for ISVs)
    Tuesday, December 5, 2006 6:27 AM

Answers

  • From http://msdn2.microsoft.com/en-us/library/ms952405.aspx:

    WOW64

    WOW64 is short for Windows-32-on-Windows-64. It provides 32-bit emulation for existing 32-bit applications, enabling most 32-bit applications to run on the 64-bit version of Windows without modification. It is similar to the old WOW32 sub-system, which was responsible for running 16-bit code under the 32-bit version of Windows.

    The hardware itself has a 32-bit compatibility mode, which handles actual execution of IA-32 instructions, but the WOW layer handles things like switching the processor between 32-bit and 64-bit modes and emulating a 32-bit system. For example, there are different registry hives for 32-bit and 64-bit programs. There is also a different system directory for 32-bit binaries. The 64-bit binaries still use the System32 directory, so when a 32-bit application is installed on the system, the WOW layer makes sure to put the 32-bit binaries in a new directory: SysWOW64. It does this by intercepting calls to APIs like GetSystemDirectory and returning the appropriate directory depending on whether the application is running under the WOW or not. The same issue can exist with the registry. Since both 32-bit and 64-bit COM servers can be installed on the system under the same class identifier (CLSID), the WOW layer needs to redirect calls to the registry to the appropriate 32-bit or 64-bit hives. The WOW layer also handles mirroring changes between some areas in the registry, in order to make it easier to support interoperability between 32-bit and 64-bit code.

    WOW64 is important because it allows you to leverage most of your existing 32-bit code when performance and scalability are not a concern. It is a best of both worlds approach. You can port your service to 64-bit and leave your Microsoft Management Console (MMC) configuration snap-in 32-bit. The 64-bit version of Windows includes both 32-bit and 64-bit versions of MMC. When choosing to leave administration tools as 32-bit there may be some issues with inter-process communication, but protocols such as Remote Procedure Call (RPC) should work between 32-bit and 64-bit processes, as long as the interfaces are designed correctly. Another thing to keep in mind about WOW64 is that it is not designed for applications that require high-performance. At the very least, the WOW64 sub-system needs to extend 32-bit arguments to 64-bits, and truncate 64-bit return values to 32-bits. In the worst case, the WOW64 sub-system will need to make a kernel call, involving not only a transition to the kernel, but also a transition from the processor's 32-bit compatibility mode to its native 64-bit mode. Applications won't be able to scale very well when run under WOW64. For those applications that you would like to leave as 32-bit, test them under WOW64. If the performance is not meeting your expectations, you'll need to look at migrating the application to 64-bit.

    WOW64 is implemented in user mode, as a layer between ntdll.dll and the kernel. WOW64 and some of its support DLLs are the only 64-bit DLLs that can be loaded into a 32-bit process. For all other cases, processes are kept pure. The 32-bit processes cannot load 64-bit DLLs, and vise versa.

    For more information about WOW64, see "64-bit Windows Programming - Running 32-bit Applications" in the Microsoft® Platform SDK. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/running_32_bit_applications.asp

     

    Wednesday, December 13, 2006 7:17 PM

All replies

  • From http://msdn2.microsoft.com/en-us/library/ms952405.aspx:

    WOW64

    WOW64 is short for Windows-32-on-Windows-64. It provides 32-bit emulation for existing 32-bit applications, enabling most 32-bit applications to run on the 64-bit version of Windows without modification. It is similar to the old WOW32 sub-system, which was responsible for running 16-bit code under the 32-bit version of Windows.

    The hardware itself has a 32-bit compatibility mode, which handles actual execution of IA-32 instructions, but the WOW layer handles things like switching the processor between 32-bit and 64-bit modes and emulating a 32-bit system. For example, there are different registry hives for 32-bit and 64-bit programs. There is also a different system directory for 32-bit binaries. The 64-bit binaries still use the System32 directory, so when a 32-bit application is installed on the system, the WOW layer makes sure to put the 32-bit binaries in a new directory: SysWOW64. It does this by intercepting calls to APIs like GetSystemDirectory and returning the appropriate directory depending on whether the application is running under the WOW or not. The same issue can exist with the registry. Since both 32-bit and 64-bit COM servers can be installed on the system under the same class identifier (CLSID), the WOW layer needs to redirect calls to the registry to the appropriate 32-bit or 64-bit hives. The WOW layer also handles mirroring changes between some areas in the registry, in order to make it easier to support interoperability between 32-bit and 64-bit code.

    WOW64 is important because it allows you to leverage most of your existing 32-bit code when performance and scalability are not a concern. It is a best of both worlds approach. You can port your service to 64-bit and leave your Microsoft Management Console (MMC) configuration snap-in 32-bit. The 64-bit version of Windows includes both 32-bit and 64-bit versions of MMC. When choosing to leave administration tools as 32-bit there may be some issues with inter-process communication, but protocols such as Remote Procedure Call (RPC) should work between 32-bit and 64-bit processes, as long as the interfaces are designed correctly. Another thing to keep in mind about WOW64 is that it is not designed for applications that require high-performance. At the very least, the WOW64 sub-system needs to extend 32-bit arguments to 64-bits, and truncate 64-bit return values to 32-bits. In the worst case, the WOW64 sub-system will need to make a kernel call, involving not only a transition to the kernel, but also a transition from the processor's 32-bit compatibility mode to its native 64-bit mode. Applications won't be able to scale very well when run under WOW64. For those applications that you would like to leave as 32-bit, test them under WOW64. If the performance is not meeting your expectations, you'll need to look at migrating the application to 64-bit.

    WOW64 is implemented in user mode, as a layer between ntdll.dll and the kernel. WOW64 and some of its support DLLs are the only 64-bit DLLs that can be loaded into a 32-bit process. For all other cases, processes are kept pure. The 32-bit processes cannot load 64-bit DLLs, and vise versa.

    For more information about WOW64, see "64-bit Windows Programming - Running 32-bit Applications" in the Microsoft® Platform SDK. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/running_32_bit_applications.asp

     

    Wednesday, December 13, 2006 7:17 PM
  • I beg to differ with the statement above: "It does this by intercepting calls to APIs like GetSystemDirectory and returning the appropriate directory"

     

    A 32 Bit VB program with: Declare Function GetSystemDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long

     

    Will return "c:\windows\system32" when run on windows 2003 64BIT. 

     

    This is causing major hassles with every single 32-bit program that makes this system call and breaks most installers that put things in the system folder.  32-bit DLL's simply do not appear to be able to be used if they are installed in system32. 

     

    If the GetSystemDirectory call in Kernel32 does not return the right folder how can anyone expect applications to work correctly?????

    Wednesday, September 26, 2007 8:14 PM