NSIS 2.37 Portable Development Test 3

*sings* 'You've made me so... very happy'.

Anywho, I think this is Simeon's job, but my registry is all good on an admin account.

Now the Very Pick PAF Stuff.

• Add your copyright in the \Other\Source\Readme.txt, and the launcher number is wrong.
• Wow, that's a lot of pre-install code, is that to accomodate for SmithTech's NSIS Portable, too? Also, line 2.11 show's an update for 4.57, which is 7-Zip, but I'll let it slide. :P
• Looks like the splash still fades in, which seems gone for good now, line 184 - 200 to 0.
• In App\AppInfo, I think it's appicon.ico, and then appicon1.ico would precede. Double check OpenOffice.org Portable on that.
• Missed a period at the end of the Description line the the AppInfo.ini. :P *hides form Zach*

All else looks good, great work, and thanks.

I like the full package but I use the ini to launch makensis.exe cause I'm used to it :)
It leaves nothing if I make a clean install. But if I upgrade from Smithtech's version, it leaves HKEY_CURRENT_USER\Software\NSIS behind. I dunno why. Win XP - restricted account.

that it leaves HKCU/Software/NSIS behind and Zach said :"I took care of that".
At first I though that would be due to my updating from Smithtechs version but then I figured out that it wasn't because of that.
I closed the main program and only kept the makensis.exe open because I only needed the makensis. But closing the main program resulted in the launcher closing and cleaning everything. But the makensis.exe is still open and able to write to the registry. So I think that's the problem for the left keys.
So I think it would be good if the launcher would only close if al the programs that can be started by the main program (makensis.exe and the converter) are closed. Should be easy in NSIS.

Looking forward to DevTest3 :)

I got my website blocked by my school. :P

FTP it is.

Updated internal version of NSIS to 2.36

I have a good solution to this...one that I may use for my default install as well. There are two compiler commands

!addincludedir
!addplugindir

These give the compiler additional search locations for for includes and plugins. If these commands are placed in the 'nsisconf.nsh' file located in the NSIS root directory, then they are compiled with every script. Relative paths are funny with this file, so use fully qualified paths relative to the NSIS base directory -

!addincludedir "${NSISDIR}\..\..\Data\Include"
!addplugindir "${NSISDIR}\..\..\Data\Plugins"

This should keep everything nice and separate, and intact during upgrades :)

Updated to 2.36 Dev Test 2

Updated to Dev Test 3, see main post for details.

Everything's clean, as found by previous testers.

There's a topic about nsExec in this post. It would be handy if your script would use ExecDos and if the installer would include it in DefaultData\plugins. Also, the Apps\NSIS\Menu\index.html can replace the nsExec line with:

<a href="EX:Docs\ExecDos\Readme.txt">ExecDos</a> - launch command line tools<br>

(in alphabetical order, of course. :-))

You could also consider an INI option ItemsToLaunch=N, where N is a combination of: 1=menu, 2=compiler, 4=zip2exe, 8=manual, etc. (e.g., compiler + manual = 2 + 8 = 10).

        ReadINIStr $0 "$INIPATH\${NAME}.ini" "${NAME}" "ItemsToLaunch"
        StrCpy "$ITEMSTOLAUNCH" $0
; ...
    LaunchNow:
        Sleep 100
        SetOutPath "$EXEDIR\App\NSIS"

        ; $ITEMSTOLAUNCH default behavior = 1 (menu)
        ; if set to 8 (manual only), do 9 (menu + manual)
;   LaunchItem8:    
        IntOp $0 $ITEMSTOLAUNCH & 8
        StrCmp $0 "0" LaunchItem4                   ; is bit 8 set?
            IntOp $ITEMSTOLAUNCH $ITEMSTOLAUNCH ^ 8 ; ... yes, unset it
            ExecShell open "${MANUALCHM}"           ; can't wait on Shell Open
    LaunchItem4:
        IntOp $0 $ITEMSTOLAUNCH & 4
        StrCmp $0 "0" LaunchItem2                   ; is bit 4 set?
            IntOp $ITEMSTOLAUNCH $ITEMSTOLAUNCH ^ 4 ; ... yes, unset it
            StrCmp $ITEMSTOLAUNCH "0" 0 +3          ; any other launch bits set?
                ExecWait "${ZIP2EXE}"               ; ... no, this was last one
                Goto CheckRunning
            Exec "${ZIP2EXE}"                       ; ... yes, there's more
    LaunchItem2:
        IntOp $0 $ITEMSTOLAUNCH & 2
        StrCmp $0 "0" LaunchItem1                   ; is bit 2 set?
            IntOp $ITEMSTOLAUNCH $ITEMSTOLAUNCH ^ 2 ; ... yes, unset it
            StrCmp $ITEMSTOLAUNCH "0" 0 +3          ; any other launch bits set?
                ExecWait "${COMPILEREXE}"           ; ... no, this was last one
                Goto CheckRunning
            Exec "${COMPILEREXE}"                   ; ... yes, there's more
    LaunchItem1:
        ExecWait "${DEFAULTEXE}"                    ; no need to check (you made it this far)
        
    CheckRunning:

I compiled and tested this code with various values of ItemsToLaunch (including none at all), and they all worked. N.B. AdditionalParameters entry is ignored (which item would you apply them to?). Note that the SaveRegKey label isn't used, so it should be commented out like LaunchItem8 above. Also, CopyDefaultIndlucdes has an interesting spelling. :P

And, this topic addresses the buggy-yet-it's-always-been-that-way-so-it's-not-a-bug INI file handling in current launchers. With the suggested changes, a user's NSISPortable.ini could look like this:

[NSISPortable]
DisableSplashScreen=false
# 1=menu, 2=compiler, 4=zip2exe, 8=manual (e.g., compiler + manual = 2 + 8 = 10)
ItemsToLaunch=10

Overall, an excellent project almost ready for release.

-hea

I can make PortableApps easily thanks to NSIS Portable, but it has a kind of bug.

It works perfect on my desktop (Pentium IV 1,7GHz, 768MB RAM, 80GB HDD), but it stuck every time I trying to build PortableInstaller on my laptop (AMD Sempron 3200+ 2GHz, 512MB RAM, 80GB HDD).

This is weird, because it works on my desktop, but on laptop it doesn't. It take about 100% CPU usage and block hole computer. PortableInstaller is growing up about 1MB per 30min. All in all I have to kill NSIS processes cause it blocks my computer. Sometime changing 'lzma' compression to zip helps.

Does anyone experience such problems?