This thread is outdated. Next version: 2.0 Beta 2
The PortableApps.com Launcher is your PAL in making applications portable. It's a universal launcher for which you don't need to write code. Instead, it's configured with an INI file (which goes in App\AppInfo\Launcher\AppNamePortable.ini), and uses a splash screen in App\AppInfo\Launcher\splash.jpg.
Download the PortableApps.com Launcher 1.0 Beta 1 [555KB download / 1.2MB installed]
(MD5: 065746e45a74a81bffda6f7d43bf3421)
Download the PortableApps.com Application Template 1.0 Beta 1 [115KB download / 195KB extracted]
(MD5: 31b9ae00784100a995ffd6d19e95f2f2)
(If you get the second package you don't need the first unless you want to see the PortableApps.com Launcher source code; the manual is available online, see below.)
Links:
- Current documentation (included as help.html; the most complete documentation)
- Using the PortableApps.com Launcher (from the Alpha thread, file names mentioned are now outdated).
- New manual (included in App\Docs; far from complete).
- Development repository
Release Notes:
- 1.0 Beta 1 (2010-03-16): improvements, bug-fixes and some changes in launcher.ini format and locations where things go (see comments in the Alpha thread or help.html).
Discussion, notification of some changes and earlier release notes are available in the alpha thread.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
This is now becoming fairly stable. It should be able to cope fairly well with things like pulling the disk out while the application is running. I'm aiming to have very few launcher INI file format changes or things like that before 1.0 final.
A template package is just coming now.
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 is its memory usage?
You'd have to try it. It's (significantly) lower than existing PortableApps.com launchers though due to the EmptyWorkingSet call in "strategic locations" as marketing agents might put it. Something like 800KB instead of 6MB while just sitting there waiting and not doing anything.
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 just uploaded my Application Template; this is a skeleton for PAL-based apps. I've designed it so that the Other directory can be left alone, you should only need to touch help.html and things in App.
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
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.
"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 speaking of help.html or the new docs?
Sorry about the Vim swap files... I'm deciding they're a bit of a nuisance so I think I'm going to turn them off again so this can't happen.
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'm talking about the new docs; help.html is perfectly readable.
The Vim swap files aren't a big deal; it's just a cosmetic thing I thought you might want to know about.
Cheers!
"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."
Ah yes, I see what you mean. Somewhere along the line I changed it from what it was earlier. Yet another of those things which I didn't notice because Ubuntu has a far better monospace font than Windows.
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
[FilesMove] is pretty badly broken; I'm working on TurboRisk, which stores its settings in its folder, and PAL is having big trouble.* It doesn't seem to detect an existing TurboRisk.ini, so it never backs it up
* After TurboRisk exits, here's what PAL is doing (per the debug message): "Copying file from D:\DOCS\Programming\PAF\TurboRisk\TurboRisk (2)\Copy of TurboRisk Portable\App\TurboRisk.ini to D:\DOCS\Programming\PAF\TurboRisk\TurboRisk (2)\Copy of TurboRisk Portable\Data\D:\DOCS\Programming\PAF\TurboRisk\TurboRisk (2)\Copy of TurboRisk Portable\Data\TurboRisk.ini"
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 >
"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."
Just a question:
Is service handling enabled in this version, or is it still disabled?
"Der Klügere gibt nach, deshalb regieren Dumme die Welt."
I'm looking at putting them back in with NSIS code rather than a plug-in soon. If you want to use services though, uncomment the
!define SERVICES_ENABLEDline in Other\Source\Segments\Services.nsh and recompile Other\Source\PortableApps.comLauncher.nsi and you'll have services.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
We've decided to renumber this from 1.0 to 2.0 due to the fact that previous launchers were labelled "PortableApps.com Launchers" with version number 1.6-1.7. So to avoid any confusion in going backwards this universal one is becoming 2.0.
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
Translators can now post translations in this Localization Discussion forum post.
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
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.
Formerly Gringoloco
Windows XP Pro sp3 x32
That's what I was going to do with it
(I knew that I could access my NewServiceLib and put it back in due to version control. Useful.)
I'll see if I can test it some time next week in my VM, creating bogus services.
One note, I'd use
,rather than/myself. Otherwise it looks like, in the dependencies example,Dependencies=This/ThaT/theotherwould be or rather than and.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
You can just change the delimiter within your own script (before including NullByte.nsh) or feel free to change it within the NullByte.nsh script.
I did define it to /, cause I thought that's what you where using.
Formerly Gringoloco
Windows XP Pro sp3 x32
I had mentioned the comma before, but I think SimpleSC used a / so I went with that with it. Comma is much nicer though. And neither is likely to (or should be) used in a service name (ID).
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
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.
Formerly Gringoloco
Windows XP Pro sp3 x32
Auto language switching will be originating from the platform, so you have access to the 5 environment variables that covers Locale Codes (2 and 3 char), LocaleID (aka 1033 for English), WinName (LANG_ENGLISH), LanguageCode, Localeglibc (things like en_US used by Pidgin, GIMP, etc) and one or two more that will debut shortly. This will cover a very good majority of apps that use one of the above methods to handle it.
For apps that don't and use their own proprietary setups, you can either write custom code or adjust the app. In the case of things like KeePass, I adjusted the language files to match the WinName (minus the LANG_ part, which will soon be available as it's own environment variable).
Sometimes, the impossible can become possible, if you're awesome!
Those are already there; for helpfulness reasons, they are set to the English defaults if they don't exist.
In my TODO list I haven't had language support there for quite a while - just better language support. I think a custom segment is probably what's going to end up being used by some, but I will be thinking more about this later.
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 sounds like a good idea to me. I'll extend it a bit further to support different base variables for the value names (e.g. Base=PortableApps.comLocaleglibc) and a default and a few minor things like that. This would actually fit the bill quite neatly for a couple of my apps; good thinking! My idea is pretty much like this.
For something like where you need the WinName minus LANG_, one possibility is %PortableApps.comLocaleWinName:~5% (I could possibly even do something like Base=%PortableApps.comLocaleWinName:~5% and then you could drop off the LANG_ in all the Values section). I think support for environment variable substrings is right through the NT line; thus if we force requiring Unicode support it'd be OK to use them. (That'd fix John's KeePass issue without needing to resort to custom 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
Don't worry about stripping LANG_. I'm gonna add another environment variable for it.
And we probably only need to do Language names in that INI of yours. No reason to support 6 different bases. Unless, of course, you make all entries optional. And if omitted it just uses your selected base. There have been a couple of apps that are almost all standard except for one or two languages (for some odd reason).
I'm gonna keep KeePass the way it is as some of the langs for a while changed names back and forth, sometimes included version numbers in the filename, sometimes not. It's easier to keep it standardized.
Sometimes, the impossible can become possible, if you're awesome!
I was intending that Base would have environment variable parsing, so you could put a default of the glibc version or something like that.
The main reason I was thinking of supporting different bases is that if it's just a slight variation of glibc, or support for lopping off the "-BR" in pt-BR, or something like that, then naming them with the glibc names would be much more understandable. I was intending to have all entries optional, defaulting to the default value (or if that wasn't set, the base value, so with base %PortableApps.comLocaleglibc% you wouldn't need to specify default %PortableApps.comLocaleglibc% if it's just variation in one or two).
Eek! The KeePass lot sounds a mess. I'll take a look at the 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
It's no code. I download all the current translations for each release and ensure they're named properly (none are included with the base download). They've been better about keeping the naming consistent lately, too.
Sometimes, the impossible can become possible, if you're awesome!
I'm not really agreeing to the 'Default=' option !
I think the default should come on first run, by the DefaultData.
After, whenever the PAM-set language doesn't exist for the specific PA, PAL should be able to leave the current language as set in the app.
For example: Lets say PAM is set to Bulgarian, the Bulgarian user can't read English, but could read Russian. Then the user would set his PA to Russian, if bulgarian language doesn't exist for this app. So when ever this PA is started again, PAL should be able to realize the PAM language doesn't exist (cause the ini entry isn't set), and leave the language as it was, Russian !
So no default !!! Otherwise the PA would reset it self every time to English, which could make this user very desperate !!!
Formerly Gringoloco
Windows XP Pro sp3 x32
It depends partially on how languages are set; there are two ways of doing it, per instance (with a command line argument or an environment variable like LANG) or in settings. When it's per instance, only setting the first time will be no good.
It's an interesting question which I'll give a bit of thought to.
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 found a somewhat-troublesome typo in Mutex.nsh:
${IfNot} $0 = 0I 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."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."
Take a look at LogicLib.nsh - you'll see that
=is integer comparison (==is string comparison). $0 is an integer and so IntCmp is faster than StrCmp.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
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'm not sure about this. Your INI file looks fine, so it's probably an issue with PAL, so I'll need to try analysing it myself. It'd help me (because I'm lazy) if you could send (probably email) me your package so that I don't need to sort out getting things in the right place.
Now I've got a Windows VM set up I'll be able to test this sort of thing out more properly.
Thanks
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 the Revo installed with just the launcher or with the PA suite? just wondering as I have it installed with the suite lite and it works flawlessly?
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
The only differences between the suites are what programs come with. That being said, I just use the menu itself and install the apps myself.
Besides that, though, you are using Revo with an old launcher. It works for some, but not for others (do you use XP, by chance?) What I'm working on right now uses an updated launcher and isn't yet available for download.
1) I am using XP home sp3
2) I installed the lite suite with 1.6
Then updated to the beta 2.0 beta 4
then installed the revo uninstaller as well as multiple cleaners and also added a2 portable, glarys utils, stinger, avir stand alone etc to make a "cleaners" disk util stick.
Any way did not mean to cause trouble or confusion, maybe I just keep reading and not reply I know I am new to the forum and portable apps and certainly did not mean to insult anyone or their intelligence.
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
Your feedback is certainly welcome, please do not feel that you are being discouraged from posting.
That seems to confirm that XP (or at least with XP with SP 3) users can use the old development test of Revo Uninstaller Portable (it works on my XP SP3 machine too, but not my laptop that has Windows 7 or work computer that has Vista). Interesting to know, and thank you.
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.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
That should be being deleted... I'll check over my code again. (Yes, it is $PLUGINSDIR.)
Edit: I can't see what might be happening. The line's there to delete it - Segments/Core.nsh:68 - have you got any idea why it might not be working? I haven't (which means lots of debugging and trying other directories [which I don't want in final, $PLUGINSDIR is the correct place].)
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'll look into it. Maybe I can find what goes wrong.
BTW my ini looks like this:
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Changing APPDATA... do you have to do that? You should know that it's evil to do such a thing. Does it really work with that? If so a better (nicer) solution would be to offer a patch to them to look at another environment variable first (see a search for APPDATA in it with Google Code Search; the first does "home" - high scores etc. - and the second in io does config, judging by quick search for the methods in those files).
Nevertheless that won't be the issue with launcher.ini in $PLUGINSDIR. That's something else.
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 works without a problem. I tried copying files around but couldnt get it to work so I redirected APPDATA and thought it was safe because SuprtTuxKart has no file dialogues or something.
EDIT: And ATanks uses an APPDATA-reidrect too
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
If ever you can't work out how to do something, please report it as it could be a bug (and I'll be able to help you anyway).
Although for games modifying APPDATA may work in my opinion it's just bad practice. Submitting a patch or asking them to check the environment variable PAL:DataDir first is a much nicer solution (then you may not need anything other than a ProgramExecutable value!).
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
As changing APPDATA could be the issue, Simeon, can you try it with it moving the settings to/from APPDATA (backing up existing ones) rather than messing with the env var?
Sometimes, the impossible can become possible, if you're awesome!
I will try and move the files around. But I know that redirecting APPDATA isn't the issue here as I just tried it with another program (JPEGView) where I only move 2 files from /Data to /App/jpegview and the problem still exists.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
It'll be something strange about $PLUGINSDIR. I'm hoping to be able to look at it tomorrow.
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
Why do you copy the launcher.ini file to $PLUGINSDIR\launcher.ini in the first place?
I changed
to
and now it works as expected.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
The INI file is *purposely* copied to the local PC. That way, on a drive pull... the app itself will either crash or exit normally without saving settings... and the launcher will still have access to its INI information in order to properly shut down. If the INI is on the drive that was pulled, the launcher would no longer have access to it.
If its causing the directory to remain, we could try adding a RMDir for the $PLUGINDIR at the end.
Or we could do the INI file elsewhere. Perhaps just in temp:
InitPluginsDir
CopyFiles /SILENT $EXEDIR\App\AppInfo\Launcher\$BaseName.ini $PLUGINSDIR-launcher.ini
StrCpy $LauncherFile $PLUGINSDIR-launcher.ini
Doing that would still give us a unique name and it would be easily associated with our temp directory when troubleshooting. And then we can manually delete the $PLUGINSDIR-launcher.ini file on exit. That should fix the issue completely.
Sometimes, the impossible can become possible, if you're awesome!
ok. The problem I have on my PC is that although the command to delete the file is in the script, it wont get deleted. I even altered the script to create a new file in the folder and delete it afterwards and this works. Its only the launcher.ini file that doesn't get deleted.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Ok, something is happening somewhere in PAL that is locking this file. It's *not* a standard Read or Write operation doing it, though.
I created a file in TEMP similarly named, wrote to it, read from it and immediately deleted. Success. This works both inside $PLUGINSDIR and in $TEMP itself.
I also switched the launcher to copy the file in and then not use it (using the one on the portable device). Success again as the file was able to be deleted.
So, somewhere in PAL, something is being done with $LauncherFile that is causing it to be locked.
This will require more research...
Sometimes, the impossible can become possible, if you're awesome!
I got it:
There is a FileOpen command on line 13 of the ForEachINIPair.nsh file but there never is a FileClose command. Could that be causing it???
EDIT:
Found it. Now it works!
Just uncomment line 65 (FileClose $_FEIP_FileHandle)in the ForEachINIPair.nsh file and it works.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
That breaks the loops. But you're on the right track.
Update. That IS the right place, but the way it checks for open file handles elsewhere is causing the issue. So line 65 needs to be uncommented and one line needs to be added to clear the variable. Details here:
https://portableapps.com/node/22987#comment-145552
Sometimes, the impossible can become possible, if you're awesome!
As soon as you mentioned that my mind went straight to ForEachINIPair. I'll just put in a single line to close the handle.
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
John posted the patch later in the thread.
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?
You're probably not using the correct format. Could you please post your string (and verify the format from the manual)?
All environment variables are supported and have been since Alpha 3 or so. This means you can use %WINDIR% if you like. Be aware that that directory will probably be read-only for most users without using RunAsAdmin.
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 following .ini line...
Get this debug message..
With some investigation, I think I found the bug in segment Registry.nsh line 39 of ...
Should be...
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...
I get this debug message...
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:
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 appendFormerly Gringoloco
Windows XP Pro sp3 x32
No official apps combine multiple keys from different hives into a single .REG file. They should be separate reg files.
Sometimes, the impossible can become possible, if you're awesome!
Sorry, I'll fix that up. I thought I'd got my 17s and 18s sorted out, and the debug message too...
I've also wondered whether the full hive name mightn't be neater anyway. Thoughts?
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 fixed them now.
We're not planning on supporting squeezing two keys into one file. There's not really any need for it and it makes things slightly more complex.
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
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 VERThis 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?
Sometimes, the impossible can become possible, if you're awesome!
I already implemented and pushed something to do that a couple of days ago in revision 35948a1c450e.
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
Line 10 of SplashScreen.nsh should be:
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).
Sometimes, the impossible can become possible, if you're awesome!
Not sure how that ended up like it did. I'll fix that.
I wasn't aware that we were going to make the display time customisable. We can 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
I've removed the fade and allowed the user (developer) to override splash time with [Launch]:SplashTime.
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
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:
That properly closes the handle and lets the procedure know it isn't open by clearing the variable.
Sometimes, the impossible can become possible, if you're awesome!
It'd be more efficient to just close it in the Core segment's Unload hook. ForEachINIPair won't be being used then. FileSeek 0 is more efficient than FileClose/FileOpen. (Earlier I had it just opening and closing each time, then I switched to FileSeek.)
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 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.
Sometimes, the impossible can become possible, if you're awesome!
If we could build a Unicode version of this I think the problem would be gone. That means waiting till Jim fixes !searchparse and !searchreplace.
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
@ChrisMorgan:
Just by compiling PAL with Unicode NSIS doesn't mean it immediately can deal with utf-16 files.
1. the original textreplace plug-in doesn't exist for Unicode NSIS,
2. PAL, compiled with Unicode NSIS should still be able to do text replacement for ANSI/utf8 settings files.
@John T. Haller:
Since 11 January I exchanged the NSIS script (what was to slow), for a modified version of the textreplace plugin. Called NewTextReplace !
Since then, there have been a few updates(last at 4 February)
Now it's fully compatible with ReplaceInFileWithTextReplace.nsh,
it can do the replacements in ANSI/utf-8 binary files and all utf-16 files
and it's basically just as fast as the original textreplace plug-in
On top of that the source is compiled for the original NSIS & Unicode NSIS
I've used it in Winamp Portable and Prapper has in like 4/5 of his apps, XMPlay Portable, Mp3tag Portable, Exact Audio Copy Portable, etc.
Although I have to confess this was my first real project in C, no issues have been reported.
So yes implement it in PAL, there will be no issues to change to Unicode NSIS later!
Any additional questions, leave a comment in the NewTextReplace forum topic.
[edit: Ok, another confession: utf-16 case-insensitive replacement only works for Latin characters(English), this is a result of a choice I had to make between this and being able to replace within binary files.
This should not be an issue for use within PAL !!!as it shouldn't have to deal with any foreign characters !
I should find a solution for this issue later, before I will be able to send the plug-in to the NSIS forum.]
Formerly Gringoloco
Windows XP Pro sp3 x32
Implementing NewTextReplace in FileWrite's Replace mode with
Encoding=UTF16-LEis coming (I'm planning to finish and commit it today). John and I discussed it yesterday in IRC (refer to the logs if you'd like to see how the discussion progressed).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
Hey, Chris, I implemented it simply with the following. PortableApps.comLauncher.nsi Line 100:
FileWrite.nsh insert starting at line 53:
${ElseIf} $0 == ReplaceUTF16 ${ReadLauncherConfig} $2 FileWrite$R0 Find ${ReadLauncherConfig} $3 FileWrite$R0 Replace ${IfThen} ${Errors} ${|} ${ExitDo} ${|} ${ParseLocations} $2 ${ParseLocations} $3 ${ReadLauncherConfig} $4 FileWrite$R0 CaseSensitive ${If} $2 != $3 ${AndIf} ${FileExists} $1 ${If} $4 == true ${DebugMsg} "Finding and replacing in a file (case sensitive, UTF-16).$\nFile: $1$\nFind: `$2`$\nReplace: `$3`" ${ReplaceInFileUTF16LECS} $1 $2 $3 ${Else} ${DebugMsg} "Finding and replacing in a file (case insensitive, UTF-16).$\nFile: $1$\nFind: `$2`$\nReplace: `$3`" ${ReplaceInFileUTF16LE} $1 $2 $3 ${EndIf} ${EndIf}I know this is probably not the way you'll actually implement it (as it's dirtier) but I did it as a test and it does work. I have one app that uses both modes of replace and both work.
It's posted here, so you can see it in action: https://portableapps.com/node/23093
Sometimes, the impossible can become possible, if you're awesome!
For some crazy reason I prefer an extra line "Encoding=UTF16-LE" to "Mode=ReplaceUnicode" or anything like that. It just feels more correct - it's still a Replace but with different Encoding. That's how I was planning on implementing it. What do you reckon?
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
Personally, I like Encoding as well (defaulting to ANSI, making it an optional entry unless you want to select UTF-16... and it should probably be "UTF-16" and not "Unicode" as we don't know about UTF-8 compatibility if people are using 2-4 bytes per char yet, I don't think... what do you think?). It does seem more accurate. And ideally, we'll enhance later so we can detect the encoding ourselves and just do it. I figured you'd want to implement it that way. I just put that together to try it out and ensure it was working properly with gringoloco's plugin... which it is.
Sometimes, the impossible can become possible, if you're awesome!
This is a very important change I've just committed.
Now an application like Audacity can do this:
The full format is like 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
Still, I don't think it should do this:
Do set the language at every startup if the specific language does exist, just don't set anything if the specific language doesn't exist !
Not exist = no ini entry at all or empty ini value
See my comment above
I'm just not sure how it will behave when the language is set as a command-line argument ?
As a compromise, is it possible to leave 'DefaultIfNotExists=' without a value to give PAL the behavior I suggest !
Formerly Gringoloco
Windows XP Pro sp3 x32
I think the DefaultIfNotExists will be a first-run only thing.
Sometimes, the impossible can become possible, if you're awesome!
See my earlier comment about transient/stored languages. However I am thinking of adding in the ability to fetch the value with ReadINIStr, RegRegValue or ConfigRead and using that if it exists or if it's not a first instance.
The main thing with it though is that it's got to have either some value or some way of skipping any registry or file writes which contain it (and I don't like that way of doing things; I'd prefer to get it right from the start [of the launcher execution] than to try to work around it).
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
Well, this will only be used when the platform variable is present. If the platform has a specific value set and the app does not have a corresponding language supported, the app should default to English on first run. Otherwise, it should NOT change the already selected language. All app launchers work like this currently, so PA.c Launcher should as well.
Sometimes, the impossible can become possible, if you're awesome!
All the PortableApps.com Platform environment variables are set to the English values if they're not set.
The slightly more complex thing is detecting when you've already set the language - or rather, fetching it back. I thought of storing it in PAL data but that won't be any use - it needs to load it from what the user has set.
I'll get back to you on how I improve it later today I hope.
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
You don't need to check if the language is already set or not in the app. You only need to do this when populating Data for the first time. So, basically, the same logic as DefaultData.
So, if you launch the app for the first time, it populates Data from DefaultData, gets the language from the PA.c Platform, checks if it exists in the app itself. If it does, set it to that. If not, set it to English. Then start the app.
If you launch the app otherwise, the launcher gets the language from the PA.c Platform, checks if it exists in the app itself. If it does, it sets it to that. If it doesn't, it does nothing. Then start the app.
If you launch the app NOT from the platform, the launcher itself should be in English. It should make no changes at all to the app language settings. It should just start the app.
Sometimes, the impossible can become possible, if you're awesome!
What's the point of anything in [LanguageStrings]? Will those values ever be changed, or is that just to show that that language exists in the app?
They're used for auto-language switching. Many apps will use one of the 5 types of language settings we use (Locale Code 2 or 3, Windows name, glibc, etc). A few will use one or two strings that are different (just to be difficult). Some will invent a whole new way of doing it (usually small projects with one developer who is unfamiliar with it). So, the full list allows for customizing one or all entries. You start with a base of one of our variables and then customize it to suit the app. Then you tell PA.c Launcher where too look to ensure the language is available (each app will store the locale files as different file names or in a sub-directory). Once found, we then change the app's setting. Chris came up with the method yesterday and it's a solid one.
Sometimes, the impossible can become possible, if you're awesome!
In 'Segments\Language.nsh', line 52:
${ReadLauncherConfig} $1 DefaultIfNotExistsShould probably be..:
${ReadLauncherConfig} $1 Langauge DefaultIfNotExistsAt least it compiles after this !
Formerly Gringoloco
Windows XP Pro sp3 x32
Sorry. I'll fix that today.
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
After the fix I done above, still doesn't work.
My ini: http://pastebin.com/rccXPCLb
First gives this debug message, what is correct:
But then when writing winamp.ini, %PAL:LanguageCustom% seems to be empty:
I tried several different ini settings, but all with same result
[edit: after commenting out the following lines, it worked as expected:]
Language.nsh lines 52-54
;${ReadLauncherConfig} $1 Langauge DefaultIfNotExists ;${ParseLocations} $1 ;${SetEnvironmentVariable} PAL:LanguageCustom $1Formerly Gringoloco
Windows XP Pro sp3 x32
I'll need to look into that. Possibly its handling of empty values isn't quite right.
For English and non-set languages though your code there will try writing to Data\settings\winamp.ini, [Winamp]:langpack=Winamp-.wlz. Is this really what you want?
Also it looks to me like glibc might be a better match for the Base string.
I think I'd get rid of the Default value. And you may want "DefaultIfNotExists=en" or something like that?
(It's also possible that you might want your Base to be Winamp-%PortableApps.comLanguageCode%.wlz, then you could have your WriteINIStr delete the value because it would get an empty string.)
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 can't get the lang-switching working properly because somehow %PAL:AppDir% (& %PAL:DataDir%) are not 'parsing' to an absolute path for 'CheckIfExists=', so the lang-file 'never exists' !
When I use an absolute path or %PAL:PackageDir% it is working as should:
Link to PortableApps.comLauncher.ini: http://pastebin.com/iM2JdN2a
Link to a package containing the launcher, .ini & some lang-files (I can only upload small packages):
http://www.mediafire.com/?jtyznm3ywmn (MD5: 09ce537d1974163e280b66d545212e97)
BTW: 'Winamp-.wlz' is not what I want. 'DefaultIfNotExists=' should be empty, cause english is included into Winamp itself, not a lang-file !
[edit: Done some investigating, and found out that most of the env.vars. are beeing created in 'Segment Variables Init', but %PAL:AppDir% & %PAL:DataDir% are only created in 'Segment RunLocally Pre'. This is too late for the lang-switching.]
Formerly Gringoloco
Windows XP Pro sp3 x32
Your edit concurs with what occurred to me as soon as you had the rest of the post there. I'll think I'll move the PAL:AppDir and PAL:DataDir to earlier, then just change them if RunLocally is true. That'll make them available earlier which is good.
Your INI file looks to be good.
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
You might be interested to know that the PortableApps.com Launcher (hg repo) will now compile successfully with Unicode NSIS.
Almost ready for 2.0 Beta 2.
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 just committed a generator wizard, based on the code of the Installer wizard. It's simplistic but should compile apps fine. What's more, it gets to use ReadINIStr and so it can pass parameters through makensis so that compiling with Unicode NSIS will not fail to read values with !searchparse, meaning you won't need to !define things in a PortableApps.comLauncherCustom.nsh file: that should be just a segment file now.
What's more I've just put the version number up to 2.0 Beta 2 (1.9.9.2) so you may be able to guess what's about to happen.
I'm going to test Mixxx 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
There won't be a release today after all. As a result of testing Mixxx Portable I did find a bug in PAL with ConfigWrite though (leading to an infinite loop when used) which I've fixed
As is common with many things, the development repository is more stable than the released version.
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 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:
but for some special characters it doesn't convert flawless, like for the '®' the script needs the following lines:
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!]
Formerly Gringoloco
Windows XP Pro sp3 x32
Pages