changed command line behaviour for makensisw in v.2.25?

Hi,

i compile my scripts by batch file. I use the following code:

start ..\..\NSISCompiler\makensisw.exe /DSOME_DEFINE scriptfile.nsi

Unfortunately the doesn't work anymore in 2.25. It seems to me that makensisw treats every parameter as a filename as therefor fails to open /DSOME_DEFINE.

Can anyone confirm?

Regards

Flizebogen

Try:
start "..\..\NSISCompiler\makensisw.exe" "/DSOME_DEFINE scriptfile.nsi"

Stu

No that gives only a different error message. This time provided by makensis and not the wrapper

cmdline behaviour hasnt changed, just tested, works fine for me.

problem on first post:
the /D switch is interpreted by the "start" command itself, so it won't work. type "start /?" in your cmdline and read 🙂

problem on the second post:
afrows solution is right, but you should not call "makensisw.exe" but "makensis.exe"
makensisw is just a GUI wrapper for the makensis cmdline compiler.

when using start and quoted paths on NT, you need to provide a title aswell (very stupid move by MS)

try: start "" "..\..\NSISCompiler\makensis.exe" /DSOME_DEFINE scriptfile.nsi

I tested it on a second XP machine and the problem is there too.

There are various reasons for using makensisw instead of the compiler itself.

- Log of compilation is cut off in ms-dos box
- possibility to recompile

I used the start command to immediate close the dos box.

@anders

Yes the online help for start says the first parameter should be the title but the command is also executed if the title is missing.

@ Afrow UK

If i quote everything than i'm forced to add a title for the "start" command. But this still doesn't work. The error message i get is:

Command line defined: "SOMEDEFINE scriptname.nsi" 

If i drop the "start" command and call makensisw directly without quoting i get the following message:

MakeNSIS v2.25 - Copyright 1995-2007 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.
Can't open script "/DSOMEDEFINE" 

If i change the call to makensis.exe then it compiles fine regardless of the not set Title for the "start" command. It also compiles fine if i use the makensisw.exe (v.2.2) from nsis 2.24.

For me this is the prove that makensisw parameter handling is buggy /differs from makensisw.exe v.2.2

Command line handling has changed for MakeNSISw v2.3. It passes `--` to escape the script name now that makensis supports both dash and slash as the switch escape code. Please open a bug report for it.

"v2.3" ? possibly since v2.23?

No

Makensisw.exe v.2.3 is shipped with nsis 2.25
Makensisw.exe v.2.2 is shipped with nsis 2.24

Ah, sorry plus the "w", I never see and use, I need to put of my 😎

strange, I have a similar problem with MakeNSISw (Release 2.30)

This doesn't work

start "" "%NSISDIR%\makensisw.exe" /DABCDEFGHIJKLMNOPQ=1 /DABCDEFGHI=2 Update.nsi



MakeNSIS v2.30 - Copyright 1995-2007 Contributors

See the file COPYING for license details.

Credits can be found in the Users Manual.



Processing config: 

Processing plugin dlls: "C:\Program Files\NSIS\Plugins\*.dll"

...

But this works: (ABCDEFGH instead of ABCDEFGHI)

start "" "%NSISDIR%\makensisw.exe" /DABCDEFGHIJKLMNOPQ=1 /DABCDEFGH=2 Update.nsi



MakeNSIS v2.30 - Copyright 1995-2007 Contributors

See the file COPYING for license details.

Credits can be found in the Users Manual.



Command line defined: "ABCDEFGHIJKLMNOPQ=1"

Command line defined: "ABCDEFGH=2"

Processing config: 

Processing plugin dlls: "C:\Program Files\NSIS\Plugins\*.dll"

...

Seems like a buffer limit to the optional arguments ?

This does not happen if I call makensis.exe directly..
Any idea ?

Both scripts work fine for me. I can't reproduce.

I tracked the bug down to this:
The following WORKS:

SET Path=C:\123456789

"C:\Program Files\NSIS\makensisw.exe" -D12345678901234567890123456789012345 -DBUG Test.nsi

The following DOESN'T WORK: (one char LESS in argument)

SET Path=C:\123456789

"C:\Program Files\NSIS\makensisw.exe" -D1234567890123456789012345678901234 -DBUG Test.nsi

So just having a char LESS as parameter make it work !

(The link with "start" was that "start" seems to add an additionnal space on the command-line before the first argument)

There seems to be something also with the PATH variable length because if you SET Path=C:\12345678 it seems to work

In my opinion there must be a problem in MakeNSISw argument parser

as it seems to be dependent on the PATH variable length and the argument length, I'm guessing a buffer overflow bug, with a '\0' a bit too far that erase the parsed defines (-D)

Both still work for me.

What can I do to track the bug further and provide more information ?
I don't see what could be wrong in my machine configuration that is causing this, but it is really annoying

Create a better model for the issue. Does it happen with makensis.exe? If environment variables seem to affect, clear them all and add some until it happens. Delete all files but makensis.exe and makensisw.exe and the stubs and see if it depends on other files. Etc...

I was able to reproduce the problem while debugging MakeNSISw inside Visual Studio, and tracking down the problem through assembly-code... !

So from what I can see, when passing 2 arguments like this:

SET Path=C:\123456789

"C:\Program Files\NSIS\makensisw.exe" -D1234567890123456789012345678901234 -DBUG Test.nsi

the second time GlobalReAlloc is called (inside AddScriptCmdArgs), it fails (returns 0) with ERROR_NOT_ENOUGH_MEMORY

I have no idea why reallocating to 30 bytes fails however... probably the global heap is not correctly initialized

found the problem in MakeNSISw !

char *args = (char *) GlobalLock(g_sdata.script_cmd_args);

...

GlobalUnlock(args);

it should be

char *args = (char *) GlobalLock(g_sdata.script_cmd_args);

...

GlobalUnlock(g_sdata.script_cmd_args);

otherwise the HGLOBAL is not correctly unlocked and the memory block can only be reallocated in-place (which sometimes is not possible => ERROR_NOT_ENOUGH_MEMORY)

can you fix this ?

Please submit the details as a bug report, or even a patch if you have one and I'll look thoroughly into it tomorrow.

done

Yes, I remember seeing this bug while going through my changes. The bug is in utils.cpp in Contrib/Makensisw, in the function CompileNSISScript(). The GlobalAlloc size does not account for the " -- " in the command line. My source code changes for Unicode support fixes this problem both in the ANSI and Unicode version.

http://www.scratchpaper.com/nsis-05-....csv-setup.exe (ANSI)
http://www.scratchpaper.com/nsis-05-...code-setup.exe (Unicode)

Please look at the thread on "Unicode" for more information about these builds.

note that jimpark points out a bug different than mine, but also linked to command-line parameters.
(mine is in function AddScriptCmdArgs)

jimpark you should add the description for your bug to my bug report or create a new bug report, for tracking purpose