![]() |
#1 |
Senior Member
Join Date: Jul 2007
Location: Piccadilly, London
Posts: 132
|
Going from a 32-Bit installer to a 64-Bit installer
Hi Everyone,
I have an installer that installs correctly to 32-Bit machines. I need to be able to install our application onto 64-Bit machines. I have searched the forums regarding this and have found out the following: NSIS is a 32-bit installer. NSIS developers would like to make a 64-bit installer but have no time. Below are issues related to 32-Bit installers and 64-Bit machines. • 32-Bit installers will run on a 64-bit machines (e.g. x86-64) • On a 64-bit machine NSIS will run as a 32-Bit process. • 32-Bit processes can only load 32-Bit DLLs, they cannot load 64-Bit DLLs. • 64-Bit procesess can only load 64-Bit DLLs, they cannot load 32-Bit DLLs. • It’s impossible to call 64-Bit plugins from a 32-Bit installer. • It’s impossible to call 32-Bit plugins from a 64-Bit installer. NSIS notes • To determine the version of the OS and architecture have a look in the following directories: 1. NSIS\Include\WinVer.nsh 2. NSIS\Include\x64.nsh Example using x64.nsh code: There is also a plugin which can be found here: http://nsis.sourceforge.net/GetVersion_(Windows)_plug-in • On Windows 64-bit you have two copies of HKLM\Software. One for 32-bit applications and one for 64-bit applications. You can access both from NSIS using SetRegView. • 64-Bit code: • 32_Bit code: Is there anything that I am missing? Are there any pitfalls that I should look out for. What is good practice from the following: (1) Have 1 script that does the lot (32-Bit & 64Bit) (2) Have 2 scripts one for each. Any further ideas would be appreciated. Thanks guys. Regards Paul |
![]() |
![]() |
![]() |
#2 |
Junior Member
Join Date: Jan 2009
Posts: 23
|
i'd say you have it figured out ok
here's what I've done to have 32/64 bit from a single NSI source: code: within Function .onInit code: I have the 64 bit executables in a different folder so there is a !ifdef WIN64 to copy the right files too. I chose to have separate installers for 32 and 64 bit (albeit controlled by a single NSI) |
![]() |
![]() |
![]() |
#3 |
Member
Join Date: Nov 2001
Location: Seattle, Washington
Posts: 78
|
Just to generalize the model a bit, consider my case: I have a 32 bit app AND a Shell extension that work together. Just running the existing NSIS installer on, say, Vista x64, results in a 32 bit install of the app AND the Shell extension... which is to say that the Shell extension does not *appear* to have installed at all!
In reality, this is just illustrating the fact that the "normal" Windows Explorer-based Shell UI is 64 bit in this environment. So while the installer in fact completed successfully, the Shell extension part was installed only for the 32 bit version of the Shell (yes, it is still there). SO, for cases like this, one needs to build and install BOTH 32 and 64 bit versions of one's Shell extension, even if your actual app is itself still 32 bit... and yes, having the 64 bit Shell extension invoke the 32 bit app works fine, as (at least for me) this will be across a process boundary, so the "mixing" of 32 and 64 bit components is fine. As to how this relates to my [32 bit] NSIS installer, I just need to have "32-on-64" conditional code as illustrated by the OP that will arrange to add the installation of the 64 bit version of my Shell extension when running in a 64 bit environment. Finally, for those who don't think this is all fairly twisted already, consider that if I eventually have a 64 bit version of my APP, it will most likely need to also install both the 32 and 64 bit versions of my Shell extension. ![]() |
![]() |
![]() |
![]() |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|