Wednesday, August 19, 2009

32-bit applications running under 64-bit Windows do not see the world as it really is

64-bit desktop computing is becoming more common. Major computer vendors like Dell and HP have started to give users the choice of 64-bit OS (read: Windows) in many of their models. Some of you may have already owned a 12gb+ XPS from Dell.

The specific Windows I am talking about here is Windows 7 64-bit, but the behaviors should apply to Vista 64-bit and/or XP 64-bit, as well as those 64-bit variants of Windows Servers.

In those days of Windows 32-bit, we have those Windows API libraries such as user32.dll and gdi32.dll residing in %windir%\System32. It makes perfect sense that one would expect that 64-bit API libraries in 64-bit Windows would live in %windir%\System64.

But in reality, 64-bit API libraries still live in %windir%\System32. One may say: Ok, it's alright to have both 32-bit and 64-bit libraries in the same directories, as the names of 64-bit libraries should be user64.dll, gdi64.dll etc.

But again, in reality, 64-bit API libraries still use the same name -> user32.dll, gdi32.dll etc.

So if 32-bit and 64-bit libraries share the same name, how do they both sit together in the same directory?

The truth:

  1. 64-bit Windows API libraries live in %windir%\System32
  2. 32-bit Windows API libraries live in %windir%\SysWOW64
  3. 64-bit applications directly use 64-bit Windows API libraries in %windir%\System32
  4. 32-bit applications indirectly use 32-bit Windows API libraries in %windir%\SysWOW64

The interesting part is point #4. Well, 32-bit applications cannot see the real %windir%\system32. Whenever a 32-bit application try to access %windir%\system32, the OS will translate the request to %windir%\SysWOW64, which is the place where 32-bit libraries live now.

Need a proof? Let's do an experiement. We need Internet Explorer for this test. I hope you did not remove Internet Explorer 8 yet since Windows 7 indeed allow you to. If you have really removed it, just use any 32-bit applications that can open a file to test.

1. Make sure your Windows is 64-bit. You cannot see this effect in 32-bit Windows.

2. Open Windows Explorer (which is 64-bit), go to your %windir%\system32, create a folder named "Can you see me" inside it.



3. 64-bit Windows come with both 32 and 64-bits of Internet Explorer. I need you to run the 32-bit Internet Explorer now.


4. In Internet Explorer, press Ctrl+O to show the Open dialog. Then click Browse.

5. Now go to your %windir%\system32. Can you see the folder we created in step 2? You can't. Why? Because this 32-bit Internet Explorer is actually viewing %windir%\SysWOW64 instead of the real %windir%\System32.



6. Now run your 64-bit Internet Explorer. Press Ctrl+O. Click Browse. Go to %windir%\system32. Tada! We can see the folder now!


Why in the world did Microsoft do this kind of confusing stuff? For backward compatibility reasons. Many software hardcoded itself to access %windir%\system32. If Microsoft simply created a system64, many software will need to be changed and recompiled (including those from Microsoft). And why are the names still user32.dll, gdi32.dll etc? Same reason, if the DLL name are changed, many source code will need to be changed before recompiling to 64-bit targets. By using the same directory and same naming, you do not need to change much in your software to retarget to 64-bit Windows.

Finally, how do you know whether a running application is 32 or 64-bit? You can use Task Manager to find out. A 32-bit process has a "*32" behind it's name. Those without it are 64-bits.

No comments:

Post a Comment