Just a short post to share something I learned the hard way today when moving a FinalBuilder installation from a 32-bit Windows server to a shiny new 64-bit Windows 2008 server on our even shinier new HyperV platform: The 64-bit registry can catch you out.
The registry on 64-bit Windows (as probably everybody but me knows) contains both 32-bit and 64-bit keys. But the 32-bit keys are effectively redirected for keys in the Software branches:
- HKEY_LOCAL_MACHINE\Software
- HKEY_CURRENT_USER\Software
On a 64-bit Windows system if you explore these keys using regedit you will find a sub-key:
- HKEY_LOCAL_MACHINE\Software\Wow6432Node
- HKEY_CURRENT_USER\Software\Wow6432Node
When a 32-bit process access the HKLM\Software or HKCU\Software keys it is in fact accessing the Wow6432Node subkey ! This is of course all for very good reasons.
Why is this important for FinalBuilder and Delphi ?
Well, FinalBuilder detects the presence of a Delphi version on your build machine by the presence of specific keys in the registry for each individual version of Delphi. For Delphi 2006 for example, FinalBuilder is looking for a value called:
- HKEY_LOCAL_MACHINE\Software\Borland\BDS\4.0\RootDir
This key would normally be created when you install Delphi, but FinalBuilder doesn’t require that your Delphi installation be a fully and completely installed instance of Delphi. As long as this RootDir value is present and points to a folder containing the relevant Delphi files (and as long as certain other registry keys are available in the absence of specific configuration in FinalBuilder), this is enough for FinalBuilder to recognise the presence of a particular Delphi version and invoke it’s command line compiler.
Which is great, because this means that “installing” Delphi on our build machine can be achieved by merely checking out the “tools” folder of our SVN repository. This folder includes an image of a Delphi installation (bin, source etc) and a pair of .reg files containing registry keys to be imported.
Except that when those .reg files are imported on a 64-bit version of Windows, having been exported from a 32-bit version, the keys are imported to the wrong place and FinalBuilder (being a 32-bit process) won’t find those imported keys !
This isn’t a problem if you are actually installing Delphi on the machine where FinalBuilder is located because both Delphi and FinalBuilder are 32-bit processes. The Delphi installer will create the necessary keys in the 32-bit tree from the outset.
The solution if – like us – you are not actually installing Delphi is of course very simple once you know what the problem is. We now have 32-bit and 64-bit versions of these .reg files, where the 64-bit version includes the Wow6432Node folder in the key paths.
Or you use the 32bit regedit to import your reg file 😉
Yep, but I imported by simply double-clicking.
It surely would have made sense for Microsoft to include some indicator in an exported .reg file that would indicate that it came from a 64-bit registry so that keys could be re-directed as appropriate when importing (i.e. when that indicator is missing, thus indicating a 32-bit .reg file).
Don’t get me wrong, I prolly would have stumbled into the same trap.
I thought you were importing that reg file along with checking out the Delphi files using some script or finalbuilder because you mentioned the different reg files you came up with. Then you could have used the same reg file just calling 32bit regedit.
Nah – installing a build machine isn’t something we do frequently enough to put effort into automating that process, especially when (we thought) the steps are/should be very simple (even if we had automated things, our automation at that time would have invoked regedit to do any key import, which on 64-bit Windows would still have been the wrong tool to use, as the 32-bit version is regedt32). 🙂
Incidentally, it isn’t even quite as straightforward as we thought. Some keys need to be in the 32-bit registry, others in the 64-bit !! Aaagh!
“which on 64-bit Windows would still have been the wrong tool to use, as the 32-bit version is regedt32”
Nope. The regedit.exe in the Windows\SysWOW64 directory is 32bit 😉 And prolly would have been called from Finalbuilder, because Finalbuilder is 32bit. But on that detail I am not sure.
Ah, I see what you mean, but I wouldn’t have used FinalBuilder to automate installing FinalBuilder. 🙂
But, out of curiosity I tested this out, and if I create a new project with a single “Execute Program” action and configure it to run “regedit.exe”, I do appear to get the 32-bit version.
It is tempting to think that a FinalBuilder script could be used to not only document but automate the setting up of our build machine, but unfortunately one negative aspect of FinalBuilder is that creating scripts is relatively laborious – more so than simply documenting steps which are/should be easily performed by following a handful of simple instructions. We did not know that those instructions would not be “portable” to 64-bit at the time, and whilst automating it would have protected us against that mistake, it would have done so only by accident, not design.
It’s only once those steps reach a certain number, or have complex dependencies or conditional branches, that the effort of creating a FinalBuilder project starts to make sense, imho.
ymmv. 🙂
Also, if you read my follow up post, you will see that it isn’t actually as simple as “import 32-bit keys into the 32-bit registry”. Even an automated process would have failed for us, as it turns out that some keys need to be imported to 32-bit and others to 64-bit !! Aaarrrgh!
Stefan’s solution is 100% the way to go. Use a 32 bit process to do the work and take advantage of the prevailing registry redirector. Always best to let the system use its knowledge rather than duplicating and hard coding the same.
On a bigger scale this applies to installers, COM registration etc. Always should be written with standard registry keys, i.e. no Wow6432Node but then let bitness of process writing those keys invoke the redirector if needed.
@David: Read on McDuff… using 32-bit regedit would have solved only 1/2 the problem – it would have imported the HKLM keys to the 32-bit tree, but it would also have imported the HKCU keys to the 32-bit tree, where [curiously] they don’t work! Some/all of the HKCU keys need for some reason to be in the 64-bit tree, even though both Delphi and FinalBuilder are 32-bit.
This is actually the more intriguing problem, but it highlights that your and Stefan’s “100% right way to go” isn’t – in this case – actually 100% right !!
In fact, far from it. 32-bit regedit wouldn’t be able to import keys into the 64-bit registry AT ALL, so I could only ever get 50% of the job done with that approach!
For an automated solution I would HAVE to use 64-bit regedit and use logic in any script to detect whether FinalBuilder was running on 64bit Windows and import keys into the appropriate 32/64-bit tree.
If 32 bit regedit can’t get it done, that’s because the keys are for 64 bit processes. My guess is that the keys that fail are OS keys, for example environment variables.
Unless you specifically identify the keys in question I can’t say for sure, but my experience installing programs and registering COM servers makes it clear in that one should use the registry redirector wherever feasible.
@David:
Well, if you had read the follow up post you would have seen that the keys in question are:
HKCU\SOFTWARE\Borland\BDS\4.0\Environment Variables
So yes, these are environment variables and on 64-bit the environment is… well, 64-bit. But these are not OS keys afaik – unless there is some Win32 API on Win64 that FinalBuilder or DCC32 is using, which can be used to direct Windows to load environment variables from a 64-bit registry key that would normally be redirected for a 32-bit process.
But in any event, whilst all of that may be relevant to why those keys need to be in the 64-bit tree, it is entirely peripheral to the question of whether using 32-bit regedit to import all keys into the 32-bit tree is a 100% solution to this problem.
The situation is that from a set of keys exported from a 32-bit registry, some of those keys need to be imported into the 32-bit tree of a 64-bit registry and others need to be imported to the 64-bit tree. So suggesting that using 32-bit regedit to import them would be a 100% solution is quite simply wrong.
You need to separate the two issues:
1) What is the right way for an app to use the registry on 64-bit
2) What is needed in the 64-bit registry to make FinalBuilder and Delphi 2006 work
“One should use the registry redirector wherever feasible”
Yes, but in this case it isn’t feasible. 🙂
You are obviously much more expert in this field than me so I’ll comment no more since I’ve clearly got nothing of value to add.
I disagree… it’s just that there are two separate issues in play.
1) the correct way to implement registry access as such things are affected by 32/64-bit’ness.. with the impending release of XE2 and 64-bit support, this is actually going to be an increasingly interesting area I suspect, and it seems you are more expert than I in this area in the general case (this encounter with Windows Server 2008 being my first 64-bit Windows experience). 🙂
2) in the very specific case of directly importing registry keys/values to support Delphi command line compilers in FinalBuilder (both 32-bit apps) when hosted on a 64-bit OS, there appears to be at least one very peculiar wrinkle which wouldn’t appear to be covered by the general rules for “correct” or at least “normal” approaches, requiring what might be best described as a “hybrid” approach.
🙂
Contributions on the first issue will be more than welcome as I am sure I have plenty to learn in that area, as in so many others. But sadly, those rules of thumb/”good behaviour” just don’t work when trying to solve the problem of the 2nd issue.
HKCU\SOFTWARE isn’t redirected. This list of keys that are is here:
http://msdn.microsoft.com/en-us/library/aa384253(v=VS.85).aspx.
So a 32 bit process under the influence of redirector should write to
HKCU\SOFTWARE\Borland\BDS\4.0\Environment Variables
just fine.
One more thought. Regedit may be a interfering by disabling redirection, so you may be better off with a different 32 bit process to import for you.
Well, as I said right at the outset – since what we are talking about is importing keys, it isn’t really worth going all around the houses to automate the process when the required results can be achieved by simply having an appropriately modified .reg file available for use with the already automatic process (just double-click the .reg file). 🙂
I haven’t tested to see whether 32-bit regedit would import to the right places – I suspect now that it would.
You are right, I can find no reference to HKCU\SOFTWARE having 32/64 split personality. What threw me was that I had seen the very vague phrase “some keys” mentioned in Microsoft documents relating to the 32/64-bit redirection, had seen some mention of HKCU\Classes and all that plus the fact that there was already a “Wow3264Node” key in the HKCU\SOFTWARE key in the registry on the machine in question, all conspired to lead me to an incorrect conclusion !
So it seems the two seemingly separate issues were in fact two sides of the same coin. Thanks!! 🙂
As an aside, why do Microsoft insist on making this so hard to figure out? Even in that document you link to, all seems to be clear, concise and complete until right at the last breath they throw in this wonderfully vague footnote:
“Other symbolic links were added in Windows 7 and Windows Server 2008 R2.”
Why can’t they bring themselves to provide a complete list ?
(I know: Because it shouldn’t matter :))
It’s just complex. How would you make it easy to figure out?
Anyway, if you just use the system redirector you don’t have to figure it out. You can continue on in blissful ignorance!!
aha – well it seems a classic case of complexity arising from trying to keep things simple. 🙂
All is well until something – for whatever reason – goes wrong, and then the assumption that people won’t need to know what’s going on and the attendant lack of clear and complete information becomes counter-productive. And yes, I too noticed that the only entry in HKCU\SOFTWARE\WOW3264Node was a Microsoft one… further confirmation (at the time) that this was a living and breathing 32-bit tree within the 64-bit registry and that other apps should follow suit.
Whoops
The HKCU\SOFTWARE\Wow3264Node key on your machine is a fine illusrtration of what goes wrong when you don’t rely on the redirector!!
The irony of it is that, on the machine I’m at now, the only entry in that folder is named Microsoft!