Yathosho
1st June 2013 15:24 UTC

i'm getting the same problem with this simple script

; Settings ---------------------------------
OutFile "installer_name.exe"
RequestExecutionLevel user
Unicode true
!include LogicLib.nsh
!include WinVer.nsh
; Pages ------------------------------------
Page instfiles
; Sections ---------------------------------
Section "section_name"
        Quit
SectionEnd
; Functions --------------------------------
Function .onInit
        ${If} ${AtLeastWin2000}
                MessageBox MB_OK "${__LINE__}"
        ${EndIf}
FunctionEnd

jpderuiter
1st June 2013 15:58 UTC

As said in my previous post, I get a crash on your script with nsArray, which you are mixing with StrCpy.

For the Kernelbase.dll error:
http://answers.microsoft.com/en-us/w...c-51ed8d70f749

Afrow UK
1st June 2013 16:45 UTC

Working on the crash now. It appears to be coming from nsArray.

Originally posted by jpderuiter
I don't know nsArray, but are you allowed to use StrCpy with it (line 304, 310 and 314)?

Yathosho
1st June 2013 17:48 UTC

Originally posted by jpderuiter
As said in my previous post, I get a crash on your script with nsArray, which you are mixing with StrCpy

System::Call kernel32::GetVersionEx(pr0)i.r3

kichik
1st June 2013 18:07 UTC

The last example doesn't crash for me either. Can you maybe attach the compiled installer too?

jpderuiter
1st June 2013 19:21 UTC

...

jpderuiter
1st June 2013 19:40 UTC

Sorry, my crashes happen because I commented out onGUIInit, because I wanted to test it without parameters.

Yatosho, does your script crash when using /help as parameter?

Afrow UK
1st June 2013 19:52 UTC

Fixed the memory access violation in nsArray which occurred in the ForEachIn loop (nsArray::Iterate). I tested by running with /install and then running subsequent debugging executions with the default INI file as an argument. I don't get any crashes now.

Edit: I should mention the crash came about because an invalid array name is being used in your ForEachIn loop - it resulted in a NULL pointer in the plug-in and subsequent violation where validation was missing. This should not be an issue now.

Stu

Yathosho
2nd June 2013 11:07 UTC

Originally posted by jpderuiter
The last example doesn't crash for me either. Can you maybe attach the compiled installer too?

Yathosho
2nd June 2013 11:12 UTC

ok, i did some more testing as getting different results on different windows installations seemed strange. computer is virus free, so i renamed my old nsis directory (i installed nsis 3 over nsis 2) and did a clean install of 3.0a. now everything compiles and runs fine. still find it a bit weird (ANSI worked, WinVer seems to have caused this), but for me it's sorted. thanks for all advice.

bnicer
2nd June 2013 13:55 UTC

I had problem with an installer, where ANSI worked as opposed to UNICODE, that was caused by WinVer. The installer didn't crash, but the ${If} ${AtLeastWin'X'} conditions failed, UNICODE. Though, unlike in Yathosho's example, my script had a mistake. I was including WinVer.nsh before I declared Unicode true/false.

I thought of posting this earlier in response to Yathosho, but it didn't seem related. Maybe it is (worth looking into)? If the Unicode true declaration comes after an included file, a compiler error message would be in order, even though it's an avoidable mistake. I wonder as well if it should be necessary to declare Unicode when the script file is encoded in UNICODE. Make Unicode an optional command?

Anders
2nd June 2013 17:18 UTC

Thanks Yathosho and bnicer for tracking this down.

The compiler should abort if you use a plugin before switching unicode mode but WinVer does some size calculations when you include it and those are later passed to System::Call, I'll try to come up with a fix for this...

mariusnegrutiu
3rd June 2013 09:55 UTC

I'm trying to digitally sign the installer using the new !finalize command.
Everything works well as long as I don't use "%1" in the command line. If "%1" is used, makensis.exe crashes...

My code goes like this:
!finalize '"${__FILEDIR__}\SignTool.exe" sign /s MY_CERTSTORE /t "http://timestamp.globalsign.com/scripts/timstamp.dll" /d "Description" /du "http://www.blahblah.com" /v "%1"'

Btw, congratulations for reviving NSIS!

Anders
5th June 2013 20:35 UTC

WinVer should be a able to deal with switching modes now but it really is best if the unicode mode is set before files are !included

Originally posted by mariusnegrutiu
Everything works well as long as I don't use "%1" in the command line. If "%1" is used, makensis.exe crashes...

extremecarver
6th June 2013 19:49 UTC

Is there filesize >2GB support in 3.0a?
Or will it come with x64 branch?

Anders
6th June 2013 20:04 UTC

Originally posted by extremecarver
Is there filesize >2GB support in 3.0a?
Or will it come with x64 branch?

extremecarver
11th June 2013 14:33 UTC

thanks for the answer. Well then I hope it will be changed/enabled after x64 intregration sometimes. It would be much better than having the installer call external .zip/7z files (which on top can only be bzip/lzma and not lzma2) to unpack because they don't fit into the 2GB limit.

yoachan
14th June 2013 03:51 UTC

Just want to say thank you for everyone's work. :)

BTW can I use/install both NSIS 2 and NSIS 3 in one PC?
Would like my project to keep running and be able to test NSIS 3 to tell if I found a bug.
So amazing that NSIS 3 exist. Even NSIS 2 is already amaze me. :)

Anders
14th June 2013 08:02 UTC

Originally posted by yoachan
BTW can I use/install both NSIS 2 and NSIS 3 in one PC?
Would like my project to keep running and be able to test NSIS 3 to tell if I found a bug.
So amazing that NSIS 3 exist. Even NSIS 2 is already amaze me. :)

Yathosho
9th July 2013 10:28 UTC

are there plans to move the examples (and maybe includes) to the user space? on any modern windows version, the examples won't compile due to lack of privileges. just saying.

Anders
9th July 2013 13:10 UTC

Originally posted by Yathosho
are there plans to move the examples (and maybe includes) to the user space? on any modern windows version, the examples won't compile due to lack of privileges. just saying.

Yathosho
9th July 2013 13:44 UTC

Originally posted by Anders
Probably not, who would do the copy to $appdata, MakeNSISw?

Afrow UK
9th July 2013 14:36 UTC

Yes, on Windows 8 you have to run MakeNSISw as an administrator (even with UAC disabled) otherwise it cannot build the example scripts (cannot open output file). Your best bet is just to move the NSIS install directory and change the registry value (or install to AppData).

Stu

Anders
9th July 2013 14:58 UTC

Originally posted by Yathosho
the installer, of course!

Yathosho
9th July 2013 16:01 UTC

considering that nsis 3.0 is a new major release, i guess it's forgivable to demand a clean install from the user (or offer optional migration). then again, i don't see any harm in allowing both app data and program files, even at the same time (app data would override program files, and program files would serve as fallback.) as a side effect, that would allow different users using different nsis setups, though admittedly that's a small target audience.

one thing is clear: the current situation can be annoying. nobody wants to move scripts all the time or edit the outfile location. a compiler asking for elevation would be equally annoying.

also, must i remind you how often you have advised users to keep data and program files separate? :)

Anders
9th July 2013 16:13 UTC

Originally posted by Yathosho
also, must i remind you how often you have advised users to keep data and program files separate? :)