[Outdated] PortableApps.com Launcher 1.0 Alpha 4

Thanks for pointing that out with RunLocally; I hadn't noticed it wasn't in an If block. I'll have to actually look at the code for longer than 5 seconds next time.

I'm working on REAL Studio again; it's got a toolbar button that launches the REAL Studio Feedback app. Of course, I can't let the non-portable feedback.exe handle that - FeedbackPortable.exe, on the other hand, both can & should handle that.

On a side note, how can I set a Registry key's default value? REAL Studio gets the path to the Feedback app from HKEY_CLASSES_ROOT\feedback\shell\open\command\(Default value); I've tried about a dozen ways of putting the right path in, but none of them has worked; I always end up with a value named "command" under the Open key.

Oh, that makes much more sense. Thanks for the explanation!
I'm using [RegistryValueBackupDelete] with [RegistryValueWrite] for HKEY_CLASSES_ROOT\feedback now, but that's not working correctly either - when HKEY_CLASSES_ROOT\feedback doesn't exist, it's apparently backed up anyway. "Restoring", or deleting it, never takes place, so HKCR\feedback gets left behind.

EDIT: ok, it looks like [RegistryValueBackupDelete] entirely ignores Registry keys and only backs up Registry values. I'd like to request that as a new feature, since having to use [RegistryKeys] with a bunch of temp values is pretty darn ugly.

Unfortunately, [RegistryKeys] doesn't clean up properly either - HKCR\feedback is still being left behind, probably because the Registry keys don't exist before running the launcher.

The PortableApps.com Launcher files are not yet in the PortableApps.com Format specification.

From the PAF 1.0 spec: "[AppInfo] may also contain the launcher.ini configuration file used for the PortableApps.com Launcher."

In any case, now that I've had time to reflect, I think my main beef with it is the subfolder being called just "Launcher". Like you, I'm a perfectionist, and I think naming it "LauncherData" or something similar and moving it up to App\, like in CPAL, would make its intent clearer. I don't like to read any more documentation than I have to, so I tend to prefer a system that's as self-documenting as possible.

I was confused with C !

But 'How to Read REG_MULTI_SZ Values', in the NSIS usermanual (appendix D.5) is dealing with reading NULL separated, double NULL terminated strings.

I got some experience with the writing of these strings as well. Since I wrote a code to do this, for Unicode NSIS Portable (I think, DT2).

Do you have to WRITE or READ the string???

[edit: just hold on, I'm making a script what probably suits your needs]

ReadNullString : just copied over from the NSIS usersmanual (zlib license)
WriteNullString : a piece of code I just wrote yesterday

There could be a few (slightly) different approaches to handling the null byte,
It would be helpful if I know the code your actually trying to use this in. So I could make it as sufficient(=faster) as possible.

Ps.: The whole trick is using the handles instead of variables containing the string, so the null byte does not vanishes every time.
The actual writing of the NULL : System::Call "*$2(&i1 0)"
where :
$2 = the location
&i1 = amount of bytes to write. i=integer
0 = the actual value to write, so this could be your delimiter as well.
The location is calculated by : HANDLE + StrLen = $2
So in theory we could make a much faster script for handling this.

Other approaches could be:

1. to write each string one by one so a null byte gets added automatically, then move the location up one position before to write the next string to the handle.
   Using: System::Call "*$2(&t$3 r4)"
   &t$3 = amount of chars to write. t=text/TCHAR
   r4 = $4, the actual string to write
   Then finish by writing the terminating null
2. or, probably it would be possible and potentially much easier and faster, to write the string as a REG_MULTI_SZ value using the registry plugin, then to get a handle to it by reading this value using the system plugin.
   System::Call "${RegQueryValueEx}....."
   This solution could rule out any Unicode NSIS issues.