NSIS v3.0rc1

NSIS 3.0rc1 is the first release candidate for NSIS 3. It contains additional DLL hijacking prevention code, a fix for !appendfile on POSIX that broke LogicLib, some documentation improvements and other small touchups. MakeNSIS will now give a warning if the output file is named "setup.exe" because Windows insecurely loads compatibility shims before any of our code runs for this specific filename.

Please report back if you are using plug-ins that require .NET WinForms or GDI+ and are having issues on Windows 7. See MS Connect for the latest news on this issue.

• Release Notes
• Known issues:
  • WinForms/GDI+ font failure on Win7 (NSIS 2.47-2.51 and 3.0b3+)

If you find any new issues, report them in this thread and/or on the SF bug tracker and please include compiler error messages and sample code if possible...

Good to see improvements and security fixes in 3.0rc1.

Just wanted to know tentative dates for official release of 3.0 branch.

Thanks,
San

We can't give exact dates because development is mostly volunteer work, so we release it when we think it's ready (which is why it's been more than five years since v2.46 came out).

No new bugs have been filed for rc1 so we are really only waiting for the GDI+ issue but if it is not solved by the end of May we will probably release...

Thanks for reply Jason and Andres. That was useful in planning ahead of time, I will keep a watch in the forum. I do completely understand limitations due to voluntary work, the changes you guys have made in v3.0 is really great.

I'm very happy to see that a release of NSIS 3.0 final is on the horizons, you guys did a great job. However, there are still a couple of things that, to me, remain unresolved. In this post I would like to address some of them. Some of them have been discussed before, but since they still haven't been addressed in RC1, I'd like to bring them up. This is not a rant, just an expression of unhappiness.

Post-Windows XP is a reality

As you know, Microsoft finally retired Windows XP. As of April 2014, Microsoft no longer provides “security updates or technical support for the Windows XP operating system” and the company urges users to migrate to a modern version of Windows. Not everyone is convinced about this, and for one reason or another there is a still considerable amount of users for whom migration is out of question. In April 2016, according to NetShare, Windows XP is still the third most-used operating system on the planet, installed on 9.88% of all computers. That is a problem.

On the other hand, I always respected NSIS for supporting such a width of Windows systems, the amount of work that went into that cannot be appreciated enough. Hell, I'm not arguing that support for pre-Vista versions of Windows should be dropped, that's not my point. I'm talking about the 74.6% of users that use Windows Vista, Windows 8, Windows 8.1, or Windows 10 (embezzeling all server equivalents), the majority of Windows users – potential NSIS users.

So, what's the problem?

The problem, to me, is some of NSIS default settings still appear to me biased towards pre-Vista. Take the compiling options in the Explorer context-menu.

WriteRegStr HKCR ".nsh" "" "NSIS.Header"

WriteRegStr HKCR ".nsh" "PerceivedType" "text"

WriteRegStr HKCR "NSIS.Header" "" "NSIS Header File"

WriteRegStr HKCR "NSIS.Header\DefaultIcon" "" "$INSTDIR\makensisw.exe,2"

ReadRegStr $R0 HKCR "NSIS.Header\shell\open\command" ""

${If} $R0 == ""

  WriteRegStr HKCR "NSIS.Header\shell" "" "open"

  WriteRegStr HKCR "NSIS.Header\shell\open\command" "" 'notepad.exe "%1"'

${EndIf}'

Source: makensis.nsi, lines 267-275

This code will create a context-menu, which let's the user compile NSIS script files using right-click in the Explorer. It works on probably all versions from Windows 95 (wild guess) to Windows XP (fact). Alternatives for this piece of code have been around for ages. Implementing these doesn't mean support for Windows XP and earlier goes away, it's a conditional option.

Let's talk User Account Control. UAC has been introduced to Windows with the release of Vista in November 2006 (RTM)/January 2007 (general availability), soon that's 10 years ago. As of then, unless deliberately disabled, Windows requires administrative permissions to write files to $PROGRAMFILES. As a side-effect, none of the Examples that ship with NSIS can be tested in its default location – makensis would have to be run with admin rights to be able to write an installer. I haven't checked whether it's mentioned in the documentation, that in order to compile examples, the user would have to copy them to user space, or compile as admin (which, for good reason, is not a given option).

${MementoSection} "Script Examples" SecExample



  SetDetailsPrint textonly

  DetailPrint "Installing Script Examples..."

  SetDetailsPrint listonly



  SectionIn 1 2

  SetOutPath $INSTDIR\Examples

  # shortened by the author of this post



${MementoSectionEnd}

Source: makensis.nsi, lines 279-335

It's my understanding, that in a post-XP world, Examples (and arguely other folders, e.g. Contrib) should be installed in $APPDATA (or $LOCALAPPDATA). Again, to preserve backward compatibility, this could be conditional. I remember, the last time I recommended this, it was countered with the question how the NSIS installer would deal with an update.

Seriously? How are Plugins treated in 3.x? Their folder structure has changed as well!

1. NSIS currently recommends uninstalling a previous version before continuing installing a new version. This could easily be enforced or warned about in a major upgrade. Maybe install to a different folder, so NSIS 2.x and NSIS 3.x can co-exist.

2. “NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for internet distribution.”

In any case, for your convenience only, Examples could remain as a shortcut (or even symlink).

Post-SourceForge should be a reality

Yes, I'm biased against SourceForge, I give you that. Yet, I have used SourceForge for more than 10 years, since it provided me good service for most of that time. What bothers me about SourceForge is weak platform performance (how often does the Wiki goes down when you do multiple changes?) and it's uninviting culture to participate. Let's not even talk about them wrapping installers with their own crapware. I was happy when I saw kichik's NSIS repository on GitHub. Unfortunately, it's basically as read-only as the SVN repository. From my understanding it uses an automated solution (possibly svn2git) to push changes from SVN to Git. It's a one-way road.

How is that my problem?

Aside from preferring git itself as a version control system, I love GitHub (synonymously used for Bitbucket, GitLab, etc.) for its accessibility. For a small fix, you wouldn't even clone the repository, you can fix a typo in the translation or documentation directly in the browser. You can offer changes through a pull request without needing write access to the repository. You don't need to fumble around with diff to submit a patch. It's so much more transparent and inviting, it's living the open source idea.

(I don't know if NSIS started on CVS. Did you migrate to SVN? What were you're motives back then?)

Would love to get an open-minded discussion going on here.

PS: hopefully not too many typos in here 🙄

I don't understand why you wait this long before bringing up these issues, during Betas we might have a chance but the RC stage is bug fixes only pretty much.


Filetype registration:
Some people like the submenus and other people don't but they are Win7+ only so it would complicate the installer unless you suggest we drop Vista as well. I personally never right-click a .nsi file to compile anyway so the issue has never really crossed my mind that it needs "fixing".

Looking at your code, "MUIVerb" is pointless if you don't point it to a .dll file with resources in multiple languages and "Icon" and "CommandFlags" are undocumented AFAIK.


Examples vs UAC:
Yes the current situation is not optimal. For files the user is supposed to edit then yes, they should be copied to $[Local]AppData. The problem is that the copy to appdata is supposed to be done by the application the first time a user runs it but we don't really have an application that the user runs.

Giving write access for everyone to create new files in the examples directory under program files might work, this should be investigated. Letting anyone edit the .nsi files in there is probably not a good idea. It is unlikely but possible that someone could make example1.nsi do evil things and then just wait for an admin to compile and run it...


Upgrade:
Most users probably just want one version installed. To support side by side versions we would have to do some planning, as a minimum the uninstall key has to change so we don't overwrite the old entry. Not sure what to do about the start menu and file types...

SourceForge:
I know Kichik likes GitHub as well so who knows. If we move to Git then it is however probably the end of my involvement as a developer on this project.

The repo on GitHub is used by the "nightly" build. For whatever reason it is not fully automated at the moment so it is not really a nightly.

The wiki does not have 100% uptime but at least there is a wiki, I'm not sure if GitHub has wikis?

As far as creating patches, you can just execute "svn diff > mypatch.patch". Not as easy as doing something on a web page I'll give you that but it is not rocket science.

Back in the really old days the source was just part of the installer but I think we also used CVS at some point, at least the initial SVN import came from CVS.

-----

So to sum up. Am I happy with the current design of our installer? No, I'd like to see a per-user and all users option along with fixes for systems with UAC but this is not just a quick fix away from reality. I did rewrite the installer with per-user and USB portable options at some point but I don't remember why it never got into trunk. It certainly made things more complicated when uninstalling because you need to uninstall the correct instance.

The next big hurdle is 64-bit support and I don't think we will support building for 95/98/ME at that point so it might be a good place to make other breaking changes as well. The code itself is 64-bit ready except for some features in System.dll but we also need to do something with our build system so we can generate 64 and 32-bit stubs and plugins from one SCons script. The v3 compiler officially is supposed to be Win2000+ but probably works on NT4 if you install IE5 and those limits can perhaps be raised when we start going beyond 3.0. Perhaps we make the shell stuff only fully work on Win7+ but let the compiler itself still work on XP.

Unfortunately our development pace is rather slow and if somebody wants to help out that would really speed things along. A patch for 64-bit callback support in System.dll would be really appreciated so if anyone out there likes coding 64-bit assembly, here is your chance 😉

I don't understand why you wait this long before bringing up these issues, during Betas we might have a chance but the RC stage is bug fixes only pretty much.

As I said before, I already mentioned at situation with the context-menus and the Examples. For my understanding, such changes should be fine to address in the RC phase. I'm willing to help working on this, even though SVN is a meh. I might already have write access, and unless you want to coordinate changes, I can submit code.

Also, I have worked on a new installer branding for a long time, as well as graphic assets and icons, to be included. This should all be considered before going final. Kichik is in the picture about this, as well as a new website that should, in long distance, fully replace the current Wiki. Design and build tools for the page are about complete, as is a huge chunk of content. This should as well be considered before the final release, so all the URLs in the installers and documentation can be adjusted.

PS: I would like to know why Git is such a big change for you, that you would go as far as evaluating your commitment.

Graphics and icons are not a problem to change although I already made new filetype icons recently so I'm not sure if you feel those need to change. Everything else is a problem because in my mind when you make a RC release, unless there are any showstoppers the final release should be the same as the last RC. We don't want to introduce new bugs at this stage!

I still don't understand the context menu issue. Other than the normal MakeNSISW command, which commands do you actually want? Are you proposing that we search for other NSIS versions and add those as well? And on top of this, are you suggesting that we rely on undocumented registry entries and magic values to do it?

As far as the Example issue goes, I'm certainly willing to evaluate whatever solution you think you have but in my mind (for reasons I have already explained) it is hard for us to follow the appdata guidelines and I see changing the ACL on the Examples directory as our best option.

Regarding Git, I just don't like the Windows ports of it, I don't want Bash or anything like that, I want a pure Windows version. I don't want anyone creating dot files/directories in my profile root, if you do that you get uninstalled from my machine...

Just my 2 cents worth.

Regarding the program files folder, just don't install to that folder. I make a habit of installing older software to non-protected folders so that they work the way they should. That said though, NSIS is a special case so I'm in favor of keeping the status quo for now.

With building 32 bit and 64 bit stubs, I do like the idea of moving the build system from scons to cmake, then again I don't have any experience with using cmake. I might look at cmake a bit more and run a few experiments, this will be long term though and most of the dev work will be on linux first.

Recently Microsoft announced that they are creating a linux subsystem for windows 10 that runs native linux executables, and the command line is bash. So linux versions of subversion and git can be run.

I don't see a problem with the context menu for single installs, but because I work with multiple source built installs I just run makensisw for the version I need and 'drag and drop' the .nsi onto it. I do see a problem if we start adding multiple versions to the context menu, as the list can get very long this way. Perhaps we just add an option for each major version, so currently it's just two versions. But even this can get complicated, but it's not really a big deal since the development cycle is so long.

I was going to mention if the nsis menu icon can be updated, because the edges aren't alpha transparent and the pixels stick out like a sore thumb on dark backgrounds.

Originally Posted by Anders View Post

I still don't understand the context menu issue. Other than the normal MakeNSISW command, which commands do you actually want?

I don't want anything else feature-wise, I just want the context-menu to work on Windows Vista and later. Just to clarify: do you get a visible context-menu when installing NSIS on any post-XP Windows? I don't, and that's what I was complaining about. The last time I had a working context-menu was in my XP days, ever since it never seemed to be present (tested on Windows Vista, Windows 7 and Windows 10.)

If there really is no reliable documentation on how to get context-menu working on modern Windows, I'd rather skip the creation of the menu altogether than adding keys to the registry that don't do anything.

Originally Posted by Anders View Post

Regarding Git, I just don't like the Windows ports of it, I don't want Bash or anything like that, I want a pure Windows version

Ah, I didn't think about that. Thought that was resolved by now:

Originally Posted by Yathosho View Post

If there really is no reliable documentation on how to get context-menu working on modern Windows, I'd rather skip the creation of the menu altogether than adding keys to the registry that don't do anything.

We are doing it the classic way (static verb) and should work everywhere, documented @ https://msdn.microsoft.com/en-us/lib...ze_verb_static

Maybe something is wrong on your system? MUIVerb is not required for static verbs and works on 2000+ IIRC. CommandFlags is only documented for use with ExtendedSubCommandsKey and Icon is not documented anywhere AFAIK. I'll try to do some investigation on Friday...

For as long as I can remember I've always had the context menu available and working (XP, 7, 8.1 and 10), perhaps something has messed it up on your system.

What Anders means by a Windows native Git is that the source code can be compiled on Windows and create Windows native binaries, instead of relying on a linux based backend port to make it work on Windows (which is what msys is).

Originally Posted by Anders View Post

Maybe something is wrong on your system?

I considered this, which is why I also tested this in a VM. Strange.

Originally Posted by Yathosho View Post

I considered this, which is why I also tested this in a VM. Strange.

Works fine for me



Try running

Section
DetailPrint ":::Incomplete classic association lookup:::"
ReadRegStr $0 HKCR ".nsi" "" ; BUGBUG: Does not handle versioned ProgIds!
DetailPrint ProgId=$0
ReadRegStr $1 HKCR "$0\Shell" ""
DetailPrint Verb=$1
StrCmp $1 "" 0 +2 ; BUGBUG: Fails if there is no default and no open!
StrCpy $1 "open"
ReadRegStr $2 HKCR "$0\Shell\$1\command" ""
DetailPrint Command=$2
!include LogicLib.nsh
DetailPrint ":::IApplicationAssociationRegistration:::"
!include WinCore.nsh
!include Win\COM.nsh
StrCpy $3 "?"
!insertmacro ComHlpr_CreateInProcInstance ${CLSID_ApplicationAssociationRegistration} ${IID_IApplicationAssociationRegistration} r0 ""
${If} $0 Z<> 0
    ${IApplicationAssociationRegistration::QueryCurrentDefault} $0 '(".nsi",${AT_FILEEXTENSION},${AL_EFFECTIVE},.r2).r1'
    ${If} $1 = 0
        System::Call '*$2(&w${NSIS_MAX_STRLEN} .r3)'
        System::Call OLE32::CoTaskMemFree(pr2)
    ${EndIf}
    ${IUnknown::Release} $0 ""
${EndIf}
DetailPrint "QueryCurrentDefault: ProgID=$3"
DetailPrint ":::FindExecutable:::"
SetDetailsPrint textonly
InitPluginsDir
File "/oname=$PluginsDir\test.nsi" "${__FILE__}" ; File needs to exist or FindExecutable fails
SetDetailsPrint both
System::Call 'SHELL32::FindExecutable(t"$PluginsDir\test.nsi",p0,t.r1)i.r0'
IntCmpU $0 32 +2 +2
StrCpy $0 "OK"
DetailPrint "FindExecutable: Status=$0 Exe=$1"
DetailPrint ":::AssocQueryString:::"
System::Call 'SHLWAPI::AssocQueryString(i0x00000100,i1,t".nsi",p0,t.r1,*i${NSIS_MAX_STRLEN})'
DetailPrint Command=$1
System::Call 'SHLWAPI::AssocQueryString(i0x00000100,i2,t".nsi",p0,t.r1,*i${NSIS_MAX_STRLEN})'
DetailPrint Exe=$1
SectionEnd 

it should give you something like

:::Incomplete classic association lookup:::
ProgId=NSIS.Script
Verb=open
Command=notepad.exe "%1"
:::IApplicationAssociationRegistration:::
QueryCurrentDefault: ProgID=NSIS.Script
:::FindExecutable:::
FindExecutable: Status=OK Exe=C:\WINDOWS\system32\notepad.exe
:::AssocQueryString:::
Command=notepad.exe "%1"
Exe=C:\WINDOWS\system32\notepad.exe

Main Windows computer. Will check my VMs tomorrow.

:::Incomplete classic association lookup:::

ProgId=NSIS.Script

Verb=open

Command=notepad.exe "%1"

:::IApplicationAssociationRegistration:::

QueryCurrentDefault: ProgID=Applications\sublime_text.exe

:::FindExecutable:::

FindExecutable: Status=OK Exe=C:\Program Files\Sublime Text 3\sublime_text.exe

:::AssocQueryString:::

Command="C:\Program Files\Sublime Text 3\sublime_text.exe" "%1"

Exe=C:\Program Files\Sublime Text 3\sublime_text.exe

It is possible you have done a "Open With" or something like that which has caused the effective ProgId to point to Applications\sublime_text.exe and that is why the compile items are missing.

Originally Posted by Yathosho

Take the compiling options in the Explorer context-menu.

Aren't you looking at the wrong code? The code for compiling scripts looks like this:

ReadRegStr $R0 HKCR ".nsi" ""

StrCmp $R0 "NSISFile" 0 +2

  DeleteRegKey HKCR "NSISFile"



WriteRegStr HKCR ".nsi" "" "NSIS.Script"

WriteRegStr HKCR ".nsi" "PerceivedType" "text"

WriteRegStr HKCR "NSIS.Script" "" "NSIS Script File"

WriteRegStr HKCR "NSIS.Script\DefaultIcon" "" "$INSTDIR\makensisw.exe,1"

ReadRegStr $R0 HKCR "NSIS.Script\shell\open\command" ""

${If} $R0 == ""

  WriteRegStr HKCR "NSIS.Script\shell" "" "open"

  WriteRegStr HKCR "NSIS.Script\shell\open\command" "" 'notepad.exe "%1"'

${EndIf}

WriteRegStr HKCR "NSIS.Script\shell\compile" "" "Compile NSIS Script"

WriteRegStr HKCR "NSIS.Script\shell\compile\command" "" '"$INSTDIR\makensisw.exe" "%1"'

WriteRegStr HKCR "NSIS.Script\shell\compile-compressor" "" "Compile NSIS Script (Choose Compressor)"

WriteRegStr HKCR "NSIS.Script\shell\compile-compressor\command" "" '"$INSTDIR\makensisw.exe" /ChooseCompressor "%1"'

Hey Anders, I just wanted to quickly check in and see if there are any updates as to the timeline for the 3.0 release. I realize this is a volunteer effort and that dates will be more difficult to nail down, but I wanted to see if there was at least a rough approximation as to the schedule now that we're further into the release cycle. We would love to incorporate some of the improvements in 3.0 into our upcoming release, and want to know how it syncs to NSIS 3.0 development.

Thanks!

I already answered this question in this thread! The compiler and produced installers are not going to change between now and final.

${NSISDIR}\Examples\Modern UI\MultiLanguage.nsi
I find the installer's UI of Traditional Chinese(中文(繁體)) is weird and different from other languages on Win10. It's normal on Win7.
What's the problem..

Originally Posted by kzh125 View Post

${NSISDIR}\Examples\Modern UI\MultiLanguage.nsi
I find the installer's UI of Traditional Chinese(中文(繁體)) is weird and different from other languages on Win10. It's normal on Win7.
What's the problem..

Saying something is weird does not help much, a screenshot of right and wrong on the other hand...

Originally Posted by Anders View Post

Saying something is weird does not help much, a screenshot of right and wrong on the other hand...

Originally Posted by kzh125 View Post

What's the problem..

Wikipedia has this to say about PMingLiU (新細明體):

distributed by Microsoft with Traditional Chinese version of Windows 98 operating system, all regional versions of Windows 2000 to Windows 8.1, and Traditional Chinese version of Windows 10.

so it is possible that you don't have the font but according to http://answers.microsoft.com/en-us/w...a-fd6b57e61fe4 if you configure your system for this locale/layout the font will be installed.

switched from NSIS 3.0b1 to NSIS 3.0rc1 and the same script that worked before start showing error:

Processed 1 file, writing output (x86-ansi):
Adding plug-ins initializing function... Done!
Error: could not resolve label "_LogicLib_EndSelectLabel_100" in install section "" (0)
Error - aborting creation process

It looks like crash on Processing pages... any ideas?

Originally Posted by DARKA View Post

switched from NSIS 3.0b1 to NSIS 3.0rc1 and the same script that worked before start showing error:

Processed 1 file, writing output (x86-ansi):
Adding plug-ins initializing function... Done!
Error: could not resolve label "_LogicLib_EndSelectLabel_100" in install section "" (0)
Error - aborting creation process

Can you provide some sample code?

Thank you for sending me your code. I was able to reproduce it but for future reference, please remove all 3rd-party plug-ins and files when possible. I had to do a fair amount of work just to get past the missing files and plugins errors!

Here is a minimal example of the problem:

StrCpy $1 1
StrCpy $2 2
${Select} $1
${Case2} 0 9
    DetailPrint c0+9
${Case2} 1 9
    DetailPrint c1+9
    ${Select} $2
    ${Case2} 2 3
        DetailPrint c1+9:c2+3
    ${EndSelect}
${EndSelect} 

I have tried to fix it, you can grab a updated LogicLib.nsh here and overwrite the original and see if this fixes it...

Thank you, your fix works.
In future i try prepare minimal example for reproducing error :-)

Originally Posted by Anders View Post

No new bugs have been filed for rc1 so we are really only waiting for the GDI+ issue but if it is not solved by the end of May we will probably release...

Just wanted to check whether v3.0 release should be expected soon (considering May has ended 🙂 )

Originally Posted by sandeep_hi View Post

Just wanted to check whether v3.0 release should be expected soon (considering May has ended 🙂 )

3 bug reports have been filed after I wrote that. One has been fixed but the other two have not and unfortunately those reports provided very little information so the next release will be delayed a bit until we figure out what to do.

One is https://sourceforge.net/p/nsis/bugs/1143/ but it is so unclear that unless we get more information there is nothing we can do, the other bug was reported privately but also lacking useful information.

Do you have any estimation when final version is released?