Setup loader determining x86 / x64 architecture

[fegorsch]

Hello everyone,


The short version:

We would like to have a setup launcher, which detects the processor bitness and launches the corresponding setup version.
Anyone with experience in this issue, or with best practice proposals on how to do this?


The long version:

I have created an InstallShield setup project, which outputs a x86 and a x64 release. Two different releases are necessary, because our setup installs drivers, and as you all know (or don't) only either the 32 or 64 bit version of DIFx can be loaded by a MSI setup. We want to distribute both setup versions on one disk in a "x86" and a "x64" folder.

So far no problem.

Now the complicated part: on this disk's root a setup loader should determine the processor architecture and start the corresponding "setup.exe" InstallShield bootstrapper in the correct subfolder.

The logic behind this is fairly easy: evaluate the PROCESSOR_ARCHITECTURE and eventually the PROCESSOR_ARCHITEW6432 environment variables and execute either ".\x86\setup.exe" or ".\x64\setup.exe".

Unfortunately the "executing" part is more complicated than I thought. First of all our setup needs to be run as an administrator. Now starting the setup.exe from the setup loader via WinAPI's CreateProcess() function in a small C++ application does not supply a possibility to eventually show a "run as administrator" dialog. At least not without utmost effort.

We also tried to create an InstallScript project, which just calls the MSI LaunchApp() function and then aborts. This also does not seem like a good solution. On the one hand this leads to showing the setup initialisation dialog twice (once for the setup loader, once for the real setup) and on the other hand involves in my eyes pretty dirty tinkering with the InstallShield project, as these don't seem to be made for such "trivial" tasks. Creating a setup.exe, which only runs ten lines of code and then exits, but has several dialogs, empty default components and so on compiled into, sounds very inefficient.

So for anyone who just read the long version: Are there people out there with experience or best practice solutions for this issue?


Thanks in advance for every answer,

Best regards, felix

[MSIYER]

Use a Win32 exe with a manifest with requireAdministrator attribute.
The other options are:
asInvoker
highestAvailable

The manifest is an xml file and can easily be found on the net.
There is a wealth of info related to this on the net. Visual Studio offers various ways of including a manifest into the exe.

Once this is done, on Vista and later, the shield icon appears on the exe.

CreateProcess cannot be used to invoke any exe that needs admin privileges. But if the manifest is included, this can be done.

Without the manifest your only choices are:
ShellExecute() or ShellExecuteEx()

Also, to find if OS is 64-bit you need to use IsWow64Process().

Hope this helps...

[fegorsch]

Thanks for your reply, adding this to the manifest solved our problem.

We stuck to reading the environment variables, to detect the processor architecture, as IsWow64Process() is not available on Windows 2000, which we still want to support.

Although our bootstrapper worked now under Windows Vista and Windows 7 the Program Compatibility Assistant always brought up a "This program might not have been installed correctly" warning after aborting or finishing the setup. This is, because the PCA assumes that every executable containing the word "setup" leaves an entry in the progam list, which our bootstrapper doesn't of course.

To prevent this message for Windows 7 and Vista add to your manifest:

Source: http://stackoverflow.com/questions/1577412/program-compatibility-assistant-thinks-my-app-is-an-installer


Regards, Felix

[MSIYER]

Glad to hear that you solved your problem.

Just a query:

Unfortunately the "executing" part is more complicated than I thought. First of all our setup needs to be run as an administrator. Now starting the setup.exe from the setup loader via WinAPI's CreateProcess() function in a small C++ application does not supply a possibility to eventually show a "run as administrator" dialog. At least not without utmost effort.

You posted the above lines and I thought you did not know about the manifest.

Thanks for your reply, adding this to the manifest solved our problem.

This line shows that you already knew about the manifest but needed the extra parameters for PCA.
In this case my post is inappropriate.