Partager via

64-Bit Windows Part 11: Windows On Windows 64

  • Article

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

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

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

Comments