8 ms·

NSIS 3.0 ready

73 points by networked 10y ago

deleted 10y ago
[deleted]
anton_gogolev 10y ago
Unrelated, but I keep wondering if there is a viable market for an install system that is generally less fubarred than WiX Toolset, but still compiles down to MSI.
- janpieterz 10y ago
  I quite often think the same. I'd love something similar to Cake [0] but then for installers. Copy file to xyz. Shortcut here. Run this method (CustomActions) only if (conditions) etc. I think the problem might lie in the MSI troubles, where WiX sort off treads in the middle (a bit abstracted, but at the same time you often have to peek into the MSI's and a lot of similar lingo), a C#/other version would abstract maybe a bit too much of something that is quite difficult. [0]: http://cakebuild.net/ http://cakebuild.net/
- taspeotis 10y ago
  There's a free one from Microsoft, or InstallShield LE. https://visualstudiogallery.msdn.microsoft.com/f1cc3f3e-c300-40a7-8797-c509fb8933b9 https://visualstudiogallery.msdn.microsoft.com/f1cc3f3e-c300... http://geekswithblogs.net/TarunArora/archive/2014/04/24/visual-studio-2013-installer-projects-ndash-hello-world-installer.aspx http://geekswithblogs.net/TarunArora/archive/2014/04/24/visu... That said: I use WiX and I find it works adequately.
  - nathanaldensr 10y ago
    WiX gets the job done, but man, does it leak Windows Installer abstractions! You have to understand Windows Installer technology to be effective with WiX. It's definitely not "point-and-click!" http://wixtoolset.org/ http://wixtoolset.org/
    - jasonjei 10y ago
      Even though WiX isnt point and click I'm still impressed how easy it is to add uninstalling of old versions with a few lines of XML
    - taspeotis 10y ago
      > Windows Installer XML Toolset (WiX, pronounced "wicks") > leaks Windows Installer abstractions Okay
- jasonjei 10y ago
  WiX's biggest issue is the lack of documentation. I actually quite like WiX because of some pretty good tooling (like heat to create WiX definitions for files to install, or dark to reverse engineer MSIs). Custom Action DLLs in C++ are pretty straightforward once you learn how to do them. However, I found the documentation to be completely terrible. Changing a default dialog required copying some templates from the source branch. I had to search all over Google (and mailing lists) to add a Custom Action DLL to augment the installer functionality in a WXS file. Overall, I like the text-based format and UNIX-y command tools. However, the lack of good support and documentation is what drives the sharp learning curve. I suspect that the need to produce MSI and desktop software is somewhat becoming a niche.
- nickpp 10y ago
  Advanced Installer has been pretty good at making MSIs for over 10 years now. Easy to use, updated often, lately with AppV and AppX support. Not open source though and the free version is not full-featured.
- flukus 10y ago
  https://chocolatey.org/ https://chocolatey.org/
wslh 10y ago
The most important feature of NSIS 3.0 is adding support for Windows 10. NSIS and Inno Setup are great when you want great control of your installation process instead of following the standard Microsoft Installer (MSI) idiosyncrasies which can give non experts a lot of headaches. It is important to note that NSIS is not transactional like MSIs and is not the official Microsoft supported installation mechanism in [big] organizations.
- ComputerGuru 10y ago
  We've been using NSIS 2.x on and deploying for Windows 10 for a long time now, without any problems. Is there something in particular with regards to Windows 10 compatibility that this release brings to the table?
  - roel_v 10y ago
    How do you deal with installing to user directories? This is what made me move away from nsis. (I mean, running elevated installer to be able to install to ProgramFiles, yet still able to install to UserData). There are some workaround but they're rather horrible, to put it mildly.
    - networked 10y ago
      You can do it with MultiUser.nsh. I've just published an installer script like that: https://github.com/dbohdan/tcl86-nsis-installer/ https://github.com/dbohdan/tcl86-nsis-installer/. With the caveat that my NSIS is rusty, I wouldn't call the result horrible or even particularly ugly relative to the baseline for NSIS scripts.
    - Stratoscope 10y ago
      We may be talking about two different things, but the NSIS installer I wrote for my JKLmouse program installs only into the user profile. It doesn't touch Program Files [(x86]) at all, so it doesn't need elevation: https://github.com/geary/jklmouse/blob/master/AutoHotkey/Source/JKLmouse.nsi https://github.com/geary/jklmouse/blob/master/AutoHotkey/Sou... Or were you saying that your installer runs elevated and installs to Program Files, and also wants to write some files to the user profile? I would think that should just work? Shameless plug: JKLmouse gives you home row mouse control in nearly every Windows app. It's like MouseKeys but doesn't require a numeric keypad, so it works on laptop keyboards. Not too many people know about it; I wrote it for my own use years ago (first in C, then later in AutoHotkey). It is so nice to be able to move the mouse pointer pixel by pixel. http://www.jklmouse.com/ http://www.jklmouse.com/
AdamN 10y ago
Am I the only one who saw sourceforge.net and didn't click because of the fear of going to such a malware-ridden site?
- prplhaz4 10y ago
  A few recent HN discussions have tremendously eased my anxiety of this...thankfully they working on moving things in the right direction. https://news.ycombinator.com/item?id=11092219 https://news.ycombinator.com/item?id=11092219 https://news.ycombinator.com/item?id=11860752 https://news.ycombinator.com/item?id=11860752
- howderek 10y ago
  SourceForge changed owners and doesn't have many of those issues anymore. https://sourceforge.net/blog/sourceforge-now-scans-all-projects-for-malware-and-displays-warnings-on-downloads/ https://sourceforge.net/blog/sourceforge-now-scans-all-proje... http://www.linuxinsider.com/story/83105.html http://www.linuxinsider.com/story/83105.html
  - liareye 10y ago
    Yes and I hear the DNC has changed ownership as well.
- WayneBro 10y ago
  No, you're certainly not the only one. Personally, unless I absolutely need some package or utility, I avoid SourceForge like the plague. In the recent past I even blocked their domain on my network so I did't download things from them on accident. I still don't trust them despite their new ownership because all I have to go by is words. It takes more time and effort than that to win back lost trust. Furthermore, I feel like any project still hosted at SourceForge probably isn't worth looking at. For one, I certainly don't want to interact with SourceForge in order to use or contribute because that would be annoying since the UI/UX for that site is utter crap. Also, the fact that the devs (who host projects at SF) didn't move to newer and better ways speaks volumes to me and I want nothing to do with them.
johnhattan 10y ago
I've had very good luck with NSIS 2.1. It's pretty far from state-of-the-art, but it's really solid if you just need to copy some files and make some start-menu shortcuts. The primary market for one of my products is elderly people, and the fact that I get almost zero setup-related tech support issues from that market tells me a lot. And yeah, my existing installers work just fine with Windows 10, so I assume they just added some Windows 10-specific features.
- JohnTHaller 10y ago
  Heads up that NSIS 2.1 has a major security hole. It will use fake Windows DLLs within the same directory instead of the ones in the Windows and System directories. This wouldn't be that big of a deal except that Google Chrome is completely insecure in terms of downloads and would let any page automatically download EXE files and DLL files to the associated download directory without user interaction. The same download directory your installer would likely run from if you distribute online. Chrome has had the insecure behavior for years. Not sure if it does currently.
  - slrz 10y ago
    Isn't this just using the Windows default library search path, though? How is NSIS supposed to know whether the library to be loaded is malicious or the result of a conscious admin decision (e.g. to circumvent some undesired installer behaviour)? The library search path is admin territory, programs shouldn't override it without a very good reason.
    - user5994461 10y ago
      It's the default search path for libraries which is well documented. (On the top of my head the function is LoadLibrary() on windows, see MSDN.) The thing is, there was a random guy who considered that a security issue and he started posting vulnerability reports and asking for bounties on quite literally EVERY software existing on the planet. e.g. firefox, chrome, internet explorer, nsis, inno setup, and many popular open-source applications (because of course, EVERY software is affected since the 30 years windows and all other OS doing the exact same thing have existed). It was a sort of epic scale hoax. (even though it's factually true that DLL are loaded from the current directory). That will lead to a whole generation of people who will read the reports and be mislead into thinking that this was a major security failure discovery.
joemccall86 10y ago
Just wanted to say congrats. When I used it for another job back in the day it solved some real problems for us. The community forums were immensely helpful as well. I'm glad to see the project is still around and actively developed!
- c0brac0bra 10y ago
  Dittos! I actively use it and it's great to see such a storied project continuing to be supported.
skrebbel 10y ago
To me, NSIS is awesome and ridiculous at the same time. It's very practical and down to earth, and it's definitely miles ahead of anything that existed when NSIS got popular (hello, InstallShield!). But the NSIS scripting language was modelled after Assembly. I mean, what? I really wonder, with delighted amazement, what went on in the heads of the people who decided to model a high level domain specific scripting language after the lowest-level language that's still human editable. I mean, hand-editing LLVM IR is easier. The good part is that assembly is actually good fun to write if you don't need to do large projects in it, and so is NSIS scripting. It sure is documented well enough. Nobody scripts installers fulltime for a living I guess, so it's a nice way to spice up work :-)
- Gracana 10y ago
  Oh man, this is wonderful. From the documentation: "The instructions that NSIS uses for scripting are sort of a cross between PHP and assembly. There are no real high level language constructs but the instructions themselves are (for the most part) high level, and you have handy string capability (i.e. you don't have to worry about concatenating strings, etc). You essentially have 25 registers (20 general purpose, 5 special purpose), and a stack." I like it. Really. It's pretty simple to use the registers and stack, you can use memory (variables) however you like, and all the complex stuff is provided as "commands." It looks like it's pretty easy to create a spaghetti-code mess, but like with BASIC, you can write perfectly maintainable programs if you're inclined to do so.
  - tauchunfall 10y ago
    >I like it. Really. Me, too. I was amazed when I found out, that one can use Pop, Push and Exch [1] to clear registers for the scope of a function and restore the previous registers after leaving the function scope. [1] http://nsis.sourceforge.net/Docs/Chapter4.html#stackinst http://nsis.sourceforge.net/Docs/Chapter4.html#stackinst
  - neko_koneko 10y ago
    > It looks like it's pretty easy to create a spaghetti-code mess Can confirm. I currently work as a malware analyst, and I frequently have to analyze (somewhat) obfuscated malware NSIS installers. Older version of the 7-zip software (v. 9.38) can extract and decompile NSIS installers, but in the newer versions this feature is no longer available, because some people on the 7-zip forums complained that users could unpack their installers and see hidden S/Ns. It's a pity.
justinfrankel 10y ago
Hi there, I created NSIS originally and maintained it through the 1.x series (a mirror of the original web site is here: http://1014.org/code/nullsoft/nsis/ http://1014.org/code/nullsoft/nsis/ ), before Kichik gracefully took over the project. I use NSIS extensively for my own projects. Given some of the comments here I thought I would mention a few things: When NSIS was first created (ca 2000), MSI did not yet exist and installers were big, fragile, and typically had many files. I made a custom installer for Winamp at some point, and then an installer-generator for Winamp plug-ins (PiMP), and later generalized that into NSIS. The script design: originally there was a list of files which would be extracted, shortcuts created, directories created, etc. The list would be processed in order. At some point Vinny from BearShare suggested (via a trivial patch) that we add conditional execution and/or looping. So that's how it ended up as "like assembly", since it was a bunch of instructions being executed. The string formatting was already there, so you don't have to manage strings, so in effect a very high level assembly. The point of writing NSIS installers is that you're really just programming a program, and the language you're using is very good at moving data around. It's not transactional, sure, but ideally if you write an NSIS installer, you can have it look at what's installed and make the correct decisions about upgrading/removing components as necessary. You can also automate the installers for network installs, plenty of system administrators do it now (/S and /D= options, in particular). The mentioned security bug in NSIS 2.1 was fixed in 2.51. Finally: last I checked with LZMA enabled, NSIS installers are very size efficient. If you program them well, they can be very robust. Anyway...
- networked 10y ago
  Thank you for creating NSIS! While we may complain about its assembly-like language, over the years NSIS has proved incredibly useful to countless people, including myself, both as developers and as users. And that goes beyond installers. When I was a university student I got a lot of mileage out of the PortableApps launcher, which was made with NSIS, and used NSIS to develop small, self-contained utilities in a short span of time. For the latter, few things can compare. It is interesting that the declarative vs. imperative configuration divide comes up again and again: in installers, GUI toolkits, configuration management systems, etc. Considering how many times imperative scripting gets reimplemented/hacked on top of a supposedly declarative system, I suspect NSIS made the right choice early on. Things like the PortableApps launcher would not have been possible to make with it otherwise.

73 points by networked 10y ago

deleted 10y ago

[deleted]

Unrelated, but I keep wondering if there is a viable market for an install system that is generally less fubarred than WiX Toolset, but still compiles down to MSI.

janpieterz 10y ago
I quite often think the same. I'd love something similar to Cake [0] but then for installers. Copy file to xyz. Shortcut here. Run this method (CustomActions) only if (conditions) etc. I think the problem might lie in the MSI troubles, where WiX sort off treads in the middle (a bit abstracted, but at the same time you often have to peek into the MSI's and a lot of similar lingo), a C#/other version would abstract maybe a bit too much of something that is quite difficult. [0]: http://cakebuild.net/ http://cakebuild.net/
taspeotis 10y ago
There's a free one from Microsoft, or InstallShield LE. https://visualstudiogallery.msdn.microsoft.com/f1cc3f3e-c300-40a7-8797-c509fb8933b9 https://visualstudiogallery.msdn.microsoft.com/f1cc3f3e-c300... http://geekswithblogs.net/TarunArora/archive/2014/04/24/visual-studio-2013-installer-projects-ndash-hello-world-installer.aspx http://geekswithblogs.net/TarunArora/archive/2014/04/24/visu... That said: I use WiX and I find it works adequately.
- nathanaldensr 10y ago
  WiX gets the job done, but man, does it leak Windows Installer abstractions! You have to understand Windows Installer technology to be effective with WiX. It's definitely not "point-and-click!" http://wixtoolset.org/ http://wixtoolset.org/
  - jasonjei 10y ago
    Even though WiX isnt point and click I'm still impressed how easy it is to add uninstalling of old versions with a few lines of XML
  - taspeotis 10y ago
    > Windows Installer XML Toolset (WiX, pronounced "wicks") > leaks Windows Installer abstractions Okay
jasonjei 10y ago
WiX's biggest issue is the lack of documentation. I actually quite like WiX because of some pretty good tooling (like heat to create WiX definitions for files to install, or dark to reverse engineer MSIs). Custom Action DLLs in C++ are pretty straightforward once you learn how to do them. However, I found the documentation to be completely terrible. Changing a default dialog required copying some templates from the source branch. I had to search all over Google (and mailing lists) to add a Custom Action DLL to augment the installer functionality in a WXS file. Overall, I like the text-based format and UNIX-y command tools. However, the lack of good support and documentation is what drives the sharp learning curve. I suspect that the need to produce MSI and desktop software is somewhat becoming a niche.
nickpp 10y ago
Advanced Installer has been pretty good at making MSIs for over 10 years now. Easy to use, updated often, lately with AppV and AppX support. Not open source though and the free version is not full-featured.
flukus 10y ago
https://chocolatey.org/ https://chocolatey.org/

wslh 10y ago

The most important feature of NSIS 3.0 is adding support for Windows 10. NSIS and Inno Setup are great when you want great control of your installation process instead of following the standard Microsoft Installer (MSI) idiosyncrasies which can give non experts a lot of headaches. It is important to note that NSIS is not transactional like MSIs and is not the official Microsoft supported installation mechanism in [big] organizations.

ComputerGuru 10y ago
We've been using NSIS 2.x on and deploying for Windows 10 for a long time now, without any problems. Is there something in particular with regards to Windows 10 compatibility that this release brings to the table?
- roel_v 10y ago
  How do you deal with installing to user directories? This is what made me move away from nsis. (I mean, running elevated installer to be able to install to ProgramFiles, yet still able to install to UserData). There are some workaround but they're rather horrible, to put it mildly.
  - networked 10y ago
    You can do it with MultiUser.nsh. I've just published an installer script like that: https://github.com/dbohdan/tcl86-nsis-installer/ https://github.com/dbohdan/tcl86-nsis-installer/. With the caveat that my NSIS is rusty, I wouldn't call the result horrible or even particularly ugly relative to the baseline for NSIS scripts.
  - Stratoscope 10y ago
    We may be talking about two different things, but the NSIS installer I wrote for my JKLmouse program installs only into the user profile. It doesn't touch Program Files [(x86]) at all, so it doesn't need elevation: https://github.com/geary/jklmouse/blob/master/AutoHotkey/Source/JKLmouse.nsi https://github.com/geary/jklmouse/blob/master/AutoHotkey/Sou... Or were you saying that your installer runs elevated and installs to Program Files, and also wants to write some files to the user profile? I would think that should just work? Shameless plug: JKLmouse gives you home row mouse control in nearly every Windows app. It's like MouseKeys but doesn't require a numeric keypad, so it works on laptop keyboards. Not too many people know about it; I wrote it for my own use years ago (first in C, then later in AutoHotkey). It is so nice to be able to move the mouse pointer pixel by pixel. http://www.jklmouse.com/ http://www.jklmouse.com/

AdamN 10y ago

Am I the only one who saw sourceforge.net and didn't click because of the fear of going to such a malware-ridden site?

prplhaz4 10y ago
A few recent HN discussions have tremendously eased my anxiety of this...thankfully they working on moving things in the right direction. https://news.ycombinator.com/item?id=11092219 https://news.ycombinator.com/item?id=11092219 https://news.ycombinator.com/item?id=11860752 https://news.ycombinator.com/item?id=11860752
howderek 10y ago
SourceForge changed owners and doesn't have many of those issues anymore. https://sourceforge.net/blog/sourceforge-now-scans-all-projects-for-malware-and-displays-warnings-on-downloads/ https://sourceforge.net/blog/sourceforge-now-scans-all-proje... http://www.linuxinsider.com/story/83105.html http://www.linuxinsider.com/story/83105.html
- liareye 10y ago
  Yes and I hear the DNC has changed ownership as well.
WayneBro 10y ago
No, you're certainly not the only one. Personally, unless I absolutely need some package or utility, I avoid SourceForge like the plague. In the recent past I even blocked their domain on my network so I did't download things from them on accident. I still don't trust them despite their new ownership because all I have to go by is words. It takes more time and effort than that to win back lost trust. Furthermore, I feel like any project still hosted at SourceForge probably isn't worth looking at. For one, I certainly don't want to interact with SourceForge in order to use or contribute because that would be annoying since the UI/UX for that site is utter crap. Also, the fact that the devs (who host projects at SF) didn't move to newer and better ways speaks volumes to me and I want nothing to do with them.

johnhattan 10y ago

I've had very good luck with NSIS 2.1. It's pretty far from state-of-the-art, but it's really solid if you just need to copy some files and make some start-menu shortcuts. The primary market for one of my products is elderly people, and the fact that I get almost zero setup-related tech support issues from that market tells me a lot. And yeah, my existing installers work just fine with Windows 10, so I assume they just added some Windows 10-specific features.

JohnTHaller 10y ago
Heads up that NSIS 2.1 has a major security hole. It will use fake Windows DLLs within the same directory instead of the ones in the Windows and System directories. This wouldn't be that big of a deal except that Google Chrome is completely insecure in terms of downloads and would let any page automatically download EXE files and DLL files to the associated download directory without user interaction. The same download directory your installer would likely run from if you distribute online. Chrome has had the insecure behavior for years. Not sure if it does currently.
- slrz 10y ago
  Isn't this just using the Windows default library search path, though? How is NSIS supposed to know whether the library to be loaded is malicious or the result of a conscious admin decision (e.g. to circumvent some undesired installer behaviour)? The library search path is admin territory, programs shouldn't override it without a very good reason.
  - user5994461 10y ago
    It's the default search path for libraries which is well documented. (On the top of my head the function is LoadLibrary() on windows, see MSDN.) The thing is, there was a random guy who considered that a security issue and he started posting vulnerability reports and asking for bounties on quite literally EVERY software existing on the planet. e.g. firefox, chrome, internet explorer, nsis, inno setup, and many popular open-source applications (because of course, EVERY software is affected since the 30 years windows and all other OS doing the exact same thing have existed). It was a sort of epic scale hoax. (even though it's factually true that DLL are loaded from the current directory). That will lead to a whole generation of people who will read the reports and be mislead into thinking that this was a major security failure discovery.

joemccall86 10y ago

Just wanted to say congrats. When I used it for another job back in the day it solved some real problems for us. The community forums were immensely helpful as well. I'm glad to see the project is still around and actively developed!

c0brac0bra 10y ago
Dittos! I actively use it and it's great to see such a storied project continuing to be supported.

skrebbel 10y ago

To me, NSIS is awesome and ridiculous at the same time. It's very practical and down to earth, and it's definitely miles ahead of anything that existed when NSIS got popular (hello, InstallShield!). But the NSIS scripting language was modelled after Assembly. I mean, what? I really wonder, with delighted amazement, what went on in the heads of the people who decided to model a high level domain specific scripting language after the lowest-level language that's still human editable. I mean, hand-editing LLVM IR is easier. The good part is that assembly is actually good fun to write if you don't need to do large projects in it, and so is NSIS scripting. It sure is documented well enough. Nobody scripts installers fulltime for a living I guess, so it's a nice way to spice up work :-)

Gracana 10y ago
Oh man, this is wonderful. From the documentation: "The instructions that NSIS uses for scripting are sort of a cross between PHP and assembly. There are no real high level language constructs but the instructions themselves are (for the most part) high level, and you have handy string capability (i.e. you don't have to worry about concatenating strings, etc). You essentially have 25 registers (20 general purpose, 5 special purpose), and a stack." I like it. Really. It's pretty simple to use the registers and stack, you can use memory (variables) however you like, and all the complex stuff is provided as "commands." It looks like it's pretty easy to create a spaghetti-code mess, but like with BASIC, you can write perfectly maintainable programs if you're inclined to do so.
- tauchunfall 10y ago
  >I like it. Really. Me, too. I was amazed when I found out, that one can use Pop, Push and Exch [1] to clear registers for the scope of a function and restore the previous registers after leaving the function scope. [1] http://nsis.sourceforge.net/Docs/Chapter4.html#stackinst http://nsis.sourceforge.net/Docs/Chapter4.html#stackinst
- neko_koneko 10y ago
  > It looks like it's pretty easy to create a spaghetti-code mess Can confirm. I currently work as a malware analyst, and I frequently have to analyze (somewhat) obfuscated malware NSIS installers. Older version of the 7-zip software (v. 9.38) can extract and decompile NSIS installers, but in the newer versions this feature is no longer available, because some people on the 7-zip forums complained that users could unpack their installers and see hidden S/Ns. It's a pity.

justinfrankel 10y ago

Hi there, I created NSIS originally and maintained it through the 1.x series (a mirror of the original web site is here: http://1014.org/code/nullsoft/nsis/ http://1014.org/code/nullsoft/nsis/ ), before Kichik gracefully took over the project. I use NSIS extensively for my own projects. Given some of the comments here I thought I would mention a few things: When NSIS was first created (ca 2000), MSI did not yet exist and installers were big, fragile, and typically had many files. I made a custom installer for Winamp at some point, and then an installer-generator for Winamp plug-ins (PiMP), and later generalized that into NSIS. The script design: originally there was a list of files which would be extracted, shortcuts created, directories created, etc. The list would be processed in order. At some point Vinny from BearShare suggested (via a trivial patch) that we add conditional execution and/or looping. So that's how it ended up as "like assembly", since it was a bunch of instructions being executed. The string formatting was already there, so you don't have to manage strings, so in effect a very high level assembly. The point of writing NSIS installers is that you're really just programming a program, and the language you're using is very good at moving data around. It's not transactional, sure, but ideally if you write an NSIS installer, you can have it look at what's installed and make the correct decisions about upgrading/removing components as necessary. You can also automate the installers for network installs, plenty of system administrators do it now (/S and /D= options, in particular). The mentioned security bug in NSIS 2.1 was fixed in 2.51. Finally: last I checked with LZMA enabled, NSIS installers are very size efficient. If you program them well, they can be very robust. Anyway...

networked 10y ago
Thank you for creating NSIS! While we may complain about its assembly-like language, over the years NSIS has proved incredibly useful to countless people, including myself, both as developers and as users. And that goes beyond installers. When I was a university student I got a lot of mileage out of the PortableApps launcher, which was made with NSIS, and used NSIS to develop small, self-contained utilities in a short span of time. For the latter, few things can compare. It is interesting that the declarative vs. imperative configuration divide comes up again and again: in installers, GUI toolkits, configuration management systems, etc. Considering how many times imperative scripting gets reimplemented/hacked on top of a supposedly declarative system, I suspect NSIS made the right choice early on. Things like the PortableApps launcher would not have been possible to make with it otherwise.