Implications of using Vista 64-bit when writing 32-bit code
I run Vista 64-bit Enterprise (under Bootcamp on my Mac Book Pro), and ran into an interesting side-effect yesterday. At least it was interesting to me. 
I want to store some values in the Windows Registry under the LocalMachine hive (a global setting, to get around a chicken-and-the-egg configuration problem I had). My build target within Visual Studio 2008 was ‘Any CPU’, which means in effect, it creates a 32-bit executable.
The code worked fine - I could both write to and read from the registry.
But when I ran Regedit to go look at the values, I couldn’t find them. I was looking at the right spot — HKEY_LOCAL_MACHINE\SOFTWARE\Oak City Software but my value wasn’t there! I knew the write suceeded because I could read the value back again — it’s just that it wasn’t written where I thought it would go. Walking off to get a refill on Diet Dr. Pepper while a global search in the registry ran, I returned to find that the values had been stored under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Oak City Software
It turns out that when running 32-bit code on a 64-bit OS, Microsoft transparently redirects your registry calls to this special Wow6432 node in the registry.
OK, time for an experiment. I changed the build target from ‘Any CPU’ to ‘x64′, thus creating a 64-bit executable. Running this resulted in my values being written to the place I expected within the registry.
I’m tempted to call this a leaky abstraction, but on the other hand, it is transparent to my code, and any support burden would be internal — I don’t expect my endusers to be spelunking in the registry. But at the same time I’m curious as to why this was done. I suspect that the registry doesn’t store values with as strong a datatyping as we think — someone trying to read a 64-bit value when only 32-bits was actually written might be a problem.
