Windows Installers and 32/64 bit

[Rod Widdowson]

Primarily for Scott and anyone else who has suffered with Windows Installers
(you there Rhys?)

The Apache technology we are using to run Jetty as a daemon works quite hard
to be 32/64 independent, that is to say the configuration is always in the
32 bit virtualized registry (HKLM\SOFTWARE\Wow6432Node\...) and it knows how
to look for the correct java dll (java_client.dll for 32 bits and
java_service.dll for 64 bits).

To that end I had hoped that we would end up with but one, 32 bit installer.
This could dynamically sense whether this was x86 and install only the 32
bit executable or x64 (and install both x86 and x64) or even ia64.

This mostly works just great, with a certain amount of expected and
documentable user pain if we install on x64 but have an x86 java installed
(you allow the install to complete, say "sc config shibd_idp
binpath=shibd_idp32.exe" and off you go).

However in testing I discovered a nasty nit - the installer code really,
really wants to help and so if you install using a 32 bit msi and so if you
specify JAVA_HOME as "c:\program files\java\jre8" it helpfully rewrites this
to be "c:\program files (x86)\java\jre8", with the result that at best the
installation fails because it cannot find "%JAVA_HOME%\bin\java.exe" or at
worst it works and you end up using the JVM you didn't mean to.

You can subvert this by setting JAVA_HOME to be the ShortName
(c:\progra~1\java\jre8), or of course installing java to a non virtualized
address, but that’s a nightmare to even try to explain, and of course
doesn't work on Win8 when short names are off by default.  And anyway
shortnames are so 90s.

The only solution that I can see is to actually grow two installers (which I
had wanted to avoid), 32 bit or 64 bit, and you use whichever is appropriate
for your java.  As a minor advantage the usability issue I mentioned above
can be made to go away.

Since both installers are doing exactly the same thing, all component GUIDs
have to be the same, but I'm not sure about the product or upgrade guids.
I'd like to keep them the same, thus allows either installer to upgrade the
other - also since these two cannot co-exist, if they exist then we need to
test for the other.

Thoughts?

R