Share via

How does WoW64 work?

  • Article

In one of my previous posts I discussed a little bit about WoW/WoW64 in 64-bit computing. While I was trying to write more about the same, I came across this blog from Craig McMurtry - https://blogs.msdn.com/craigmcmurtry/archive/2004/12/14/301155.aspx. After reading the same, I felt that this post is very comprehensive and there is not much left to be explained (whatever is, is there after the post). So read on …

===========================

We saw that both Itanium and x64 processors have a way of making their differences from 32-bit x86 processors invisible to 32-bit x86 code, although we noted that x64’s do so in a way that is a lot more efficient than Itaniums. However, when the 32-bit x86 code is running on a 64-bit operating system, with 64-bit data structures, how does the operating system hide its differences from a 32-bit x86 operating system away from the 32-bit x86 application?

The answer is that, on a 64-bit operating system, 32-bit applications run on top of an emulation of a 32-bit operating system that is called Windows on Windows 64, or WOW64 for short. WoW64 intercepts system calls to the operating system made by a 32-bit application.

It formulates native 64-bit system calls, converting 32-bit data structures into 64-bit aligned structures.

Then it issues the native 64-bit system call, and translates any output data from the 64-bit system call into 32-bit data structures.

Now, for non-technical folks in the audience, software applications quite typically use the facilities provided by other software components, called libraries, and they usually do so in the most efficient manner possible, which is by having the operating system load libraries into memory, and then accessing the facilities that they need by referring directly to the locations of those facilities in memory. Later, when we talk about developing applications for 64-bit Windows, we are going to emphasize that 32-bit applications cannot directly access the facilities of 64-bit libraries, and vice-versa. So, it would be quite disastrous for a 32-bit application running on a 64-bit operating system to attempt to directly access the facilities of a familiar library if that library were to turn out to be 64-bit. So, for 32-bit applications to work properly on 64-bit operating systems, they need to have 32-bit versions of their libraries available, while 64-bit applications need to have 64-bit versions of their libraries. So, in many cases, 32-bit and 64-bit versions of the same library need to exist side-by-side. Furthermore, if a 32-bit version of an application is installed, it should not overwrite a 64-bit version and vice-versa, so 32-bit and 64-bit versions of applications need to co-exist side-by-side, too.

On 32-bit Windows operating systems, programs are installed by default into a system folder called Program Files, while operating system components and shared libraries are installed into the System32 folder. On a 64-bit Windows operating system, there are separate versions of those folders for 32-bit and 64-bit software components.

So, in addition to the Program Files folder, there is a Program Files (x86) folder for 32-bit applications. Also, in addition to the System32 folder, there is a SysWOW64 folder. Contrary to what the names may suggest, 64-bit operating system components and shared libraries go into the System32 folder, while 32-bit operating system components and shared libraries go into the SysWOW64 folder. (There are no typographical errors in this paragraph: 64-bit entities go into the System32 folder, and 32-bit entities go into the SysWOW64 folder.)

Registry keys specific to 32-bit applications are stored in a branch under HKEY_LOCAL_MACHINE\Software\WOW6432Node.

All of this is done transparently to the application by WOW64, which, in intercepting calls to the operating system, detects references to file paths and registry keys and maps them accordingly.

This system allows 32-bit and 64-bit versions of the same applications to be installed side-by-side on the 64-bit operating system without risk of overwriting one another’s files or inadvertently accessing the wrong versions of the same library.

On the x64 versions of Windows Server 2003, there are both 32-bit and 64-bit versions of Internet Explorer installed by default. Why? Because many sites on the Internet incorporate 32-bit libraries called ActiveX controls, and for Internet Explorer to access those controls, it needs to be 32-bit. If you open up the Task Manager with both version running, and go to the Processes pane, you'll see that 32-bit processes are denoted by *32.

There are some limitations to 64-bit Windows’ support for 32-bit applications.

· You may remember reading here that 64-bit Windows operating systems do not support 16-bit applications? Well, many 32-bit applications have 16-bit installers. Windows detects many 16-bit installers and transparently instantiates an equivalent 32-bit version if one is available. Microsoft is working with vendors of 16-bit installers to obtain compatible 32-bit versions.

· You may also remember reading that 64-bit Windows operating systems require all drivers to be 64-bit. Well, many 32-bit applications depend on 32-bit drivers, and those applications will not run on 64-bit Windows.

===========================

A few points that I wanted to add to the above blog –

· Users often get confused between the 32-bit and the 64-bit subsystems on the 64-bit platform and struggle to find if a particular application is going to work on their 64-bit machines.

Applications are created as 64-bit, 32-bit or agnostic. All the 64-bit and agnostic applications would work on the 64-bit systems. For the 32-bit applications, it however depends if they are WoW64 enabled and tested or not. Applications which state that they would work as WoW on 64-bit platform, would use the x86 emulator. They should work as if they are running on a 32-bit machine. While a normal 32-bit app might not. So there is no default that installing a 32-bit application on the 64-bit platform would work in WoW automatically.

· How do we find if the application is running in the WoW mode or Native mode?

One of the ways in which you can confirm that your applications are running on the native 64-bit and not on a WoW emulation, is to check the size of the IntPtr on the machine. You can use System.IntPtr.get_Size() to find the same. For the native platform, the size would be 8 as compared to 4 on WoW emulation and 32-bit platforms.

Another way is to use the IsWow64Process API. It can help a user detect if the x86 targeted binary (assuming the binary is going to be a x86 binary)

is running in a Wow64 subsystem. You would need to do call this API via a GetProcAddress because it may not be present in some 32 bit OS'es.

· How do we find if the application is supposed to run in the WoW mode or Native mode?

I am discussing this from a managed code context. This can be easily found out from the PE header information of a managed file. To view this header you can use the corflags tool which is shipped as a part of the Visual Studio SDK. To read the details about this, read my blog here. The thumb rule is that binaries which are 32-bit (x86) specific, are the ones that would be executed in WoW64 environment on a 64-bit machine.

More soon!!!

Comments

  • Anonymous
    August 09, 2006
    allz fine with the WOW64 info.

    help me out with this...

    I want to run my web apps (.ASP/IIS) on windows2003 64bit/IIS.
    I use 3rd party DLL's that are 32 bit. how do i use them?

    irkannan@gmail.com

  • Anonymous
    March 14, 2008
    Hi Gaurav. I'm just curious about one issue a customer has been having: when they load my .NET 2.0 app (built for "Any CPU") on 64-bit Vista, the app is crashing with a System.BadImageFormatException at a call to System.Data.SqlServerCe.NativeMethods.DllAddRef(). Doing some research I discovered SqlServerCe must run in WOW64 mode under Vista 64. So, is my suspicion correct that if I build the app rather for x86 specifically, this will force WOW mode on Vista 64 and possibly solve the problem?

  • Anonymous
    June 25, 2008
    Just wanted to say thanks. Even though this post is old by now and these issues are settled, the users still are not. This gave me a lot more insight than a lot of posts and got my system where I needed it to be. Thanks again.

  • Anonymous
    January 10, 2009
    PingBack from http://www.mcseboard.de/windows-forum-allgemein-28/prozessoraustausch-2-145867.html#post896914