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.

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

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

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

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:

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/

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.

I use the UAC plug-in, but it is a pain indeed :/

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

yes, he's the real deal