Tyler from Microsoft has contacted me about my Vista bug report. He said he’ll open an internal bug report for it, but can’t promise it’d be fixed before RTM. In the mean time, newer versions of NSIS will include the manifest so no problems should come up with them.
While working on a new NSIS header file to properly handle Windows versions, I thought of something really cool. The LogicLib is a cool library dselkirk and eccles wrote a long time ago. It allows you to avoid using labels, Goto, StrCmp, IntCmp, relative jumps and other cool beans. Instead, you get a bunch of macros wrapped in defines that make your life so much easier.
${If} $0 == "good" DetailPrint "it's not evil" ${EndIf}
It struck me while I was thinking of the interface I want to use for the new version checking stuff, I originally started with a function taking an argument. However, functions and header files don’t work too well together. A warning is spewed, if the function isn’t used. The code was also meant to be short, as there isn’t too much to do. So, combine those two together and of course you get macros. But what will the macro get? Labels to jump to? What if the user passes relative jumps? What if the user wants to skip a label definition and just jump to the next line? Why can’t it be like LogicLib? Because these checks don’t fit into LogicLib.nsh? So what? Why can’t I define more tests for LogicLib? Who said I can’t? I can.
And it turns out adding more tests to LogicLib is quite easy as well. Just define a macro with a name prefixed with an underscore and give it four parameters. Two operands and jump labels for true and false. The LogicLib will handle creating the labels and all that is left for this little macro is the actual test.
!macro _= _a _b _t _f IntCmp `${_a}` `${_b}` `${_t}` `${_f}` `${_f}` !macroend
The end result is quite cool. Instead of yet another new interface for another functionality, there are just a few new operators for LogicLib.
${If} ${AtLeastWin2000} DetailPrint "2000 or better. Fun!" ${EndIf}
The new code is available on CVS for your eager browsing. Crave code. Craving is good.
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.
I just had a quick look at the statistics and noticed NSIS downloads on SourceForge surpassed 1,000,000. That’s one and a half terabyte of NSIS downloads. Add a couple million page views a month taking around 17GB of bandwidth and you’ll get quite some bandwidth. So, before I sit back, relax and step on cloud nine, I’d like to thank SourceForge for their hosting for the last 4 years. I don’t even want to think about having to handle that just as a side dish to the big-shot projects that have over one million downloads a day.
I’ll sit back now. See you in 1 more million downloads 
Welcome to my blog. I’m Amir Szekely, also known as kichik. I’m a programmer living in Israel. Most of my computer time, when not at my workplace, I spend on NSIS, an open-source installer for Windows. I’ve been working on it for over 4 years and it has been quite fun.
I don’t know what type of posts you can except to find here, only time will tell. I guess it’d include the occasional NSIS techy post, maybe some tips & tricks, some rants of a perfect world, movies, games, who knows… Just in case, I’ve setup a syntax highlighting extension, so I can share some NSIS codes here and there.
Name test OutFile test.exe Section SetOutPath $TEMP File /oname=test.nsi "${__FILE__}" Delete $TEMPtest.nsi SectionEnd
Installing this extension and the entire blog was a piece of cake. WordPress is very easy to use, with lots of DHTML and a smooth user-interface. I’m quite impressed. Took me a while to find a nice theme, but MistyLook saved the day.