The new Windows Vista, filled with shiny new features, hyped on security, and runs dead slow and with no sound on Virtual PC. I should have installed it on a real computer, but that’s a different story. This post is all about Vista’s love towards NSIS. Vista loves NSIS so much, it mentions it in no less than kernel32.dll. Well, I might be reading too much into it. It also has Gentee, InstallShield, Raphael Install Builder (what’s that?), Astrum, Inno Setup and even WinRAR.

But why? Security, what else. Vista’s new UAC asks the user to enter an administrator’s password for administrative operations, such as installing an application. Back in the old days (last Monday), one had to use runas or logout and login as an administrator in order to install an application, assuming he was running a non-administrator account. As you probably know, that’s quite annoying. Users usually use an administrator account all the time and skip this annoyance. UAC allows creating standard users with no administrative privileges and still using them comfortably, even for administrative tasks. Just like sudo for Linux or that new lock icon on Mac OS X. This way, a standard user can be used and all sorts of harm can be avoided. Malicious code accidentally executed or intentionally injected using an unpatched vulnerability will not have access to the entire computer, but rather only the user’s space.

To make it easy on the transition, Microsoft has stuffed kernel32.dll with detection code for all sorts of installers, including NSIS. When it detects an installer is being executed, it’ll automatically jump into administrative execution level, not before asking for the administrator password. A similar thing is already done older versions of Windows where an option to run as administrator is automatically presented for applications that have setup in their name.

The execution level Windows will ask from the user can be controlled by the application manifest. I started digging into this when I was adding a new command to NSIS, RequestExecutionLevel, that specifies the execution level in the manifest. I was surprised to see that even without the manifest, it still requested an administrator password. Naturally, I got curious and embarked on reckon mission to find out the nature of this newly formed relationship between NSIS and Vista. I saw most of the stuff I’ve already read about in action and those new things I just mentioned above.

However, there is one thing I couldn’t find mentioned anywhere and for which I certainly couldn’t find any logical explanation. It identifies MakeNSISw.exe, zip2exe.exe and MakeLangId.exe as something that requires administrative execution level. It also identifies the uninstaller, but that makes sense because it’s actually an installer with different strings and pages. At first, I thought it identifies every application created by another application that requires administrative execution level. I also tried installing Inno Setup and got similar results where its compiler and uninstaller were identified. But it turns out I was wrong. If, for example, I created an installer that just extracts makensis.exe (no w, the command line compiler), it’s not identified. I also downloaded MakeNSISw.exe separately and it was still identified and marked with that little Windows shield icon. I was finally convinced this is some funky bug when I saw nsisconf.nsh also comes up with that little shield icon and that’s just a text file which is not even associated with MakeNSISw.exe. Then I realized NSH files take their icon from MakeNSISw.exe and that was indeed why it’s marked with the shield.

If something as harmless as MakeLangId.exe gets labeled, I wonder what else does… I hope they fix it until RC2. Not the nicest of features. Too much on the paranoiac side…

Update: seems like MakeLangId.exe and MakeNSISw.exe are labeled because they contain the phrase “Nullsoft.NSIS” in its manifest. I don’t see why they’d want to do that. That’s just a prefix we use. Installers are marked with “Nullsoft.NSIS.exehead”, there’s no need to catch the entire package. That’s definitely enough information for a bug report.