Anders
I would like to ask about NSIS and support for 64-bit.
As far as I know NSIS 3.10 can compile 64-bit installer, but there are no so called "stubs". So, it is not finished yet and we can not use it as fully 64bit software (if I understand it well).
I found a project that do this (can compile 64-bit exe installer) and it seems to work fine.
Is it possible to merge both projects? It would be great if official NSIS fully support 64-bit.
I mean, 32 bit is a prehistory... we will be moving to ARM64 soon (yeah, a dream :P)... and we still don't have 64 bit support?
Yes, I know... it need time and someone to code it. But, as there is already working solution, maybe you could use it?
Thanks,
Thank you for your work for NSIS!
-Pawel
NSIS with 64-bit support
9 posts
I think it's been mentioned before, but I think the team would rather have a 32 bit based binary for the tools, and only have stubs and plugins be target specific. The main blocker is the use of a very old compiler that doesn't have 64 bit support.
I would like to start adding code around the distribution side so that scons isn't used to build the installer directly, instead using the release script to compile for each target we support and manually assembling the binary package (ie compiling and installing each target architecture to the same folder, x86 last, and using that to make the .zip and installer), so that when we jump to a newer compiler (VS2005 is my pick), 64 bit stubs and plugins would automatically start working. But this would have to basically stop compiling for win 9x, and I don't think we are quite ready to make that jump yet.
The assembly file used in the system plugin for 64 bit isn't fully implemented, callbacks are missing at the moment. And if I remember correctly, we still haven't confirmed how the target selection will work in the script yet.
I've also experimented with distributing both 32bit and 64bit in my fork (nsisbi), my way is simple but mostly manual (without an installer). Maybe I can do this dist work on my fork first, then try upstreaming it to NSIS.
I would like to start adding code around the distribution side so that scons isn't used to build the installer directly, instead using the release script to compile for each target we support and manually assembling the binary package (ie compiling and installing each target architecture to the same folder, x86 last, and using that to make the .zip and installer), so that when we jump to a newer compiler (VS2005 is my pick), 64 bit stubs and plugins would automatically start working. But this would have to basically stop compiling for win 9x, and I don't think we are quite ready to make that jump yet.
The assembly file used in the system plugin for 64 bit isn't fully implemented, callbacks are missing at the moment. And if I remember correctly, we still haven't confirmed how the target selection will work in the script yet.
I've also experimented with distributing both 32bit and 64bit in my fork (nsisbi), my way is simple but mostly manual (without an installer). Maybe I can do this dist work on my fork first, then try upstreaming it to NSIS.
We don't support both architectures because our scons script does not support building both. I doubt this will ever get fixed. You can however build or grab 64-bit stubs and plug-ins from somewhere and use them with the official 32-bit makensis (assuming the they are the same versions or very close).
Everything works as 64-bit except the system plug-in callbacks. If somebody fixes those we could perhaps drop all 32-bit support and go full 64-bit.
Everything works as 64-bit except the system plug-in callbacks. If somebody fixes those we could perhaps drop all 32-bit support and go full 64-bit.
Let me write here a request to all who have skills and time. Using NSIS 64 (for now, unofficial build, see above) is not enough. Most of NSIS installers use plugins, that extends its functionality. The problem is that most plugins are only 32-bit, and will NOT work in 64-bit NSIS. All of them (at least the most popular) should be ported to 64-bit. This process is very slow, especially for plugins that are very old or not developed any more.
So, maybe this thread will be some start. I am asking you to recompile/adapt to 64-bit the following plugins:
1. Lockedlist by Afrow UK
Homepage: https://nsis.sourceforge.io/LockedList_plug-in
Newest build: https://github.com/DigitalMediaServe...dList/releases
The plugin is designed to detect and close running processes. Very useful plugin. The goal is to make it 64-bit, to detect all 64-bit (AND 32-bit) process in Windows 64.
2. AppAssocReg by Robert Strong
Homepage: https://nsis.sourceforge.io/Applicat...ration_plug-in
This plugin can read / set application association registration for Windows Vista and greater.
3. StdUtils by lordmulder
Homepage: https://github.com/lordmulder/stdutils
The plugin ads many various C Standard Library functions to NSIS and few others. Veru useful. 64-bit version needed!
The plugin offered Pinning Icons to Taskbar/Start Menu - not working now... however, maybe this is possible, as known browsers, like Opera or Firefox can do this automatically...
Who has enough skill and time? Who will take up the challenge?
-Pawel
So, maybe this thread will be some start. I am asking you to recompile/adapt to 64-bit the following plugins:
1. Lockedlist by Afrow UK
Homepage: https://nsis.sourceforge.io/LockedList_plug-in
Newest build: https://github.com/DigitalMediaServe...dList/releases
The plugin is designed to detect and close running processes. Very useful plugin. The goal is to make it 64-bit, to detect all 64-bit (AND 32-bit) process in Windows 64.
2. AppAssocReg by Robert Strong
Homepage: https://nsis.sourceforge.io/Applicat...ration_plug-in
This plugin can read / set application association registration for Windows Vista and greater.
3. StdUtils by lordmulder
Homepage: https://github.com/lordmulder/stdutils
The plugin ads many various C Standard Library functions to NSIS and few others. Veru useful. 64-bit version needed!
The plugin offered Pinning Icons to Taskbar/Start Menu - not working now... however, maybe this is possible, as known browsers, like Opera or Firefox can do this automatically...
Who has enough skill and time? Who will take up the challenge?
-Pawel
Could someone tell me why you (NSIS Developers) can not use for example this fork: https://github.com/negrutiu/nsis
Can you just ask the author to merge it with official NSIS (or atleast base part that allows to compile NSIS 64)?
I am worried that NSIS is still 32-bit, when 64bit is main architecture from long time ago.
Author of this fork made a great work and it works fine!
-Pawel
Can you just ask the author to merge it with official NSIS (or atleast base part that allows to compile NSIS 64)?
I am worried that NSIS is still 32-bit, when 64bit is main architecture from long time ago.
Author of this fork made a great work and it works fine!
-Pawel
We will do at least one more release first.
You can compile official NSIS now as 64-bit if you want, this has worked for years already. However, the System plug-in is missing callbacks in 64-bit mode and that has to be fixed before we can do a real 64-bit release. I doubt this fork you are linking to has implemented it.
I implemented the basic System plug-in 64-bit code 10 years ago and nobody has submitted a patch for the remaining bits in that time...
You can compile official NSIS now as 64-bit if you want, this has worked for years already. However, the System plug-in is missing callbacks in 64-bit mode and that has to be fixed before we can do a real 64-bit release. I doubt this fork you are linking to has implemented it.
I implemented the basic System plug-in 64-bit code 10 years ago and nobody has submitted a patch for the remaining bits in that time...
I would also like to have a talk sometime about how we can do that. After that talk I'll do some experimenting with manually assembling the installer and zip (not using 'scons dist'), the main issue is whether the host OS doing the compiling is 32 bit or 64 bit. Making the host OS 64 bit simplifies the assembly steps. I think making everything 64 bit, but also retaining the ability to make 32 bit installers by using 'Target' or 'TargetCPU' would probably be the best way forward.
I recently made a Windows 95 VM to test my fork on, and it seems to work fine with all-in-one installers up to 4GB (this was using a VS2005 build of my fork). I haven't had any time to do programming, but I do want to help bring NSIS into the present time (64bit based).
I recently made a Windows 95 VM to test my fork on, and it seems to work fine with all-in-one installers up to 4GB (this was using a VS2005 build of my fork). I haven't had any time to do programming, but I do want to help bring NSIS into the present time (64bit based).
OK, I also wanted to use a 64bit NSIS for various reasons, including making installer exes that formerly needed to be split into chunks due to 32bit limitations.
I found and built the fork: https://github.com/negrutiu/nsis as mentioned above.
I needed to fixup the unpacking of files to preserve date-time stamps when unpacking in a difference timezone vs the timezone used to create the installer. I had done a change to 32bit NSIS several times in previous years, but this time I have tried to do the change publicly - see my fork here: https://github.com/daveb49/nsis64
[As a plug for this: I do hope someone merges this little change into other nsis repos as I believe this is the correct behaviour for unpacking files, matching the behaviour of standard zip unpacking].
As noted by Anders, there are system calls that don't work properly in 64bit plugins, but I went through and updated all my installer scripts and to make them work properly I needed to create/update/rebuild some 64bit plugins. I've made those available here: https://github.com/daveb49
I agree with Anders that these system calls should be fixed properly, but pending someone doing that, I have simply avoided them to keep my installers stable. I tripped over with built installer exes crashing until I did that.
For example, I replaced a plugin for getting folder sizes with this: https://github.com/daveb49/getdirsize64 which is measurably much faster than the 32bit method I previously used.
I also added a new function to get free disk space. I found that even after mofiying the system call in https://nsis.sourceforge.io/FreeDiskSpace to the point where it worked correctly in 64bit on most PCs, it was unreliable with some PCs failing intermittently... so I just put the system call inside the new 64bit plugin and that works seamlessly.
I also had to digitally sign all the plugin DLLs because the stubs get unpacked and put in temp folders as DLLs on the client PC, but antivirus software was blocking them sometimes.
I'm happy to share my built 64bit portable NSIS install with all its plugins, all in 64bit of course, if there's a sensible place to put it. [Built in VisStudio 2022 on Win11]. But the main reason for this post is to encourage others to move to 64bit and help the 64bit NSIS community grow. I'm currently using this 64bit NSIS setup for all my installer building, and it seems to work well. I've replaced all my 32bit nsis installer scripts now, without exception.
I found and built the fork: https://github.com/negrutiu/nsis as mentioned above.
I needed to fixup the unpacking of files to preserve date-time stamps when unpacking in a difference timezone vs the timezone used to create the installer. I had done a change to 32bit NSIS several times in previous years, but this time I have tried to do the change publicly - see my fork here: https://github.com/daveb49/nsis64
[As a plug for this: I do hope someone merges this little change into other nsis repos as I believe this is the correct behaviour for unpacking files, matching the behaviour of standard zip unpacking].
As noted by Anders, there are system calls that don't work properly in 64bit plugins, but I went through and updated all my installer scripts and to make them work properly I needed to create/update/rebuild some 64bit plugins. I've made those available here: https://github.com/daveb49
I agree with Anders that these system calls should be fixed properly, but pending someone doing that, I have simply avoided them to keep my installers stable. I tripped over with built installer exes crashing until I did that.
For example, I replaced a plugin for getting folder sizes with this: https://github.com/daveb49/getdirsize64 which is measurably much faster than the 32bit method I previously used.
I also added a new function to get free disk space. I found that even after mofiying the system call in https://nsis.sourceforge.io/FreeDiskSpace to the point where it worked correctly in 64bit on most PCs, it was unreliable with some PCs failing intermittently... so I just put the system call inside the new 64bit plugin and that works seamlessly.
I also had to digitally sign all the plugin DLLs because the stubs get unpacked and put in temp folders as DLLs on the client PC, but antivirus software was blocking them sometimes.
I'm happy to share my built 64bit portable NSIS install with all its plugins, all in 64bit of course, if there's a sensible place to put it. [Built in VisStudio 2022 on Win11]. But the main reason for this post is to encourage others to move to 64bit and help the 64bit NSIS community grow. I'm currently using this 64bit NSIS setup for all my installer building, and it seems to work well. I've replaced all my 32bit nsis installer scripts now, without exception.
I must admit that I don't remember if I actually tested the 64-bit part specifically or not, but there are 3 DLLs in the ZIP-file I made for the "DigitalMediaServer" build. It contains both ANSI and Unicode 32-bit DLLs plus a Unicode 64-bit DLL. I'm not a C++ developer, so it's always somewhat of a struggle to do anything with these plugins, but the intention, at least, is that it should support 64-bit already.Originally Posted by Pawel View Post1. Lockedlist by Afrow UK
Homepage: https://nsis.sourceforge.io/LockedList_plug-in
Newest build: https://github.com/DigitalMediaServe...dList/releases
The plugin is designed to detect and close running processes. Very useful plugin. The goal is to make it 64-bit, to detect all 64-bit (AND 32-bit) process in Windows 64.