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/ ), 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.
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.
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 :-)
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.
> 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.
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.
And people still use it over creating MSIs? Madness. I hate everything that's not an MSI as I deploy software in schools. Of course as soon as Office 2007 stopped being a normal MSI all hope was lost. If Microsoft won't use it why would anyone else?
MSI and the whole Microsoft setup engine ecosystem is very wrong and a waste of hardware resources and people's time.
I get the benefits of MSI and MSM when managing a fleet of machines, but it exhibits the same issues as Microsoft's other installers and update engines. It takes ages to do anything and during that seemingly seeks around the disk or eats up cpu for no reason. Sometimes it takes minutes or an hour just to return a failure condition at the end. If you compare the update process of a Debian install, which can update before first boot, to a Windows installation, you cannot explain what Microsoft is doing. The only explanation I've heard is that Windows doesn't have the required info in their databases and thus has to seek around the disk for a very long time.
Now, if you compare that to an NSIS installer, which admittedly doesn't support the Windows Domain deployment scenarios that MSI does, it's instant and you can understand where time is spent.
I do not understand why Microsoft doesn't fix those shortcomings.
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.
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.
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!"
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.
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.
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.
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.
It's an issue for the scenario I mentioned above which has been exploited in the wild for months now. You create a fake SHFOLDER.DLL or similar with your payload in it and stick it on every hacked WordPress or similar site you can. Google Chrome's stupidly insecure download setup allows any website to automatically download the vulnerable DLL right to the Downloads directory with no user interaction required. Now, every single legitimate NSIS or InnoSetup installer that hasn't been patched against this vulnerability that the end user downloads and runs will use the infected DLL instead of the legitimate one.
The above works regardless of how the admin has defined the search path. It's a legitimate vulnerability. Installers specifically should be hard coded to only use Windows DLLs from the Windows directories.
Realistically, Google Chrome should be fixed to not be so dumb and insecure with EXEs and DLLs as well. It may have been by now but it was definitely vulnerable when NSIS fixed this exploit and it was the primary attack vector since browsers like Firefox don't allow websites to automatically download infected DLLs to your Download directory.
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.
Another +1 for NSIS with older / elderly customers. I've also had success in that respect, and the NSIS support for custom DLLs let me extend NSIS to improve usability. (My products have to be installed in the plugins folder of dozens of different commercial programs, the DLL support lets me detect that automatically for my customers.)
I also like InnoSetup, and its Pascal scripting is certainly more straightforward than the NSIS Assembly-like coding, but NSIS has served me very well.
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!
Being careful with downloaded software might be one thing (even though there isn't any indication that there is any of that going on right now), but not visiting the site? Did SF ever did something justifying that?
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.
NSIS has ages of history. It was written while many HNers were still in elementary school. Projects with that much built-up documentation and massive amounts of deep links don't just move on a whim.
Yes. This. We have so much invested in SourceForge including scripts, a whole Wiki and tons of history. Ideally we'd move to GitHub one day, but it'll be a sizable project. There is already a mirror of the code on https://github.com/kichik/nsis and hopefully more will come in the future.
As for SourceForge injecting adware, they only do that to dead projects or projects that volunteer. NSIS is neither. Many people approached me asking to bundle their stuff, even outside of the recent SourceForge efforts, and they were always swiftly rejected.
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.
MSI is hardly transactional. Out of "ACID", it's "happy-path-only-Atomic", "happy-path-only-Consistent", certainly
"grab-the-global-mutex-Isolated", and "as-long-as-file-system-is-ok-Durable".
I don't think it is possible to make Windows installers fully transactional, but architecture astronauts from Microsoft did their best to pretend that MSI is actually capable of transacted installs. Which is why MSI is such a horrorshow.
And yet, MSI is the official package manager format. Saying that you prefer shipping your product with a InnoSetup or NSIS installer is akin to saying that you prefer self extracting shell scripts to .deb or .rpm packages under Linux.
Aside of the (slightly) transactional support, MSIs also allow for easy centralised deployment and because correctly authored MSIs are declarative only, an admin can potentially audit the installation process before running it.
Finally, when you kill dpkg or rpm at the right time, you will have an equally non-working install under your Linux distro as you will have a non-working install of your MSI file when you kill msiexec at the right time.
Don't get me wrong. I agree with you that MSI is suffering from overengineering and I agree that the UI is really messy, especially with regards to updates, but instead of trying to find different, less standardized installers, we should invest in better tooling (compared to WiX) and maybe tell Microsoft what we need changed.
Not trying to be purist here but NSIS is explictly non-transactional: killing the installer process in the middle of the installation doesn't perform a rollback later.
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?
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.
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:
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.
You can do it with MultiUser.nsh. I've just published an installer script like that: 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.
Are you 'the' Justin Frankel? If so, I feel vindicated in my decision :) (which was admittedly controversial among my colleagues at the time because NSIS is so much more 'natural' to use than MSI). I mean if even you find UAC a pain, then it's only normal that those of us with much less insight into the inner workings of NSIS are having a much harder time still...
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/ ), 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...