[Outdated] PortableApps.com Launcher 1.0 Beta 1

This looks really great! I'm going to go upgrade some apps & try it out.

Just a couple of minor things:
* The font used for file names, settings, etc. is very, very hard to read; the gray rectangle around the file names, settings, etc. makes it even harder.
* There's a couple of unnecessary files with PAL: App\Manual\html\objects.inv, App\Manual\html\.buildinfo, App\AppInfo\.appinfo.ini.swp, App\SampleLauncher\.AudacityPortable.ini.swp, App\SampleLauncher\.ScribusPortable.ini.swp, Other\Source\.Segments.nsh.swp, and a lot of .swp files in Other\Source\Segments.

[FilesMove] is pretty badly broken; I'm working on TurboRisk, which stores its settings in its folder, and PAL is having big trouble.

Somehow, the entire path is getting used for the save info; I'm going to probe PAL and see if I can find out just what's going on.
nvm >

Just a question:
Is service handling enabled in this version, or is it still disabled?

As I found a version of NewServiceLib.nsh in the Development repository,
date: Thu Feb 04 16:32:24 2010
NewServiceLib.nsh: http://portableapps.hg.sourceforge.net/hgweb/portableapps/launcher/file/...

I updated the example script I wrote the other day, and made some modifications for safety, speed, Unicode NSIS and added the push & pop's.
NullByte.nsh: http://pastebin.com/Q7qCbhez
Although I tested it thoroughly, I couldn't really test it in combination with NewServiceLib.nsh, but I believe it should be able to do what you need in this script.
Probable implementation in NewServiceLib.nsh :

		; $6: Dependencies {{{2
		${GetOptions} `${_Parameters}` `/dependencies=` $6
		; TODO: decide whether this is actually possible or not. Dependencies must be null-separated, but 
		${WriteNullString} $HANDLE "$6"
		${If} $6 == ""
			StrCpy $6 n
		${Else}
			StrCpy $6 `i $HANDLE` ;'t' is replaced by an 'i'
		${EndIf}

Feel free to make modifications to NullByte.nsh yourself and let me know if you have any issues with it.

Do you have any good idea for the language switching jet ?

Myself I was wondering if it would be possible to implement a 'Locale.ini' within the 'appinfo' folder.
PAL could translate for example the '%PortableApps.comLocaleWinName%' through this .ini file to some new environment variable containing one of the .ini values.
This way the value could suit the needs for the specific app better.

As an example, I made an .ini file I could use for MP3Gain Portable.
http://pastebin.com/kwy6Rh34

For this case, PAL should be able to write this value, containing the language filename, to the MP3Gain .reg file as an .ini value. Or as a REG_SZ value to the registry.

I've found a somewhat-troublesome typo in Mutex.nsh:
${IfNot} $0 = 0

I might have my NSIS all screwed up, but doesn't that always fail? It assigns 0 to $0, then the ${IfNot} test fails. I think the code should be
${IfNot} $0 == 0, which compares $0 to 0.

But Revo Uninstaller Portable still won't work. Not sure if it's a problem on my end or with the launcher, but here's the launcher.ini:

[Launch]
ProgramExecutable=RevoUninstaller\revouninstaller.exe
RunAsAdmin=try
SingleAppInstance=true

[FilesMove]
settings\settings.ini=%PAL:APPDIR%\RevoUninstaller

; Details of the launcher.ini format are available in the PortableApps.com
; Launcher package. (You should not leave this comment in.)

However, this time the splash screen loads and then nothing else happens.

I always have a NSIS-plugin-like folder (ie the name is changing) with the launcher.ini file being left inside my temp folder.

Besides that I haven't been able to get Apps to start properly but I guess I have to become familiar with the new layout and such.

i used the registryvaluewrite to write a hklm string to the reg but it doesn't work and tried it several times.

and does the beta support the windir now?

The following .ini line...

[RegistryKeys]
PDF-XChangeViewerPortable2=HKEY_LOCAL_MACHINE\SOFTWARE\Tracker Software\PDFViewer

Get this debug message..

Saving registry HKLME\Software\Tracker Softrware\PDFViewer.....

With some investigation, I think I found the bug in segment Registry.nsh line 39 of ...

			StrCpy $0 $0 "" 17

Should be...

			StrCpy $0 $0 "" 18

HKEY_LOCAL_MACHINE is a letter longer then
HKEY_CURRENT_USER, but both are set to 17 letters!

But as well if I try to use in the short way...

PDF-XChangeViewerPortable2=HKLM\SOFTWARE\Tracker Software\PDFViewer

I get this debug message...

registry hive in key "HKLM\SOFTWARE\Tracker Software\PDFViewer" is bad,
should start with HKCR, HKCU or HKLM....

But besides this debug message, PAL does handle the backup, restore, etc. as it should.
I'm using the latest updates from the Development repository !

BTW: When PAL has to handle 2 main keys, like a HKLM & HKCU, is there any way for PAL to save them into one .reg file !
For now when I try to use the same .reg file twice, the first saved key gets deleted from this .reg file:

[RegistryKeys]
PDF-XChangeViewerPortable=HKEY_CURRENT_USER\Software\Tracker Software\PDFViewer
PDF-XChangeViewerPortable=HKLM\SOFTWARE\Tracker Software\PDFViewer

The solution prapper used for now is to give the second one a different name, but this way PAL won't be compatible with old launchers.
Maybe implement the following for any extra key to be handled

${registry::SaveKey} "[fullpath]" "[file]" "/A=1" $var ; the A for append

As we still have some folks using the older 1.0 release of the PA.c Platform as well as a couple of forks of based off it and will until 2.0 with categories and other features debuts, I was thinking perhaps that we could setup the current launcher with the ability to take the name of the current app as well, so it will show up properly for these users of legacy menus that don't use PA.c Format.

Specifically, lines 38 and on become:

;=== Program Details {{{1
!verbose 3
!macro !echo msg
	!verbose push
	!verbose 4
	!echo "${msg}"
	!verbose pop
!macroend
!define !echo "!insertmacro !echo"
${!echo} "Specifying program details and setting options..."
!searchparse /noerrors /file ..\..\App\AppInfo\appinfo.ini "PackageVersion=" VER
!ifndef VER
	!define VER 1.0.0.0
	!warning "Unable to get version number from appinfo.ini; it should have a line PackageVersion=X.X.X.X in it. Used value 1.0.0.0 instead."
!endif
!searchparse /noerrors /file ..\..\App\AppInfo\appinfo.ini "Name=" LauncherName
!ifndef LauncherName
	!define LauncherName "PortableApps.com Launcher"
	!warning "Unable to get name from appinfo.ini; it should have a line Name=AppName Portable in it."
!endif
!searchparse /noerrors /file ..\..\App\AppInfo\appinfo.ini "AppID=" LauncherEXEName
!ifndef LauncherEXEName
	!define LauncherEXEName "PortableApps.comLauncher"
	!warning "Unable to get AppID from appinfo.ini; it should have a line AppID=AppNamePortable in it."
!endif

Name "${LauncherName}"
OutFile "..\..\${LauncherEXEName}.exe"
Caption "${LauncherName}"
VIProductVersion ${VER}
VIAddVersionKey ProductName "${LauncherName}"
VIAddVersionKey Comments "A universal launcher for PortableApps.com applications, allowing applications to be run from a removable drive.  For additional details, visit PortableApps.com"
VIAddVersionKey CompanyName PortableApps.com
VIAddVersionKey LegalCopyright PortableApps.com
VIAddVersionKey FileDescription "${LauncherName}"
VIAddVersionKey FileVersion ${VER}
VIAddVersionKey ProductVersion ${VER}
VIAddVersionKey InternalName "${LauncherName}"
VIAddVersionKey LegalTrademarks "PortableApps.com is a Trademark of Rare Ideas, LLC."
VIAddVersionKey OriginalFilename "${LauncherEXEName}.exe"
!undef LauncherEXEName
!undef LauncherName
!undef VER

This will pick up the App's name from the Name= line and the AppID from AppID= (for constructing the launcher EXE name). Once we have folks moving towards 2.0 we can then drop this extra work and just use the PA.c Launcher as is for all apps (no custom icon or name). Thoughts?

Line 10 of SplashScreen.nsh should be:

newadvsplash::show /NOUNLOAD 1500 0 0 -1 /L $EXEDIR\App\AppInfo\Launcher\splash.jpg

We don't fade splash screens anymore. And I thought we were gonna add an option to the launcher.ini to allow custom timings (for bigger apps that take longer).

ForEachINIPair.nsh is leaving an open handle on the launcher.ini file. To fix this, line 65 of it must be uncommented and a new line added after it:

	FileClose $_FEIP_FileHandle
	StrCpy $_FEIP_FileHandle ""

That properly closes the handle and lets the procedure know it isn't open by clearing the variable.

I can't recall where we were with Unicode files. I know GringoLoco did his ReplaceInFileWithUnicodev3.nsh that I'm using in uTorrent now. It's slower than the TextReplace plugin, but it does work on UTF-16 files. I'm working on Mixxx for the PA.c Music Suite and it uses UTF-16 files, so the PA.c launcher can't replace strings in them.

!insertmacro: ReadLauncherConfig
!insertmacro: macro "ReadLauncherConfig" requires 3 parameter(s), passed 2!
Error in macro Language_Init on macroline 33
Error in macro RunSegment on macroline 10
Error in script "H:\PortableApps\Mercurial\launcher\Other\Source\PortableApps.comLauncher.nsi" on line 235 -- aborting creation process

In 'Segments\Language.nsh', line 52:

${ReadLauncherConfig} $1 DefaultIfNotExists

Should probably be..:

${ReadLauncherConfig} $1 Langauge DefaultIfNotExists

At least it compiles after this !

I was just reading the logs, and realize things are speeding up for Unicode NSIS !

We are really going to have to test the plug-ins properly for PAL & InstallerU first in development tests. As I really can not guarantee that there aren't any bugs.

A few issues to keep in mind, already:

• NsisUnzU is the old, potentially unstable, zlib, version 1.1.3. As I was experiencing major difficulties compiling with the newest version. Could fix that though if really necessary?
• Another issue with NsisUnzU is that it can't handle foreign characters within the extraction/ZIP-file path !
• It would probably be preferable to do away with the NsisUnz plug-in and just use 7z.exe, if possible ?
• The RegistryU plugin, although I tested it well, it was a real makeover to get it to work in Unicode NSIS.
• NewTextReplace.nsh should really have credits to Instructor's original textreplace plugin, as that's what it's based on. It does have the credits in the read.me & source but I must have forgotten in the .nsh
• Unicode NSIS is just up to version 2.45 for now, and we are totally depended on JimPark to update this 'regularly' !
• Another note is that Unicode NSIS converts the original ANSI scripts as UTF-8, which isn't a major problem cause the scripts just make use of ordinary Latin characters,
  but for some special characters it doesn't convert flawless, like for the '®' the script needs the following lines:

  !ifdef NSIS_UNICODE
  BrandingText "PortableApps.com - Your Digital Life, Anywhere®" ;UTF-8
  !else
  BrandingText "PortableApps.com - Your Digital Life, Anywhere®" ;ANSI
  !endif
  

For any replies please contact me on the Unicode NSIS Development forum topic.

[edit: and the languages in InstallerU need to be looked-over/re-done, as I can't guarantee I converted them well enough!]