Fractal Life

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.