Download wow64.dll About wow64.dll errors. When an application requires wow64.dll, Windows will check the application and system folders for this.dll file.

On 64-bit Windows, 32-bit programs run in an emulation layer. This emulation layer simulates the x86 architecture, virtualizing the CPU, the file system, the registry, the environment variables, the system information functions, all that stuff. If a 32-bit program tries to look at the system, it will see a 32-bit system. For example, if the program calls the GetSystemInfo function to see what processor is running, it will be told that it's running on a 32-bit processor, with a 32-bit address space, in a world with a 32-bit sky and 32-bit birds in the 32-bit trees. And that's the point of the emulation: To keep the 32-bit program happy by simulating a 32-bit execution environment. Is writing an installer in the form of a 32-bit program that detects that it's running on a 64-bit system and wants to copy files (and presumably set registry entries and do other installery things) into the 64-bit directories, but the emulation layer.

The question is 'What is the way of finding the x64 Program Files directory from a 32-bit application?' The answer is 'It is better to work with the system than against it.' If you're a 32-bit program, then you're going to be fighting against the emulator each time you try to interact with the outside world. Instead, just recompile your installer as a 64-bit program. Have the 32-bit installer detect that it's running on a 64-bit system and launch the 64-bit installer instead.

The 64-bit installer will not run in the 32-bit emulation layer, so when it tries to copy a file or update a registry key, it will see the real 64-bit file system and the real 64-bit registry. [quote]If a 32-bit program tries to look at the system, it will see a 32-bit system. For example, if the program calls the GetSystemInfo function to see what processor is running, it will be told that it’s running on a 32-bit processor[/quote] [quote]Have the 32-bit installer detect that it’s running on a 64-bit system and launch the 64-bit installer instead.[/quote] Except the 32-bit installer doesn’t have a way to detect that it’s running on a 64-bit system, because that’s the point of the emulation layer?

What’s the correct way for a 32-bit app on windows to realise that it’s running a on 64-bit system? Dorfl – some games (I’m thinking of Crysis here) have started to include 64-bit binaries to take advantage of some faster floating point calculations.

Also, on 32-bit, you’re stuck with 4.0-x gigs of RAM (where x is probably between 0.5 and 1.0 for a gaming machine), which basically means you get 2x1GB RAM, which means a 32-bit process using all of its virtual memory can’t all fit into RAM at once. Whereas on 64-bit (I have 8 gigs of RAM), not only is your process all in RAM at once, but you get a hefty amount left over for J.Random apps you might have open (IRC, voice comms etc.) plus, more significantly, disk cache.

8 gigs is probably overkill for that (I also use a lot of VMs) but 4 gigs is definately useful. The only downside of 64-bit, in my opinion, is slightly worse driver support. This is nowhere near as bad as it used to be, and it’ll be usb consumer printers and the like that you might have problems with (getting drivers for my USB bluetooth dongle was waaay harder than it should have been). As long as you check your hardware and peripherals for support beforehand, you’re fine •.

Well, apparently the emulator failed to emulate GlobalMemoryStatus, which contrary to the documentation will not clamp its result to 2GB. That causes some interesting behavior on x64 machines with 4 (or 8, or) GB of RAM. Apparently five years and a few billion dollars can’t afford MS a backcompat test machine with 4 GB of RAM. I mean, the amount of stuff this breaks is staggering.

Need for speed underground racers. Any amount of testing would have caught it. For really old stuff not all hope is lost though: Windows 98/95 compatibility mode does clamp it to 256 megs. Nice way of saying 'we almost got it right! Almost' BTW, the real system32 is available as%windir%Sysnative under emulation.

But shh, don’t tell anybody. Consider this a retaliation for not showing the Compatibility Files button under x64 Explorer. SuperKoko: This is the lamest answer. The simple fact is someone was an idiot and I mean a world class idiot when they made the system32 being 64bit and the SysWow64 being 32bit call. Linux does it right /lib – 64bit libs if thats your think /usr/lib – ditto /usr/local/lib – ditto /lib32 – 32bit libs (ia32-libs installed) /usr/lib32 – ditto /usr/local/lib32 – ditto etc, etc, etc It works for me and every other Linux user on the planet and I have no trouble with applications getting confused because ld takes care of all of the magic for me. If your running a 32bit app, the LD_LIBRARY_PATH is set to the correct locations automagically. If your hardcoding your app, your asking for trouble.