You are here

PA Launcher: Possible Bug

4 posts / 0 new
Last post
Gremlin
Offline
Last seen: 1 month 1 week ago
Joined: 2010-07-02 04:48
PA Launcher: Possible Bug

Hi,

I think I found a bug in the PA Launcher V2.0.

Description:
When you try to generate a portable app launcher you get the notification that the launcher was not generated. In the launcher generator's log file you get the following text in the last line:

Error in script "G:\WinBox\PortableApps.com\PortableApps.comLauncher\Other\Source\PortableApps.comLauncher.nsi" on line 54 -- aborting creation process

This happens when you choose a too long term with too much blanks in the term for the variable 'name' under section [Details] in App\AppInfo\appinfo.ini

An example:

While you get this error with

[Details]
Name=Application - My Own Application Portable

you do not get it with

[Details]
Name=Application - MyOwnApplication Portable

but it comes up again with

[Details]
Name=Application - My OwnApplicationA AA Portable

There was a discussion about it in this thread at that time referring to line 51 in the script.

Hope this helps.

Cheers

Gremlin

Chris Morgan
Chris Morgan's picture
Offline
Last seen: 9 years 5 months ago
Joined: 2007-04-15 21:08
Weird error

As mentioned in the old thread, that's a very confusing error message which doesn't really mean anything at all. Right through I have been entirely unable to come up with a logical explanation to the issue. First of all, are you using NSIS Portable (Unicode) 2.46?

A complete NSIS log would also be a lot more useful than just the single line as if there's any more helpful information it'll be earlier. To get it all you should also comment out line 23 of PortableApps.comLauncher.nsi - change !verbose 3 to ;!verbose 3 - so that you get all of what's happening.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

Gremlin
Offline
Last seen: 1 month 1 week ago
Joined: 2010-07-02 04:48
I am using NSIS Portable

I am using NSIS Portable (Unicode) 2.46 Rv2. A complete NSIS log can be found at PasteBin.

The weird thing is I tried it on 2 laptops and on one it would fail and on the other it would work. I have the PAL Launcher Generator and the NSIS Portable on an USB stick working from there. But it is not always the same laptop where it is working or not. It could be vice versa.

Chris Morgan
Chris Morgan's picture
Offline
Last seen: 9 years 5 months ago
Joined: 2007-04-15 21:08
OK

I've diagnosed what it is due to that, and it's definitely a bug (or quirk if you prefer) in NSIS. Here's my train of thought tracing it; I may be wrong in one or two points but I believe that I'm right in the essence of it:

  1. A definition is provided on the command line: Name=Application - My Own Application Portable
  2. NSIS definitions are case insensitive. This means that ${NAME} is equivalent to ${Name}, and both provide the value Application - My Own Application Portable.
  3. FileFunc.nsh is included. FileFunc.nsh includes Util.nsh.
  4. TextFunc.nsh is included. It includes FileFunc.nsh which detects it has already been included. Then TextFunc.nsh includes Util.nsh.
  5. Excerpt from Util.nsh (starting from line 10):
    !ifndef ___UTIL__NSH___
    !define ___UTIL__NSH___
    
    # see WinVer.nsh and *Func.nsh for usage examples
    !macro CallArtificialFunction NAME
      !ifndef __UNINSTALL__
        !define CallArtificialFunction_TYPE inst
      !else
        !define CallArtificialFunction_TYPE uninst
      !endif
      Call :.${NAME}${CallArtificialFunction_TYPE}
      !ifndef ${NAME}${CallArtificialFunction_TYPE}_DEFINED
        Goto ${NAME}${CallArtificialFunction_TYPE}_DONE
        !define ${NAME}${CallArtificialFunction_TYPE}_DEFINED
    

    __UTIL__NSH__ is defined. So the parser wanders forwards until it gets to an !else or an !endif. It finds the !else (wrong one) and goes on, parsing as it goes. It's missed the !macro, so at this point it doesn't realise it's inside a macro. Thus, instead of realising ${NAME} is a macro-scope definition... it looks for a global one. Which we have (otherwise it would just become a literal "${NAME}" and a warning would be showed at the end that it was not recognised and ignored). Uh oh...

  6. The tokenizer gets to the !ifdef line, line 21. ${NAME} gets expanded, so it has six parameters, but the tokenizer doesn't worry about that: !ifdef has * parameters, as you can combine checks with it like !ifdef THIS & THAT & THEOTHER & .... When it gets to actually parsing it, then it would complain about a syntax error if this code path really happened.
  7. It gets to the !define line. Now this becomes like this: !define Application - My Own Application Portable${CallArtificialFunction_TYPE}_DEFINED
  8. Eek! Tokenizer says there are six parameters in the !define, but the most allowed for !define is five parameters. Invalid, throw an error.
  9. What should happen instead is that it should go on past that and get to the !macroend on line 30 and realise it's got something a bit wrong and go back and sort out the !ifndef properly. The way NSIS handles its parsing of compiler lines is a bit weird in general.
  10. Normally the "what should happen" would happen because that !define line wouldn't go wrong. Normally Name has fewer arguments, so the !define only has five or fewer parameters when parsed incorrectly.

In the Inkscape installer I had a bit of trouble when the Windows build provider tried to generate the installer for 0.48pre1 (I think it was that release), where a certain code path ended up with !if..!endif muddling, because it missed ones in the middle. So I had to change the nesting of a couple of !if, !ifdef things to the other way round so that when the BZR_REVISION wasn't set it wouldn't get messed up. It took me quite a while to work that one out but I got it in the end.

As you can hopefully see, it's not my fault, except in that I didn't take care to avoid the glitch in the NSIS compiler by using a unique !define name.

One solution is to use a different variable - if I used PortableAppName instead of Name the problem would go away entirely. But it's still a bug in NSIS which I should report to them.

I've already had to deal with a vaguely similar issue in PAL to do with the way the parsing works; in the segments, I can use ${SegmentInit}, which has been defined in ${SegmentFile} to !macro FileName.nsh_Init, but when it gets to the end of the macro, I originally tried using a !define for ${SegmentEnd} to provide the !macroend, but that was no good because as far as the parser was concerned the ${SegmentEnd} is part of the macro, with definitions not to be parsed until the macro is included... That's why PAL has the vaguely not-neat ${SegmentInit} .. !macroend.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

Log in or register to post comments