64 bit vs 32 bit Installation Support?

[MWieder]

We have an applicaiton that needs to be able to be installed either on a 32 bit or a 64 bit platform. We want to use a single Installshield source for this, but have no issue creating two seperate outputs if that's what is needed.

Is there a tutorial to help us through the process or would someone be kind enough to outline the steps so we can take our current 32-bit only Installshield file and have it produce 1 or 2 outputs that work on both 32 bit and 64 bit systems?

Specifically, I am concerned with Registry keys as we write configuration values to HLMK/SOFTWARE and the 64 bit registry looks different from the 32 bit one.

Thanks in advance for your time.

[Kovalenko]

If someone will need to build setup by required Product Configuration and Release, use IsCmdBld.exe. Sample:

ISCmdBld.exe -p "C:\InstallShield 2009 Projects\My Othello Project\Othello.ism" -r "Othello Beta" -a "Build 245"

[Superfreak3]

So, here's my setup with a few questions...

Features:
Server
ServerX64
Common (This would hold the other 32 bit pieces common to both configurations.)

My plan is to build the Features as outlined with the server features being identical except for architecture, of course.

I will set the Template Summary Property as part of the release configurations to build two distinct .msi's. What would have been cool is if setting this architecture setting would have defaulted INSTALLDIR appropriately also, but I digress.

Now the questions...

1. Should I start my project as 32 bit and just mark the 64 bit components as such? In other words will everything (outside of the 64 bit stuff) be marked as 32bit components or should I change a setting?

2. At runtime, if INSTALLDIR is set to ProgramFiles64Folder during the 64 bit install, by whatever means, where are the 32 bit component files placed--In the same location or do they get dumped to ProgramFilesFolder since they are considered 32 bit components?

Any further information is greatly appreciated!!

[ZygoCorp]

We do this successfully. I have one InstallScript project with 2 defined releases. There is a lot of fancy foot work to do to deal with all of the 6t4bit stuff installshield doesn't handle, but you can usually program around the problems. Use the 64 defined directories; they will be set correctly for either 64 or 32 bit based on the OS this way you only have to code things once and don't have to put checks in all over the place.

The biggest issue we have right is that our code for checking if our application is running when the installer is launched doesn't work on win7, 64...the 'set wmi = CoGetObject(...) ALWAYS fails. I think its because the object commands are based on a 32bit system and we are on a 64 bit system....

I hope there is A LOT MORE 64 bit support coming with the next version. There is so much not handled.

[Superfreak3]

ZygoCorp wrote:
There is a lot of fancy foot work to do to deal with all of the 6t4bit stuff installshield doesn't handle, but you can usually program around the problems.

Can you summarize the 64 bit stuff not handled by IS or are the items to many to mention effectively?

Use the 64 defined directories; they will be set correctly for either 64 or 32 bit based on the OS this way you only have to code things once and don't have to put checks in all over the place.

Are you saying simply set INSTALLDIR via CA based on Architecture? This would be nice if this was done automatically based on the Template Summary Property setting used when configuring the releases.

I can see that it might be a problem to make a blanket change of INSTALLDIR to Program Files or P F (x86) as someone may install our product to any other location. We save INSTALLDIR to the registry and read on upgrade so can I use any text searching functions in IS 2010 on a property set during System Search.

For example if INSTALLDIR><"Program Files"??? I know this is a bit off this topic, sorry about that. I'm thinking I can because this is what the condition looks like if using Release Flags (property created) for conditions.

[Superfreak3]

Oh, another quick question (probably off topic as well)...

Can I run a 32 bit .dll Custom Action when running the 64 bit install package?

-----Had a chance to test this and it works OK running the 32 .dll from the 64-bit .msi.

[Christoph]

I defined a lot of registry searches in the system search pane. Do I need to create for every registry search a 64-BIT counterpart... meaning checking the 'Search the 64-BIT portion of the registry' checkbox?

[Superfreak3]

I'm having a little trouble getting this going (32/64 bit installs from same template).

After build it looks as though the correct features/components are included in build, but I'm tripping up on getting the 64 install to target Program Files as it seems to always go to Program Files (x86).

What I did was add a Set Property custom action to change INSTALLDIR to ProgramFiles64Folder. This action was run from the Next button on the dialog preceeding the Destination Dialog and was conditioned with VersionNT64. When the install runs on 64-bit, the correct location appears in the dialog, but the install files still go to x86. Should I be using a Set Directory custom action instead? If so, what settings should I use?

Are there many more changes I should be making in various, other tables too?

Any information appreciated!

[loralynne]

What I did that works for me was add a Set Directory custom action with the following settings:

Directory Name: INSTALLDIR
Directory Value: [ProgramFiles64Folder]\MyCompany\MyProduct
Execution Scheduling: Execute only once
Install Exec Sequence: After CostFinalize
Install Exec Condition: Not Installed And VersionNT64 And ISReleaseFlags="64bit"

My 64-bit Product Configuration has a release flag called 64bit; hence, the ISReleaseFlags="64bit" in my Install Exec Condition.

With this custom action, my 64-bit installer installs to Program Files for both a UI install and a silent install.

[Superfreak3]

I reread this thread from the beginning and used a Set Directory custom action from the next button of the dialog immediately before the destination dialog to set INSTALLDIR to ProgramFiles64Folder if ISReleaseFlags><"64Bit".

I don't know if setting the directory where I am is ideal, but it seems to work.

[loralynne]

Although that works for a UI install, it doesn't work for a silent install since the UI sequence doesn't get executed during a silent install.

[Superfreak3]

A yes, that's true, but this install cannot be installed silently. It can, I guess, but there is currently no need.

Maybe I should sequence it more appropriately in case someone tries to go the silent route. I guess I'll just sequence the action in both the UI and Execute sequences after CostFinalize.

[dan_galender]

Are these 64-bit components?

[Superfreak3]

The install is set up with a 32 Bit and 64 Bit feature as well as a Common feature containing files common to both previously mentioned features. The Common feature primarily contains 32 bit components, but the 64 Bit feature contains components marked as such.

[Christoph]

Did anyone succeed successfully in building a 64-BIT installer(as described by Dan before) on a 32-BIT operating system?

The build itself succeeds without errors but when I'm running the 64-BIT Installer on a 64-BIT OS, it behaves very strange and generates errors on uncommon places.

When I build the 64-BIT Installer on a 64-BIT OS... it behaves like expected.

Anyone experienced this and if so... what is the explanation behind it??
I expect it would be possible to build a 64-BIT Installer on a 32-BIT OS without problems.

[dan_galender]

Christoph wrote:
Did anyone succeed successfully in building a 64-BIT installer(as described by Dan before) on a 32-BIT operating system?

The build itself succeeds without errors but when I'm running the 64-BIT Installer on a 64-BIT OS, it behaves very strange and generates errors on uncommon places.

When I build the 64-BIT Installer on a 64-BIT OS... it behaves like expected.

Anyone experienced this and if so... what is the explanation behind it??
I expect it would be possible to build a 64-BIT Installer on a 32-BIT OS without problems.

Are you doing COM extraction on 64-bit components? That requires a 64-bit development/build platform.

[Christoph]

No, I don't.

[Christoph]

another thing I saw:

I've modified the template summary to x64;1033 to target X64 platforms.

However, when I run the setup on 64-BIT OS, I see in the process list of the taskmanager setup.exe running as 32-BIT process(setup.exe *32)?!

I would expect running it as 64-BIT Process.

This probably causes all installscript registry function I use in my code to create regkeys under the 'Wow6432Node' or has this another reason?

[MichaelU]

Our bootstrap is 32-bit (better error messages on 32-bit systems, among other things), as is the InstallScript engine. If you want to write to a 64-bit registry key from an InstallScript custom action, you must tweak REGDB_OPTIONS accordingly.

[Christoph]

@MichaelU

Thanks...

I found it out a minute after posting this question.
This works fine indeed.

[ThisIsEd]

So with InstallShield 2011, it's easy to setup 32bit and 64bit product configurations so you can keep it all in one project. However there's no way to override the INSTALLDIR that I can find, so my 64bit installer defaults to c:\Program Files (x86) instead of being able to point it to the 64bit C:\Program Files for just that release.

Any supported InstallShield workarounds that can happen at build time to change INSTALLDIR on a release/Product configuration basis rather than using change directory actions during runtime?

[Superfreak3]

You could have a SetDirectory Custom Action (ISReleaseFlags><"64Bit") that changes INSTALLDIR from [ProgramFilesFolder]... to [ProgramFiles64Folder].

ISReleaseFlags is set and populated with Features included in that build configuration. In the above condition, 64Bit is the name of a feature that is only included in the 64 bit build configuration. When the feature is included, the app installation will target Program Files in the 64 bit file system.