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
- :
- Re: x64 setup builds as a 32-bit executable
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Mar 02, 2010
01:29 PM
x64 setup builds as a 32-bit executable
I'm trying to create a project which builds a 32-bit and a 64-bit setup from the same .ism file. So far, I have:
- an InstallScript MSI project with separate 32 and 64 bit components. The 64-bit components are marked as 64-bit, their condition is set to "VersionNT64" (and the corresponding 32-bit components have the condition "Not VersionNT64"). Every component has a different GUID.
- two features in the project, the 32-bit and the 64-bit, both with different Release Flags.
- two releases, one with "Intel;0" and the other one with "x64;0" in the Template Summary. Both specify the appropriate Release Flag for the feature to include.
- a custom action, first in all sequences which sets INSTALLDIR to ProgramFiles64Folder on the condition "VersionNT64".
The outcome of this is, it builds both 32 and 64 bit setups, however the 64 bit setup is a 32-bit application (it is able to run on a 32-bit OS, only to fail later because of the x64 components it carries).
What am I missing to create a 64-bit native setup.exe? Do I have to build it on a 64-bit OS?
Thanks in advance for any advice.
- an InstallScript MSI project with separate 32 and 64 bit components. The 64-bit components are marked as 64-bit, their condition is set to "VersionNT64" (and the corresponding 32-bit components have the condition "Not VersionNT64"). Every component has a different GUID.
- two features in the project, the 32-bit and the 64-bit, both with different Release Flags.
- two releases, one with "Intel;0" and the other one with "x64;0" in the Template Summary. Both specify the appropriate Release Flag for the feature to include.
- a custom action, first in all sequences which sets INSTALLDIR to ProgramFiles64Folder on the condition "VersionNT64".
The outcome of this is, it builds both 32 and 64 bit setups, however the 64 bit setup is a 32-bit application (it is able to run on a 32-bit OS, only to fail later because of the x64 components it carries).
What am I missing to create a 64-bit native setup.exe? Do I have to build it on a 64-bit OS?
Thanks in advance for any advice.
(7) Replies
‎Mar 12, 2010
09:59 AM
Hey I read it!
Here's my understanding of it - whether your target system is 32- or 64-bit, the installer itself is going to be a 32-bit application.
That's what I see and it works fine so I guess that's what it's supposed to do.
It was a little tricky to access the 64-bit part of the registry from a 32-bit installer using VBScript though...
Here's my understanding of it - whether your target system is 32- or 64-bit, the installer itself is going to be a 32-bit application.
That's what I see and it works fine so I guess that's what it's supposed to do.
It was a little tricky to access the 64-bit part of the registry from a 32-bit installer using VBScript though...
‎Mar 12, 2010
03:18 PM
SirAthos wrote:
The outcome of this is, it builds both 32 and 64 bit setups, however the 64 bit setup is a 32-bit application (it is able to run on a 32-bit OS, only to fail later because of the x64 components it carries).
What am I missing to create a 64-bit native setup.exe? Do I have to build it on a 64-bit OS?
Thanks in advance for any advice.
How does it fail, specifically? I do a similar thing in my builds, but I manually modify the summary information.
-Pete
‎Mar 15, 2010
09:03 AM
It is my understanding that you can't have a project that supports both 64-bit and 32-bit releases. I was in a similar situation to you a couple of months ago and what I had to do is have 2 seperate projects (one for 64-bit and the other for 32-bit).
I did this as all of the components need to be marked as 64-bit components for pure 64-bit support, even though the setup.exe wrapper runs as 32-bit. If you don't run as pure 64-bit you don't have access to the 64-bit areas (program files and registry).
I hope that I am wrong, as at the moment I have a script that converts my 32-bit project into a 64-bit project as to reduce the amount of work needed to maintain my projects
I did this as all of the components need to be marked as 64-bit components for pure 64-bit support, even though the setup.exe wrapper runs as 32-bit. If you don't run as pure 64-bit you don't have access to the 64-bit areas (program files and registry).
I hope that I am wrong, as at the moment I have a script that converts my 32-bit project into a 64-bit project as to reduce the amount of work needed to maintain my projects
‎Mar 16, 2010
12:59 PM
Ray_Portrait wrote:
It is my understanding that you can't have a project that supports both 64-bit and 32-bit releases. I was in a similar situation to you a couple of months ago and what I had to do is have 2 seperate projects (one for 64-bit and the other for 32-bit).
You can have a single project that will support both 32-bit and 64-bit releases. You simply use release flags to deliver the appropriate features (32-bit or 64-bit) for the target platform. If you create seperate releases, you can easily do this from a single InstallShield project.
Creating seperate projects works as well, but then you have the added complexities of ensuring that all of your custom actions, dialogs etc. are synched between both projects. To me that is too much of a headache.
-Pete
‎Mar 17, 2010
05:45 AM
For a release to be fully 64 bit don't ALL of your components in that release need to be marked as 64-bit components? If so, does this mean that you will have a duplication of components that are shared between the 32- and 64- bit releases as a 32-bit release cannot have any 64-bit components? This could make a single project extremely large.
‎Mar 17, 2010
05:18 PM
Thanks for the answers! I had given up (most of the) hope to receive any...
That was the main question I had. From reading other posts and the documentation, I was under the impression that 64-bit installers are built as 64-bit applications (which can't even be started on a 32-bit OS) - otherwise, you would run into problems such as Wow64 and registry redirection.
For now though, it seems that InstallShield is able to deal with 64 bit installations from within a 32-bit application just fine.
I used a custom script action calling Disable(WOW64FSREDIRECTION) - after that, no problems.
Well, since it's a 32-bit app, it is able to start in a 32-bit OS, but after it does its internal checks it realizes that it contains 64-bit components and fails with a message saying something along the lines of "this installer is not compatible with your OS".
You are generally able to create a single project which compiles into two different setups (targeting 32-bit and 64-bit OS). I got stuck trying to include 32-bit and 64-bit drivers in the same project. That fails because InstallShield automatically includes DIFx (the component used to install drivers), but only for one type of OS. If you change the type for one driver, it replaces the DIFx component for the whole project - common therefore to all included drivers.
I'll guess that you could manually force it to include and install both 32-bit and 64-bit versions of DIFx, but at that point the research required for it was not an option any more - so I ended up with two projects and the chore of mirroring every change in both places from that point on.
Not all of your components, just the ones which behave differently from their 32-bit counterparts. Yes, some duplication is required, but it's still way better than maintaining separate 32 and 64 bit projects and duplicating everything...
enorris wrote:
Here's my understanding of it - whether your target system is 32- or 64-bit, the installer itself is going to be a 32-bit application.
That was the main question I had. From reading other posts and the documentation, I was under the impression that 64-bit installers are built as 64-bit applications (which can't even be started on a 32-bit OS) - otherwise, you would run into problems such as Wow64 and registry redirection.
For now though, it seems that InstallShield is able to deal with 64 bit installations from within a 32-bit application just fine.
enorris wrote:
It was a little tricky to access the 64-bit part of the registry from a 32-bit installer using VBScript though...
I used a custom script action calling Disable(WOW64FSREDIRECTION) - after that, no problems.
Pete Delgado wrote:
How does it fail, specifically? I do a similar thing in my builds, but I manually modify the summary information.
Well, since it's a 32-bit app, it is able to start in a 32-bit OS, but after it does its internal checks it realizes that it contains 64-bit components and fails with a message saying something along the lines of "this installer is not compatible with your OS".
Ray_Portrait wrote:
It is my understanding that you can't have a project that supports both 64-bit and 32-bit releases. I was in a similar situation to you a couple of months ago and what I had to do is have 2 seperate projects (one for 64-bit and the other for 32-bit).
I did this as all of the components need to be marked as 64-bit components for pure 64-bit support, even though the setup.exe wrapper runs as 32-bit. If you don't run as pure 64-bit you don't have access to the 64-bit areas (program files and registry).
I hope that I am wrong, as at the moment I have a script that converts my 32-bit project into a 64-bit project as to reduce the amount of work needed to maintain my projects
You are generally able to create a single project which compiles into two different setups (targeting 32-bit and 64-bit OS). I got stuck trying to include 32-bit and 64-bit drivers in the same project. That fails because InstallShield automatically includes DIFx (the component used to install drivers), but only for one type of OS. If you change the type for one driver, it replaces the DIFx component for the whole project - common therefore to all included drivers.
I'll guess that you could manually force it to include and install both 32-bit and 64-bit versions of DIFx, but at that point the research required for it was not an option any more - so I ended up with two projects and the chore of mirroring every change in both places from that point on.
Ray_Portrait wrote:
For a release to be fully 64 bit don't ALL of your components in that release need to be marked as 64-bit components? If so, does this mean that you will have a duplication of components that are shared between the 32- and 64- bit releases as a 32-bit release cannot have any 64-bit components? This could make a single project extremely large.
Not all of your components, just the ones which behave differently from their 32-bit counterparts. Yes, some duplication is required, but it's still way better than maintaining separate 32 and 64 bit projects and duplicating everything...
