NSIS 3.0 ready
nsis.sourceforge.net
nsis.sourceforge.net
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...
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.
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 :-)
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.
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
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.
wow
I'll have to look for that in the future. I guess removing the disassembler from a common piece of software raises the bar a bit, but still.. yikes.
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.
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.
https://visualstudiogallery.msdn.microsoft.com/f1cc3f3e-c300...
http://geekswithblogs.net/TarunArora/archive/2014/04/24/visu...
That said: I use WiX and I find it works adequately.
> leaks Windows Installer abstractions
Okay
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.
Not open source though and the free version is not full-featured.
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.
Chrome has had the insecure behavior for years. Not sure if it does currently.
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.
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.
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.
https://news.ycombinator.com/item?id=11092219 https://news.ycombinator.com/item?id=11860752
https://sourceforge.net/blog/sourceforge-now-scans-all-proje... http://www.linuxinsider.com/story/83105.html
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.
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.
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.
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.
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.
[0]: https://msdn.microsoft.com/en-us/library/windows/desktop/hh8...
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.