Christian Froeschlin wrote:
> In what way? I recently used NSIS at work to build a rather
> huge installer including support for installation of 64-bit
> applications and libraries. This works perfectly fine even if
> the installer runs as a 32-bit process. There are only few
> things to consider, such as using the appropriate version
> of $PROGRAMFILES for your desired result, and the correct
> root key for making changes to the 64-bit branch of the
> registry. There is not even a need to make separate
> installers for 32 and 64 bit, if you can live with
> a bit of overhead for packaging both binaries.

This is a common question, and the fact that it *appears* you can install
programs on Win64 with a 32-bit executable has been an impediment in
getting software engineers to understand the issue. Perhaps they have
updated NSIS to be a 64-bit program now, but certainly last time I looked
into it, it was only 32-bit, and they had no intention of changing.

A 32-bit installer cannot (easily) *properly* install 64-bit programs in
Win64. It cannot, for example, put anything into "Program Files", any
accesses to this are redirected by the OS to "Program Files (x86)".
Here's a summary:

  http://developer.amd.com/pages/316200464.aspx

While there are work-arounds for many of these issues (e.g. disabling the
WOW64 file redirection is possible via an API call), I'd rather go with the
flow than fight the system.

NB I'd like to make it clear that I am not saying that a 64-bit user-mode
program installed by a 32-bit installer won't work. It will. I'm saying
that unless you make special effort, it won't be installed in the standard
location for 64-bit binaries, and there may be other issues that turn up
that are related to the WOW64 layer being applied to the system view of the
installer program but not to the installed program. It really comes back to
what the installed program is designed to expect.

-- Chris

Post a reply to this message