
NSIS 3.0 ready - networked
http://nsis.sourceforge.net/News
======
justinfrankel
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
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.

------
skrebbel
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
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.

~~~
neko_koneko
> 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.

~~~
Gracana
> some people on the 7-zip forums complained that users could unpack their
> installers and see hidden S/Ns

 _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.

------
anton_gogolev
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.

~~~
taspeotis
There's a free one from Microsoft, or InstallShield LE.

[https://visualstudiogallery.msdn.microsoft.com/f1cc3f3e-c300...](https://visualstudiogallery.msdn.microsoft.com/f1cc3f3e-c300-40a7-8797-c509fb8933b9)

[http://geekswithblogs.net/TarunArora/archive/2014/04/24/visu...](http://geekswithblogs.net/TarunArora/archive/2014/04/24/visual-
studio-2013-installer-projects-ndash-hello-world-installer.aspx)

That said: I use WiX and I find it works adequately.

~~~
nathanaldensr
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
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

------
johnhattan
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
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
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.

~~~
JohnTHaller
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.

------
joemccall86
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
Dittos! I actively use it and it's great to see such a storied project
continuing to be supported.

------
AdamN
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?

~~~
howderek
SourceForge changed owners and doesn't have many of those issues anymore.

[https://sourceforge.net/blog/sourceforge-now-scans-all-
proje...](https://sourceforge.net/blog/sourceforge-now-scans-all-projects-for-
malware-and-displays-warnings-on-downloads/)
[http://www.linuxinsider.com/story/83105.html](http://www.linuxinsider.com/story/83105.html)

~~~
liareye
Yes and I hear the DNC has changed ownership as well.

------
wslh
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.

~~~
anton_gogolev
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.

~~~
tobias3
Since Vista Windows has transactional NTFS and registry e.g.
CreateFileTransacted and RegOpenKeyTransacted, so it should be possible...

~~~
anton_gogolev
Transactional NTFS is deprecated [0], and having a transactional Registry buys
you very little.

[0]: [https://msdn.microsoft.com/en-
us/library/windows/desktop/hh8...](https://msdn.microsoft.com/en-
us/library/windows/desktop/hh802690\(v=vs.85\).aspx)

~~~
tobias3
I know that. But that wouldn't stop Microsoft from using it.

