NSIS 3.0a2

It's the holiday gift you've been waiting for!

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

New known issues:

• Installer welcome page still says NSIS 2

Is there any progress on a Linux version of this? I've been using 2.46 as part of an automated build system on Linux, but lately I've been running into issues with the max path length of 260 characters imposed by Windows. I was hoping to get around this by using the Unicode command in NSIS 3.0.

I've looked into the Unicode version of 2.46, but there doesn't seem to be Linux version of that either.

Originally Posted by calebd View Post

Is there any progress on a Linux version of this? I've been using 2.46 as part of an automated build system on Linux, but lately I've been running into issues with the max path length of 260 characters imposed by Windows. I was hoping to get around this by using the Unicode command in NSIS 3.0.

I've looked into the Unicode version of 2.46, but there doesn't seem to be Linux version of that either.

You can try the SVN trunk, it should work or be pretty close.

Originally Posted by Anders View Post

You can try the SVN trunk, it should work or be pretty close.

Well it seems to be working so far - I'm at least able to build makensis now. I'll try building some installers and update this with the results.

I have the compiler compiling on 64 bit linux, and it runs my test script on windows with no errors (both ansi and unicode 😁). The 64 bit stuff isn't fully implemented yet, but the 32 bit build should compile completely on linux with a cross-compiler, mingw-w64 is what I'm using (scons XGCC_W32_PREFIX=i686-w64-mingw32-). You'll need a windows zlib package (for compiling zip2exe) and wxWidgets installed (for compiling NSIS Menu).

Teaser for makensis 64 bit:

Now that I'm picking up some of my old NSIS projects, I was wondering what the idea behind the new directory structure for plugins has been. NSIS development has always been conservative (no negative undertone intended!) when it comes to such things, so the change has been a bit of a surprise. The structure of the (unofficial) Unicode fork wasn't ideal either due to duplicate files (not only plugins), but I think there are better ways to solve this. I'm mostly thinking about the broken backward-compatibility for existing plugin installers and so forth. Why not simply place Unicode plugins in a subfolder inside the Plugins-directory and keep all other files as in 2.x? I can imagine many old plugin installers etc. will never be updated and require annoying manual moving (and a solution through symlinks isn't possible either). Not to mention all the extra check necessary for future plugins.

I'm sure you guys put a lot of thought into this (as always!), but since I didn't follow the process, I'd like to know what lead to this decision for the current directory structure.

AFAIK the official position has been that other plugins should not go in that plugins directory since it will be deleted if you upgrade? I have several NSIS versions installed at the same time so I just use !addplugindir $%APPDATA%\... for other plugins but I understand that this is not a good idea for scripts that you distribute to other people.

!if "${NSIS_CHAR_SIZE}" = 1
!addplugindir "${NSISDIR}\Plugins"
!endif

Should work if the script is Ansi. With Unicode you would actually have to say mypluginW::function for that to work...


Anyway, the way it works now is because it builds the subdirectory name by doing CPU+CharSet. The fork invented the W suffix convention but that does not scale to other CPU targets.

Hopefully you will see another directory in there soon (amd64-unicode) 🙂

Is 3.0a2 ready for prime time if I'm doing really a simple installer?

I'm not sure if it's alpha because it's not feature complete, or alpha because it's untested.

TIA

The previous alphas did have some bugs, the current alpha has no known issues (on Windows) and 99% percent of the work is taking place in makensis and the build system, not in code that runs on the end-users machine.

If we slapped a beta label on it would it make you more comfortable? It is after all just a label, even releases marked as stable can be buggy.

SVN trunk has usable 64 bit support now but shipping that as part of the 3.0 final is not going to happen. I assume that once the remaining POSIX bug is fixed you will get beta(s?) and 3.0 final...

Anders,
Take a look at this folder: \NSIS_3\Bin
There is "GenPat.exe" application. I am not sure, but I think, in 2.4x releases I could use it without any external dlls...
Now, to use GenPat, I had to copy to Bin folder "zlib1.dll" library.
I suppose other apps also looking for that lib... Maybe you should add this to makesis setup to install it to this location...

-Pawel

Originally Posted by Pawel View Post

Anders,
Take a look at this folder: \NSIS_3\Bin
There is "GenPat.exe" application. I am not sure, but I think, in 2.4x releases I could use it without any external dlls...
Now, to use GenPat, I had to copy to Bin folder "zlib1.dll" library.
I suppose other apps also looking for that lib... Maybe you should add this to makesis setup to install it to this location...

zlib1.dll should already exist in \bin

Yes, you are right! Sorry.
I wrote it incorrectly. I should write, that I use GenPat in one of my projects. Once I copied it to the project directory and use it in older NSIS without problems (I suppose it used zlib from system directory). Now, in NSIS 3 we use special (I may be wrong) zlib library, so if it is not copied to GenPat/system directory it is not working.

Originally Posted by Anders View Post

It is after all just a label, even releases marked as stable can be buggy.

No, I don't care about the label, I just wanted to know if it was reasonably solid or not. Sounds like it's pretty solid. Thanks!

I'm chasing a posix bug and these logs are debug outputs of lang.cpp, LoadLangFile(). These are for the dev's benefit.

Hi all,
We are going to start using 3.0a2 in production.

Any new known/open issues?

Thanks

Originally Posted by toolbar510 View Post

Any new known/open issues?

I don't think there are any new bug reports but that does not mean it is safe to use 😉

The duplicate string bug was fixed after the current alpha but that is just a size bug.

It is passing our QA tests well - when do you plan on making it available outside of alpha?

Originally Posted by toolbar510 View Post

It is passing our QA tests well - when do you plan on making it available outside of alpha?

Kichik is pretty busy these days and there is a Posix bug that needs to be fixed first so I don't know...

Anders
Thank you very much for your work! Please take a look when it is possible, when compiling the latest source [r6459] in x64 error appears:

scons: *** [build\urelease\System\amd64-unicode\Source\Call-amd64.obj] Source `Contrib\System\Source\Call-amd64.sx' not found, needed by target `build\urelease\System\amd64-unicode\Source\Call-amd64.obj'.
scons: building terminated because of errors.

If I create a file Call-amd64.sx with contents

#include "Call-amd64.S"

I get an error:

cl: command line warning D9024: unrecognized source file type "Contrib\System\Source\Call-amd64.sx", object file assumed
cl: command line warning D9027: source file "Contrib\System\Source\Call-amd64.sx" ignored
cl: command line warning D9021: no action performed
LINK : fatal error LNK1181: cannot open input file "build\urelease\System\amd64-unicode\Source\Call-amd64.obj"
scons: *** [build\urelease\System\amd64-unicode\System.dll] Error 1181
scons: building terminated because of errors.

It's very important, because current x64 version from https://bitbucket.org/dgolub/nsis64 don't support System::Call, it makes impossible to complete the work of System plugin. Thank you!

The AMD64 support is not complete as you can see. It looks like a scons problem to me: "unrecognized source file type" ... "object file assumed" from CL should not happen because it needs to be compiled by ml64.exe when using the MS toolchain, not CL. I'm using a older version of scons because they keep breaking things and I know the one I have works. You have to read the documentation for the version you are using and find out what the correct file extension is... (I think .sx might be MinGW/GNU?)

It's works! I just compile object file manually and System:Call started working, thank you!

Originally Posted by systracer View Post

It's works! I just compile object file manually and System:Call started working, thank you!

That is not really a good long term solution, we should try to figure out which scons changes need to be made...

@Anders
In NSIS 3.0a1 thread, I wrote:
3. NSIS.exe application has a header image. It has a gap from the right side. Should be eliminated (title text bug is already reported)
http://www.meggamusic.co.uk/shup/137.../NSIS_Menu.png

You answered:

I made the dialog 2 pixels thinner, might not fix it 100% on your end, some font & dialog unit calculation is probably required to completely fix this (The gap is probably from wxWidgets changes, not something we did)

Newest, NSIS 3.0a2 still has the problem. Take a look:
In \Contrib\NSIS Menu\nsismenu\nsismenu.cpp, line 67:
#define HTMLW 598
After compilation there is still z gap: http://www.meggamusic.co.uk/shup/1398690318/GAP.png

But, when you change it, about 2 pixels:
#define HTMLW 596
The gap is now fixed: http://www.meggamusic.co.uk/shup/1398690385/No_GAP.png

Could you check it and eventually fix it?
-Pawel

3.0a2 has no gap on this system (Win8 with custom border size/padding probably). Someone that knows more about wxWidgets than me has to fix the code so that the client (inner) rectangle of the window is exactly HTMLW x HTMLH pixels. Maybe wxWindow::SetClientSize or calculate it with wxWindow::GetWindowBorderSize or wxWindow::ClientToWindowSize.

On my system (win8.1 x64) there is a gap (header image width size is 598px, so wxWindow should also be 598px (like it is in sources). However, on my machine it displays the gap... I hope someone can fix it, thanks Anders.
And, this is not a big deal, but if someone with wxwidgets skills could fix it would be nice.
-Pawel

Good day!

I found problem with WriteRegBin - for example if you write 50 bytes - all is ok, but if you write 100 or bigger bytes (200 symbols) - application will crash. This bug exists only for Unicode version (old or new), ANSI works perfect.

Thanks!

I cannot reproduce this.

Unicode true
!include LogicLib.nsh
Section
!define BINDATA "AA..snipped600more...BB"
#SetRegView 64
ClearErrors
WriteRegBin HKCU "Software\NSIS" "Test" "${BINDATA}"
${If} ${Errors}
DetailPrint Error
${Else}
DetailPrint OK
${EndIf}
StrLen $0 "${BINDATA}"
IntOp $1 $0 / 2
DetailPrint "BINDATA length is $0 ($1), NSIS(${NSIS_PACKEDVERSION}) char size is ${NSIS_CHAR_SIZE}"
!define /ifndef HKEY_CURRENT_USER 0x80000001
!define /ifndef KEY_QUERY_VALUE 0x0001
System::Call 'Advapi32::RegOpenKeyEx(i${HKEY_CURRENT_USER},t"Software\NSIS",p0,i${KEY_QUERY_VALUE},*p.r1)i.r0'
${If} $0 = 0
System::Call 'Advapi32::RegQueryValueEx(pr1,t"Test",p0,*i.r2,p0,*i.r3)i.r0'
DetailPrint "Error=$0 RegType=$2 Size=$3"
System::Call 'Advapi32::RegCloseKey(pr1)'
${EndIf}
SectionEnd

OK
BINDATA length is 600 (300), NSIS(0x03000021) char size is 2
Error=0 RegType=3 Size=300

Edit:
There was a overflow bug in the HEX data logging function when compiled with NSIS_CONFIG_LOG=yes and compiling as Unicode, fixed now.