This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Setup loader determining x86 / x64 architecture
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 26, 2011
09:03 AM
Setup loader determining x86 / x64 architecture
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
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
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 27, 2011
03:03 AM
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...
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...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 01, 2011
08:04 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 02, 2011
03:31 AM
Glad to hear that you solved your problem.
Just a query:
You posted the above lines and I thought you did not know about the manifest.
This line shows that you already knew about the manifest but needed the extra parameters for PCA.
In this case my post is inappropriate.
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.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)