This has been released.
The PortableApps.com Launcher is better than ever - now we're up to 2.1 Release Candidate 1 and the length of the release notes amazes me. Look at the 2.1 release notes to see what's new and what's changed.
Download the PortableApps.com Launcher 2.1 Release Candidate 1 [916KB download / 2.6MB installed]
(MD5: 98c430cb494f01498d40b40bd25fdc5a)
Release Notes:
- 2.1 Release Candidate 1 (2011-05-09): assorted miscellany, boot-polish and shoelace-tying. See hg log for more info.
- 2.1 Beta 2 (2010-12-03): various fixes and documentation and translation updates, also fixed Data to App move back when a handle is open (which was an issue with Opera). See hg log for more info.
- 2.1 Beta 1 (2010-10-02): no special release notes, see 2.1 release notes
Manual: development (will always contain the dev docs, as I update it whenever I update the manual - unfortunately the SourceForge hg server is restricted, a changegroup hook there failed to connect to my server to trigger the update). stable (currently 2.0).
App template: use Development Toolkit (it contains the current state of the template from which the standalone app template will be updated for the final release).
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I just used beta1 to make "IHMC CmapTools" portable - the new moving dir variables work perfectly, thanks!
I looking forward to 2.2: DLL registration/server support and I'm really hoping for a method of dealing with services and drivers.
Or at least, it doesn't fix the language switching problems with admin under Windows Vista/7.
I put it in in the hope it would fix that and an issue prapper was having, but as we tested it turned out it didn't fix the environment thing (but it did fix the other); I still need to think more about how we're best to solve that for 2.2. I've got a couple of ideas kicking around in my mind and I'll need to try them out.
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
Using XP 32-bit with Admin:
Setting 'ProgramExecutable64=Speccy\Speccy64.exe' makes Speccy Portable no longer run. I didn't do any debugging yet, but the splash screen shows then nothing happens.
I can't believe it. (Well, I can, actually.) I muddled the value of the IsWow64Process
Try this!
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
Alright, that works.
I know I have not been in active development of portable apps, and I have only just started using PAL this weekend. So please don't take this as a negative criticism, but more of a question/comment. With that said...
Would it be better to change the values of [Launch]:DirectoryMoveOK? Currently the changelog states that the values are "yes if it works or no if it doesn’t work at all". I am thinking it may be better to have the values as true|false, instead of yes|no for consistency.
Just my 2 cents, and thanks for all the hard work. I am looking forward to digging in and exploring what I can make portable with PAL.
Edit: I just noticed that there is a third possible value "warn" which happens to be the default. Possibly this is the reason for not going with true|false?
It amazes me that on the internet you can be anything you want, and yet so many people still choose to be idiots.
Indeed; when it's a tristate field I prefer not to have "not there" as a magic value.
And incidentally, I'm far more inclined to change true/false to yes/no than the other way round. CleanTEMP=yes, WaitForProgram=no... it makes more sense. I just don't feel like changing it right through at the moment (it would only be a programmer's-memory issue; the Generator can easily go through and update all trues and falses to yesses and noes, and there's value-error-checking in in this release for such values). For 2.2 or 2.3 I might change true/false to yes/no; I don't know yet.
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
I've released 2.1 Beta 2 now. This is what I plan on being 2.1, I just need the Data-to-App-moving-issue-when-a-handle-is-open fix verified (the one that was causing trouble with Opera losing the profile when a downloaded file was opened rather than saved and left open when Opera was closed).
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
Console and WAtomic both use PAL, so the manual can be updated to reflect that.
I've got them on my list... just haven't updated them yet. Thanks for remembering
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
How should we handle 64-bit apps where the 32-bit and 64-bit versions are in side-by-side but otherwise identical folders? (App\AppName\x86 and App\AppName\x64; both have the same file structure, same config file names, etc.)
Specifically, I'm looking at Double Commander. I'd like to package both the 32-bit and the 64-bit version, but I don't know how to handle the package so it automatically uses both the correct app version and provides the correct config files (since both the 32-bit and 64-bit versions appear to save settings to identical config files with the same names, but the 32-bit and 64-bit are in side-by-side folders so a simple file move is out)
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
topics/64-bit
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
That's what I see as being relevant in the manual, but I don't see how it really helps, unless I'm supposed to construct a custom environment variable for the path like the provided code block demonstrates. I was hoping for something a little more streamlined, so I could keep using standard PAL env vars.
If I end up creating a custom env var, I assume I'll need to use it for everything (FileWriteN, FilesMove, DirectoriesMove, etc.)?
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
We will only do 64bit if it is required (JkDefrag) for proper use on x64 Windows or if it has a very big performance increase (7-Zip = ~10%+) and no huge size increase. Details: https://portableapps.com/node/24371
Sometimes, the impossible can become possible, if you're awesome!
Thanks for pointing me to that thread. I'll leave 64-bit alone in the future unless it's necessary (e.g. Process Hacker or JkDefrag).
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
Once you've created the environment variable, you can use it in all of those sections with no extra bother. What's hard about that? All it ends up as is
%FullAppDir%instead of%PAL:AppDir%\AppName.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
It's not hard, just a bit more complex than a typical launcher, and something I can see myself looking at in 6 months and going "What did I do here and why??" It's not a big deal, just something I was wondering about.
Thanks!
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
Have you implemented clean-up for HKCU\Software\Trolltech\OrganizationDefaults\Qt\customColors yet? If not, were you going to do this for 2.1? If not, is it on your todo list? (Just keeping up with this, because Zint should be ready soon.)
For the moment, just do [RegistryKeys]:-=HKCU\Software\Trolltech\OrganizationDefaults\Qt\customColors (and gently prune the tree back to HKCU\Software).
I may also do a [Qt] section with customColors=ignore|clean|preserve (ignore being the default, clean being equivalent to -= above and preserve being equivalent to customColors=HKCU\... so that it actually saves the contents - perhaps some app somewhere actually uses the value?) which will also include the automatic pruning. I think I'll put that in 2.2. Got to sort out 2.1 first, though...
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
It one registry key really worth a whole new section?
But it also removes the pruning code.
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
Is it possible to keep it in QtKeysCleanup (or whatever it is)?
PAL 2.1 fails to build a launcher for Iron. The log file shows an error in the PushAs_ macro:
I took a look at the PushAs_ macro, especially the first line, and it looks ok.
PAL 2.0 didn't have any trouble with it, and I haven't upgraded my NSIS or anything but PAL.
Any suggestions?
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
Could you please post your custom code? Then I can try to track down what the problem is; it might be being triggered by one of these obscure !define + !macro definition bugs that I've come across.
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
The custom code is a bit complex, so I've uploaded it to Pastebin. The code itself isn't too bad, but there are enough macros calling macros in other files to make following it a bit hard.
PortableApps.comLauncherCustom.nsh
calls
PluginsEx.nsh
which calls
CallANSIPlugin.nsh
which is where the actual error is triggered, in macro PushAs_.
Thanks for taking a look!
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
I presume you meant Custom.nsh and have it all in App\AppInfo\Launcher, once you're dealing with PAL 2.1? I know you must have moved at least Custom.nsh, but you should put it all in this directory if you haven't already. Other\Source is a thing of the past. (You can also get rid of all ANSI NSIS support; PAL won't be using it ever.)
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
I forgot PAL renamed & moved PortableApps.comLauncherCustom.nsh for me. That's in App\AppInfo\Launcher, but the other files aren't. (Just for the record, I did try moving the other source files there, but that didn't fix the problem.)
Does that mean I should just delete Other\Source?
When I get a chance, I'll try removing ANSI support and see how that goes. I seem to recall something (Portable Passwords, most likely) needing it.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
Keep Other\Source, but all launcher stuff should be in App\AppInfo\Launcher. Other\Source is for launcher documentation for the user. Even if it doesn't fix it, once you get to deployment that's the way it should be.
I presume the rest is all just in the Iron package; I'll get it next week and poke around and see what I find.
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
I moved the other files to App\AppInfo\Launcher and tweaked Custom.nsh (it had a line using
${PACKAGE}\Other\Sourcewhich needed changing) to match. I'll keep it like that for the future.Yep, the other files are in the Iron package. You can just grab the official release.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
If you would compare the script use are currently using for the password plug-in to the one used in PAL, you'd see there is some quotes missing. PAL didn't mind due to the use of variables, but when I wrote your password plug-in script I came across this bug, so I added the quotes !
Formerly Gringoloco
Windows XP Pro sp3 x32
Should I just quote the Push and Pop strings, or should I be adopting all the changes in that CallANSIPlugin.nsh?
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
And now it's a couple of months ago I've seen this script
For the changes, ( As far as I can recall, ) it's just that I did find a cleaner way to handle the system calls. By making the system plug-in pushing / popping the stack directly, using the 's' command. I'm sure nothing dramatically did change.
Aswell I added some extra functions VarFromANSI/UTF8, which Iron P needs for the killproc plug-in.
So I guess do include all the changes, I'm sure it'll be fine. After all it has been fully tested by IronP by now
Formerly Gringoloco
Windows XP Pro sp3 x32
I copied CallANSIPlugin.nsh from Iron Portable to PAL and now the launcher builds properly. Thanks for the fix!
Do you think I should upload a development test so people get a chance to see if everything works correctly, or should I just send the build directly to John for release?
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
concerning CallANSIPlugin.nsh, I really believe it's fine, it is the script IronP used all this time. But is PAL 2.1 already being used officially? If yes send it to John and let him decide.
Formerly Gringoloco
Windows XP Pro sp3 x32
I don't think PAL 2.1 is being used officially yet, but Iron Portable needs the wildcard support for language switching. (Yes, that really is a bit messy, but so is the format of Iron's settings files.)
Like you suggested, I think I'll just send John the build and let him decide what to do with it.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
Are you sure you need the wild-card support, wild-card support only concerns files and folders, not values.
All I can find in your launcher.ini is :
I have to say, messy, yes, the launcher.ini surely looks quite odd. You're also passing the %PAL:LanguageCustom% variable in the commandline
edit: I had a very quick look into the Iron language settings, I really cannot see how the NewTestReplace plug-in could every handle a wild-card.
Why not write the language value to Data\settings\IronPortableSettings.ini and read it from there on start up, then pass it in the command-line. That should work
Formerly Gringoloco
Windows XP Pro sp3 x32
Good point about redundantly passing the lang value on the command-line. I'll have to drop that and rebuild the package.
I don't think I can write the language to %PAL:DataDir%\settings\IronPortableSettings.ini, since %PAL:LanguageCustom% doesn't change when Iron's language changes. The only way I could work that would be to read the language from Iron's settings file, and then of course I would have to write the language value to that file as well. That's exactly what I'm doing now.
I'd really love to drop the wildcard, but, given the complexity of the Iron settings-file format, I don't think I can successfully do that.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
PAL 2.1 Beta 2 is already being used in a few apps where it is needed. It's been demonstrated to be stable, really.
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
For easy build path of 64bit program, It's nice if launcher have a build-in variable like PAL:ArchSuffix (have value 64 when os is 64 bit, have value 32 or empty string when os is 32bit), so we will not need custom code when building path for 64 bit application.
I'm Trying to make a flash game portable so it copies its own flash cookie.
The problem is that the file in "C:\Documents and Settings\thstu\Application Data\Macromedia\Flash Player\#SharedObjects" is different on every computer.
I have tried (in [FilesMove]) "Settings\DinoRunSavedGame.sol=%APPDATA%\Macromedia\Flash Player\#SharedObjects\*\localhost" but it doesn't go into the folder, it puts it next to it.
I'm wondering if this could be fixed in the next release.
-Hello
That's a type of replacement which won't be being implemented. It would be ambiguous what should be done about it, anyway.
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
hi i wanted to change the splash screen to a custom splash screen png format but the launcher only supports jpg. how do i do that?
You'll need to convert it from PNG to JPG. It only supports JPGs. The plugin doesn't support alpha transparency, so a PNG would have no real advantage.
Sometimes, the impossible can become possible, if you're awesome!
I'd like people to just make sure this is working for them, translate it if you speak a language other than English, German and Slovenian, and then we can release it fairly promptly. Unless there are bugs, I don't expect to make any changes other than with the translations between this and 2.1 final and removing the "UNDER DEVELOPMENT" label on the release notes.
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