32 bit program on 64 bit OS, the Active setup registry keys

There is a whwole lot of confusion on the 3X2 matrix of hardware, OS, Application runnig on 32 bit and 64 bit OS.
So i clarify the newbies things first and then move on to explain an interesting thing that I 'discovered' about the title of this post.

1. Machine can be X86 or X64. When someone tells you that he bought an x64 machine, hear it as 'i bought a machine with x64 processor'.
2. OS (windows) comes in two forms in terms of architecture. the primary target is an 64 bit windows for x64 machine and a 32 bit windows for x86 machine, but there is a small catch here. A 32 bit windows is installable on x64 machine. No, you wont have any truoble. Nothing at all. You won't ever know that you have an x64 hardware, unless of course you have adebugger hooked to the kernel of then machine and you are exploring the boundary of hardware and software where the hal picks it up.
But this (installing 32 bit OS on x64 machine is just a waste of the power of the machine. I wouldn't be able to allow you the previlege of the x64 architecture)
3. Applications are written seperately for x64 and x86 machine. Visual studio has the default configuration of making the binary architecture independent, but you can change it to x86 or x64 specifically. Now an x86 application will run on both x86 and x64 machine, but an x64 application will run only on x64 machine and not on x86 machine. (By machine here I mean OS. 32 bit OS on x64 machine = 32 bit machine, 64 bit OS on 32 bit mahchine = you are a fool, it doesn't exist).

Now let us move to the topic of the blog here:
Suppose I am writing an application which has both 64 bit and 32 bit versions like Internet Explorer. On a 64 bit OS, it exists as C:\program files\internet explorer\iexplore.exe which launches the 64 bit instance of IE and c:\program files(x86)internet explorer\iexplore.exe which launches the 32 bit version of the internet explorer.
Now, suppose the application contains the set up part.
In the setup part you will have to add some regkeys so that when any new user logs in he gets the personalized settings for that application. You would have noticed that when a new user logs in, a window comes up on top right corner stating something like "personnalising settings" and vanishes very soon.
For 32 bit applications on 32 bit OS these keys are created under the regkey:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup"
For 64 bit applications on 64 bit OS these keys are created under:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup"

But the situation of 32 bit apps on 64 bit OS is little different.
For them all the calls are redirected to 6432 node in registry.
Thus these settings get created in
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Active Setup"

Now on a new user logon on 64 bit OS,
explorer.exe of windows reads the keys under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup" and as per the settings there, the personalization of settings by the application is run.
What about the 6432 node in which the 32 bit apps on 64 bit OS store their active set up?
Well, it never gets read by the OS and is never execute. lo! and behold! That is a bit problem.
Here are three workaround:
1. Login as any user and kill the explorer "taskkill -f -im explorer.exe". Restart the explorer from c:\windows\syswow64\explorer.exe. This is the 32 bit explorer.exe on the system which is always present but by default only the 64 bit explorer.exe at c:\windows\explorer.exe is run.
Since the explorer.exe now running will be 32 bit one, it will read the keys under
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Active Setup" and execute the settings there. But this is not a supported scenario, so cannot be trusted to let other things work well. There will definitely be problems related to control panel applets and file path redirections
2. Register you application in the 64 bit node. This can be done by setting the flag "msidbComponentAttributes64bit" at http://msdn.microsoft.com/en-us/library/aa368007(VS.85).aspx.
This will mark the component as a 64 bit one and you will 'fool' the OS into believing that it is a 64 bit application. But since this is applicable only for the active setup part, apart from small file redirections in the part of your app which deals with active setup, you dont need to be careful anywhere else.
Also settings this flag will create the registry entries at
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup" which is actually the place for 64 bit apps only.

The above explanation is valid only for Win2000/WinXp/Win2003. From Vista and above it is a little different.
in vista, the 64 bit explorer will run both the 32 bit active setup part (wow6432 node) from the registry as well as the 64 bit part. The order will be 32 bit first and 64 bit next.
So if your app has both 64 bit and 32 bit part and both of them register their active setup (like IE), the 64 bit settings will take precedence. So you dont need to change anything in your app if it is 32 bit only or 64 bit only, but if it ships as both of them, better make the things explicit to the customers (and developers).

Here is how the active set up keys actually work:
When a user logs in , the contents of this active setup key is compared against the SAME key in HKCU. If the HKCU key does not exist and/or the "version" value is less than that in HLKM, the appropriate "StubPath" command is run and the key copied to HKCU so it is not run again.



To see how this works for yourself, you can create a key in HKLM…Installed Components and call it "test". Then, add to it a String Value "StubPath" and set it to "notepad". Reboot. See that when you log in, notepad starts. Log in as a different user. See that notepad starts. Log in again with the first ID – notice notepad does not start – as now the "test" key has been copied into the HKCU branch after it ran the first time. Note that version is not necessary.


This way the settings can be personalized for each user login.

Send a mail to sidscrazy@gmail.com in case there is some doubt that you would like to clarify