Outdated: this has been released.
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 2.0 Release Candidate 2 [718KB download / 1.8MB installed]
(MD5: 1d998f1d454b26de1d0a5054892ba291)
Download the PortableApps.com Application Template 2.0 Beta 2 [115KB download / 195KB extracted]
(MD5: f58081d20bf55c360f674e4d68b91702)
(This is from the Launcher 2.0 Beta 2 but nothing needs updating in it yet. Run the Generator from the latest package over your package built with this template and it will be up to date.)
To get a custom build of the PortableApps.com Launcher with custom icon and name (do), download the main PortableApps.com Launcher package and Unicode NSIS Portable and install them next to one another. Then run the PortableApps.com Launcher Generator and select your directory. Read the manual for more details.
Known Issues:
- Language switching does not work when running as admin as the environment is reset. Due to be fixed in 2.1 if possible.
Links:
- Manual (included starting at App\Manual\index.html).
- Using the PortableApps.com Launcher (old but still may be useful; from the Alpha thread, file names mentioned are now outdated).
- Development repository (including .tar.gz, .zip and .tar.bz2 snapshots for those who don't want to get Mercurial)
Release Notes:
- 2.0 Release Candidate 2 (2010-05-21):
- Fully automated build process (bash script... built on Linux :P)
- launcher.ini no longer left behind in $PLUGINSDIR
- [DirectoriesMove] supports a key name "-" to not save the directory but just revert it to the local version
- The user INI file doesn't care about the INI section header any more (ConfigRead)
- Improvements to the Generator (especially error checking)
- Slovenian translation (thanks, Filip), and better management of languages for me (maintenance in a single file instead of maintaining two lists of languages)
- (Few enough changes that I can list them all!)
- 2.0 Release Candidate 1 (2010-05-18):
- Built with Unicode NSIS Portable 2.46 DT3
- Various bug fixes
- A few new features
- See comments from old thread and changesets for a manifest of all changes.
- No known issues beyond the admin environment one mentioned above for fixing in 2.1.
- Unless any more issues are found, I think this may become the final release (except for the hoped addition of an Armenian translation awaiting some final corrections).
Discussion, notification of some changes and earlier release notes are available in the 2.0 Beta 3-4 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
[DirectoriesCleanupForce]
Shouldn't this backup/restore any local folders of the same name? It doesn't seem to at the moment.
[DirectoriesMove]
Folders specified here seem to be created by PAL automatically. Wouldn't it be better if they weren't?
No. That sort of thing can be done with a DirectoriesMove directive. This is designed more for use in a situation where you have a DirectoriesMove which has temporary data in it which is big but is safe to delete and so you don't want to keep it. It's probably not useful in many situations at all. DirectoriesCleanupIfEmpty is generally more what is wanted. Considering DirectoriesMove though, I think I'll implement what I implemented with RegistryKeys: a key of
-making it not back it up, so it would effectively become a DirectoriesCleanupForce with backup. What do you reckon on it all? Mentioning it like you are I'm thinking over it and wondering whether it really is very useful in its current state...This is by design, mainly so that if other things need to work in that directory they can, and so that there will be something to save. Why do you think it should not be created?
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 think this would be better as, even though the temporary data isn't worth keeping, you don't necessarily want to trash the local stuff either.
Not totally sure what you mean here by "other things" but, if I understand correctly, in that situation the app would just create them as needed though wouldn't it? But then again, maybe not, so I'm not so sure now. It just struck me as odd that directories that could potentially never exist were created.
By "other things" I mean other parts of the launcher.
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 like the idea to use a "-" for the other thing, because I simply don't see why DirectoriesCleanupForce would ever be used in its current state.
If you were running a browser and it was using a local cache, for example.
Sometimes, the impossible can become possible, if you're awesome!
That is, provided it's not going to be in the same path as a local cache. In which case a [DirectoriesMove] with this hypothetical key "-" would do just as well (and back it up if necessary into the bargain).
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 updated my PAL and it left %TEMP%\nsr1C.tmp\launcher.ini behind.
But I am pretty sure it wasnt introduced with this update as the latest UnicodeNSISPortable_2.46_Developement_test_3_online.paf.exe package also has this flaw.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Cool, OpenTTD Portable isn't the only one.
I'll investigate more.
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
In switching back to the old ForEachINIPair macro I had neglected to go back to closing the file handle, so there was a line missing in Core/Unload just before the Delete,
FileClose $_FEIP_FileHandle.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,
I have to do a WaitForEXE1= in my launcher.ini but sometimes, the application crashes, which is not totally unexpected. How can you cleanup the file AppName\Data\PortableApps.comLauncherRuntimeData-AppName.ini when that happens? If it is present when relaunching the app, it tends to hang.
Thanks!
Homer
That file will be deleted if the app crashes, but if the launcher crashes it won't be - with good reason, as it needs to clear up what got left behind.
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 wanted to see if anyone had any suggestions about the error that I am receiving when I try to use the PortableApps Launcher Generator. When I try to use it, the launcher creations fails with the following report. Any suggestions would be greatly appreciated. I received a similar error when I previously tested it with the beta 4 release. I redownloaded the UnicideNSISPortable and tried again using a different file location without success as well. Thank you for your assistance with this situation.
Processing script file: "F:\PortableApps\PortableApps.comLauncher\Other\Source\PortableApps.comLauncher.nsi"
Including required files... (macro:!echo:3)
!insertmacro expects 1+ parameters, got 0.
Usage: !insertmacro macroname [parms ...]
!include: error in script: "F:\PortableApps\UnicodeNSISPortable\App\NSIS\Include\Util.nsh" on line 25
!include: error in script: "F:\PortableApps\UnicodeNSISPortable\App\NSIS\Include\TextFunc.nsh" on line 60
Error in script "F:\PortableApps\PortableApps.comLauncher\Other\Source\PortableApps.comLauncher.nsi" on line 51 -- aborting creation process
That's due to your appinfo.ini missing or not being in order !
Look at:
BTW: Maybe ChrisMorgan could modify something here, it definitely is a very confusing error message.
Formerly Gringoloco
Windows XP Pro sp3 x32
looks more like an error message from inside NSIS to me and thus nothing Chris can modify easily.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
That's a very strange error. What it's saying is that it's getting to line 51,
!include TextFunc.nsh, then inside TextFunc.nsh to line 60,!include Util.nsh, then inside Util.nsh, into the!macro CallArtificialFunction NAME(!?) to the line!insertmacro ${NAME}and deciding ${NAME} is nothing. I can't work out how it's getting to this stage, it's all weird. You could try changing line 22 of PortableApps.comLauncher.nsi,!verbose 3, to!verbose 4, then you might possibly get a more useful message. I can't understand quite what it's doing beyond the possibility of slightly messed up encoding in one of the files somewhere (presumably in Util.nsh) doing something weird.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
in trying to do Hugin 2010.
Should we be using the DL link here, or is there a later one on mercurial?
I made this half-pony, half-monkey monster to please you.
What version of NSIS are you using? I've got a notion I've almost worked out what's going wrong, and it's an NSIS bug in the handling of closing the
!ifdef.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
UnicodeNSISPortable_2.46_rc2_Developement_test_2_online.paf.exe is the setup file.
I made this half-pony, half-monkey monster to please you.
Please update to 2.46 DT3 and see if that fixes 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
I'm probably doing something wrong. I'll have to re-read the manual and pick it apart.
I made this half-pony, half-monkey monster to please you.
The problem is that it just doesn't make sense. Try running it over the PAL directory itself, that should work if it's some other issue than what I think it is. Also then could you please report the OS etc. you're using.
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 tried it over the PAL directory and it completed successfully on Win XP SP3. I hope that helps.
In using the Launcher, I originally selected the immediate parent folder (bin) to the executable.
That is, I selected
HuginPortable |_App |_Hugin |_binOnce I selected the top folder
it worked.
Sorry about that!
I made this half-pony, half-monkey monster to please you.
Still not good. I'll try to pinpoint it now.
I've now come up with a vague notion as to why it's going wacko; it sees ${Name} is defined (empty), gets its !macros muddled and goes on. I'm pretty sure it's an NSIS bug, but there was also a slight bug in the PAL Generator in that it continued on trying to generate the launcher once it had identified. So I've fixed some bugs and put a couple of new features in the Generator as a consolation prize. Now it won't let you do it except to the root of the package.
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
Released 2.0 RC2. Hopefully there are no more issues and this can become the final release without any more modifications.
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, I'll find something.
If there are issues there to find, find them. I made sure that I said "Hopefully there are no more issues", not "Hopefully you won't find any more issues"
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 just got ATanks to wiórk with RC1 with language switching and all. Everything worked (crashing the app, local settings etc), nothing was left behind except for the ini file but that's been taken care of in RC2.
I'll be gone for a week so I sadly wont be here for the release
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Glad you got to test it all.
If you'll be gone for a week, I hope you won't be here for the release
Hopefully you'll find lots of things have happened while you're away, I think you'll find it's a fairly critical week for activity. I hope so, anyway. Enjoy whatever you do, sorry for your sake you'll miss what happens here.
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 Chris, I made a menu that you can add for your launcher that I think could be helpful to many users. It in houses the help file with the Launcher Generator and also the folder template I have also included the sample scrips with the main Launcher script that you setup as a guideline.
I hope you guys like it and if you need me to modify it in any way please let me know download it extract it in the same folder as PortableApps.comLauncher is or it wont work.
This will only add some files with some pictures. Your program stays the same and it works well with portableapps menu.
I hope you like it.
E-mail me at danny_m_2785 @ hotmail.com for questions or suggestions about this menu.
That's actually pretty impressive. Needs quite a bit of work (mainly GUI stuff), but I like the idea.
It's a beta, but it just for now so that it make things easier to manage i can also include NSIS Portable, PA Installer and or other programs to this menu but i would have to change the configuration of the folders and so on but i think this is good for now.
This program is actually meant for making CD/DVD Autorun Menus but it also has many other ways that it can be used as you can see. It can also be very complicated stuff that you can create with it I know I was going to make a CD menu for PAC and stop when new freeware programs where added. I could make the menu as a downloader or an installer with all information that belongs to each program(s).
And yes we need a GUI to go with this so that it makes it faster and easier for us the developers to make our programs faster and not have to run around so mush in the main menu and all the folders to find what we need.
I think that's a good idea, but I don't really like the implementation, mainly because it doesn't work in Wine and is pretty big. I might reimplement a similar thing in AutoHotkey after 2.0. (There's also the portability of that MSHTML control to consider - it's not portable.)
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
Changes can be made to it but like you said it dose not run in wine, but this is only a sample of an idea for the future for any one that can come up with a simple gui that runs in java or something that people can use to for managing that different programs and scripts at the same time to cut down on the hassle of opening and closing programs and scripts from different windows etc.
ok so i though about it and you are right the menu is to big so i also removed all the big stuff from it and this way i think it can be used in win not sure but let me know if it works. Just replace the autorun file with this one here and let me know how it works.
I found something that might be useful, it is a free "Gui Builder" that might be helpful for making the gui that we need. All that is needed is some one that know how use java programing.
here is that link toGuiGenie.
We can also see if can add this program to PAC since it looks useful.
Hey I updated the menu for the PAC Launcher just added a couple of things. just extract and replace the files that are already there from before and you are good to go. Downlaod It Here
Enjoy!!
Before I take you up on your work how about letting me know what few things you updated? What was so wrong? What needed modification?
“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
Ok well all i did was make the main window smaller 303px with, 504px hight. This is to save space and also because MSHTML is not portable so there for i can't display HTML documents in this menu as Chris explains. So I added a file menu-bar with the option to explorer folder and a exit button, on the help menu i added a home page to PAC Launcher button and also the help file to PAC Launcher it also has an about button informing the user not to delete the autorun.aru file or the menu will not work.
I am not going to continue the discussion of the menu here for it is not part of the PAL. I will post a link to this menu
soon.EDIT: here is the link to the GUI/MENU for PAL https://portableapps.com/node/23631
Sorry Chris for taking space in your forum.
And I was still having quotes around some of my ini values. Then ForEachINIPair deleted the quotes, but also the last character of the string.
ForEachINIPair.nsh, line 70:
StrCpy ${VALUE} ${VALUE} -2 1Should probably be:
StrCpy ${VALUE} ${VALUE} -1 1[Edit:
Some thing I brought up a while ago about the language switching, here & here, still seems to be an issue ! And yes I know, also for me it's a PITA to get my head around this one, but I consider it quite an important feature, what is missing atm !
Maybe it could be done by always reading the initial value with [LanguageFile], also when PAP is used ! Then later, if the LanguageString or language file is missing, PAL could use the initial value, instead of the default !]
[Edit:2 'also when PAP is Not used' should be 'also when PAP is used'. Small typo, but big difference! Fixed it now, though]
Formerly Gringoloco
Windows XP Pro sp3 x32
I've fixed ForEachINIPair. Sorry about that bug.
Regarding your edits, about language switching, this is by design, we don't want to change that. In the next release of the Platform, users will be able to disable language-switching on a per-app basis if they really don't want it to do the auto-selection, but normally they will want 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 been playing with the language section, to have a better idea how realistic my above statements are! And I came to this.
http://pastebin.com/mQydWs9Z
I done some testing on it(maybe not enough yet, but had to go to bed), and it does for what I head in mind. But I'm not sure if it does all what you have in your mind.
It still deals with a 'Default' value, but is basically only used on a first run.
Formerly Gringoloco
Windows XP Pro sp3 x32
I updated Japanese translation.
Please check follow:
http://oss.poyo.jp/pub/contribute/portableapps/2010-06-01/japanese_trans...
(hg exported)
I imported your patch. (This would have been better put in the translations thread, 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 done a re-write of the two functions of TextFunc.nsh to support UTF-16LE format files.
It's setup in a way that the function checks what the encoding is, so the function will use the appropriate encoding to write/read the file !
I just hope you aren't using anymore functions of TextFunc.nsh, but if you do, let me know and I'll have a look at it.
For now just include this into PAL's 'Other\Source' folder. PAL should automatically make use of it that way.
I will report this to JimPark.
TextFunc.nsh
[edit: BTW, wouldn't it be better to deal with .reg files as an INI file, instead of using ${ConfigRead} ?]
Formerly Gringoloco
Windows XP Pro sp3 x32
I see you read the logs
There was a reason why I didn't use Type=INI... I just can't remember what it was now, and I can't see any reason why not 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
Is this related to your headerless INI files?
Sometimes, the impossible can become possible, if you're awesome!
Reading a UTF-16LE .reg file. INI should work fine for them.
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
First of all there is a small typo in the manual, the minus is in the wrong place:
Second issue what came to my mind, is when updating existing (ansi) apps, the ansi reg file will have a problem to be drive-letter updated when using the above setting.
One way of solving it (just came to my mind) is to have PAL look for a BOM by default. Instead of using ANSI by default !
Example, just add this to FileWrite.nsh after line 54 (${ReadLauncherConfig} $5 FileWrite$R0 Encoding)
${If} $5 == `` FileOpen $9 $1 r FileReadByte $9 $5 ; Use FileReadByte for ansi NSIS compatibility FileReadByte $9 $8 IntOp $8 $8 * 256 IntOp $5 $5 + $8 ; FileReadWord $9 $5 ; Unicode NSIS ${IfThen} $5 = 0xFEFF ${|} StrCpy $5 UTF-16LE ${|} FileClose $9 ${EndIf}BTW: I just realized I have a bug in my code TextFunc.nsh code. FileSeek isn't using the right handle in line 936 & 1030. This is to reset the file position after trying to read a BOM but it didn't exist. Maybe I do an update of the whole file (one day) as I should probably finish the other instructions as well !
[edit: For your info, I never yet experienced a problem with, quote:
, neither with RegistryValueWrite.nsh, which I'm using in one of my own apps with 7 separate value to write ! I did see you have some doubt about the code, but sleep 50 shouldn't be necessary and definitely deleting before writing a value is also not necessary !
Sorry for the amount of edits !]
Formerly Gringoloco
Windows XP Pro sp3 x32
Language switching doesn't work for apps that use RunAsAdmin because the environment variables are not passed to the admin process, thus it always defaults to English.
I've updated various things based on your post.
* 256(and also use<< 8instead of* 256, it's more precise) and then checked that it was equal to 0xFFFE, which is the UTF-16LE BOM (UTF-16BE is 0xFEFF). Also I chose to use FileReadWord for NSISu as it's more precise and readable. Not that there's any real difference. Also I couldn't work out why you used $8 instead of $6 so I used $6. (Edit: we discussed this and I see why you did it this way, LE reverses it, so ReadWord did it back to front too, so I've gone to just using FileReadByte.)I think the encoding auto-detection is very important. I'd completely forgotten in my drive letter updating in a .reg file that it was now a Unicode file, so I was missing an Encoding=UTF-16LE. Far easier to not need to remember it.
I'm glad of what you say with the RegistryValueWrite, I think I started to work out a bit what it was, but I'm still not entirely clear on it. I got a bit frazzled trying to work my head around it at the time with Sweet Home 3D, so I went and designed a crazy room (with the UI in Polish :P) instead. I still have yet to get back to it properly to work out exactly what was happening.
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
SweetHome 3D, Does it do language switching in the registry with a REG_DWORD ?
I did encounter a problem with PDF-XChangeViewer that way, the issue is that the reg file format has DWORD's in HEX values, while ${Registry::Write} writes in decimal values. At the time it wasn't a big issue, but now with the new language handling, there needs to be a proper solution.
Formerly Gringoloco
Windows XP Pro sp3 x32
No, it uses REG_SZ.
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 there anyone who thought about what happens with my settings if my PC crashes due to a power failure or something else?
Last week I crashed my PC (deliberately!) to see what happens to my portable settings. It was exactly the way I thought it would be: the settings I had copied to my %APPDATA% remained there and when I run my app after the crash, PAL thought they were the local settings and backed them up.
Does that mean the "no personal settings are left behind"-rule only applies if I shut down my PC peacefully?
I haven't tried if the PAL correctly saves my "portable" registry entries back to my Data folder after a PC crash but I think it does as they are all kept in one place.
I know this problem has existed for about as long as this page is up, but it just appeared to me that maybe the new launcher could be a way to work around it by having a file stored some place so it can keep track of things and clean up a pc even after a crash.
EDIT: I just found this comment by Chris mentioning that something like this is already in place. Does this only work in the registry?
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
This is a consideration which John and I did think of with the Launcher. It would be a fair bit of work doing it for individual apps, but once you've got it the way we do now it is far easier to implement with portable settings.
It should all be brought back properly; it should work with all things moved. This is how it works: when you run it normally, it runs the .onInit, Init, Pre and PrePrimary/PreSecondary hooks, then executes, then does Post, PostPrimary/PostSecondary, then Unload. When it gets to executing, it stores a value saying that it's running (in Data\PortableApps.comLauncherRuntimeData-AppNamePortable.ini). In Unload, it removes that. When it starts, after Init, it checks for that value. If it exists, then it assumes it crashed and so skips Pre* and execute, going to Post. Thus, it should clean up (though it's silent and gives no indication that it's done anything, which could potentially be confusing). The first time you run it after a crash it should not execute the program, and just clean up (including the $PLUGINSDIR from the previous crashed instance). Then the next time you run it, it'll run.
Maybe I should test this again myself to make sure it's working. Terminating the XPortable and X processes should do 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
How do I write the drive letter to a file on first run? I debugged the launcher and it seemed like the drive letters were being assigned before DefaultData had been copied. Is that correct or am I missing something?
I don't understand what you need. The drive letter and last drive letter are read during Init and DefaultData is copied in PrePrimary, but I'm not clear about how or why you need it. If you just need to have a certain default drive letter to start drive letter replacement from, you could have App\DefaultData\settings\AppNamePortableSettings.ini with [AppNamePortableSettings]:LastDrive=X: for some value of X. There's nothing to stop you putting that file in the DefaultData (I've done it once before). If that's not what you need, please provide more details and I'll try to help.
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
Yes, that's exactly why I need it and I have that file (and the one I'm replacing in) in DefaultData with the LastDrive value in both files set to X:. If the drive letters are assigned before DefaultData is copied, they'll both be set to the current drive (as no data/lastdrive exists yet) and LastDrive=X: will be ignored when the replace happens.
But it's working for you?
Oh, I see what you're saying now. I used that technique quite a long time ago, can't remember if it even antedated PAL... haven't got a clue what it was I used it in. But the technique is sound, just won't work here due to the implementation (which is correct).
Hmm...
What's the precise case? (More details?) Is there some other way it might be done at all?
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
Just copy DefaultData a bit earlier? Move "${RunSegment} Settings" from PrePrimary to before DriveLetter in Init, change the segment hook & $DataDirectory variable in "Settings.nsh" and that's it. Does it interfere with anything else? It seems to be fine here. What do you think?
PortableApps.comLauncher.nsi:
Function Init ;{{{1 ${RunSegment} PortableApps.comLauncherCustom ${RunSegment} Core ${RunSegment} Settings ; *** moved from PrePrimary ${RunSegment} DriveLetter ... Function PrePrimary ;{{{1 ${RunSegment} PortableApps.comLauncherCustom ; ${RunSegment} Settings ; *** moved to Init ${RunSegment} DriveLetterSettings.nsh:
${SegmentInit} ; *** moved from PrePrimary ; Check for settings ${IfNot} ${FileExists} $EXEDIR\Data\settings ; *** $DataDirectory changed to $EXEDIR\Data ${DebugMsg} "$EXEDIR\Data\settings does not exist. Creating it." ; *** " CreateDirectory $EXEDIR\Data\settings ; *** " ${If} ${FileExists} $EXEDIR\App\DefaultData\*.* ${DebugMsg} "Copying default data from $EXEDIR\App\DefaultData to $EXEDIR\Data." ; *** " CopyFiles /SILENT $EXEDIR\App\DefaultData\*.* $EXEDIR\Data ; *** " ${EndIf} ${EndIf} !macroendThe main reason why it's in PrePrimary and not Init is that it shouldn't really happen until we're sure it's not going to quit. My reasoning has been that if the app is going to abort (executable not there, etc.), it shouldn't really be changing the Data directory. Not sure if it really matters though... changing this would make it malfunction slightly in Live mode, where it should not make any changes locally, but then Live mode is only supported when settings already exist, and so the "bug" of it modifying the Data would only appear when they're not using it properly. It'll also make Live mode break more (possibly completely, depending on the app and launcher configuration) if run with no prior settings.
Whether I make this sort of a change or not, it won't go into 2.0 which has been finalised, or into the 2.0.X line at all as that will be just bug fixes. 2.1 is the earliest it will go in (indeed, I'm currently working on the 2.1 line).
Keep going. I'm weakening
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
What about this? Settings.nsh:
${SegmentFile} ${SegmentPrePrimary} ; Check for settings ${IfNot} ${FileExists} $DataDirectory\settings ${DebugMsg} "$DataDirectory\settings does not exist. Creating it." CreateDirectory $DataDirectory\settings ${If} ${FileExists} $EXEDIR\App\DefaultData\*.* ${DebugMsg} "Copying default data from $EXEDIR\App\DefaultData to $DataDirectory." CopyFiles /SILENT $EXEDIR\App\DefaultData\*.* $DataDirectory ;=== Check LastDrive again ============================================================================== ${If} ${FileExists} $DataDirectory\settings\$AppIDSettings.ini ; ReadINIStr $LastDrive $DataDirectory\settings\$AppIDSettings.ini $AppIDSettings LastDrive ; StrCpy $1 $LastDrive 1 ; ${SetEnvironmentVariable} PAL:LastDrive $LastDrive ; ${SetEnvironmentVariable} PAL:LastDriveLetter $1 ; ${DebugMsg} "Current drive is $CurrentDrive, last drive is $LastDrive" ; ${EndIf} ; ;======================================================================================================== ${EndIf} ${EndIf} !macroendAlso, it occurs to me that the only place to insert 'first-run only' code would be just before the last ${EndIf} in Settings.nsh. The only way I can think of doing that at the moment would be to disable the Settings segment, move it's contents up into PortableApps.comLauncherCustom.nsh ${SegmentPrePrimary} and add custom code there. Which works but is there another alternative? Or am I the only person that'll use it?!
Code duplication! Putting things in the wrong spot! Panic!
OK, you've scared me enough that I think for 2.1 I'll move Settings from PrePrimary to Init. I suppose it really is initialising...
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
Agreed.
You mean re-checking LastDrive? What's the alternative with the current running order (another possible solution below)?
What's in the wrong spot? You mean this... ?
In which case, the running sequence hasn't changed because it's the first thing to run in PrePrimary anyway and there's still no duplication as the original segment has been disabled.
OK... last one.
DriveLetter.nsh: It's all in PrePrimary now.
${SegmentFile} Var LastDrive Var CurrentDrive ; NOTE: (Last|Current)Drive refer to $EXEDIR, even with Live mode ; TODO: make it (Last|Current)(App|Data)?Drive ${SegmentPrePrimary} ; Load the last drive letter and get the current drive letter. If ; LastDrive is not set, we set it to CurrentDrive, then any [FileWrite] ; with Type=Replace will skip last->current replacement as they'll be the ; same. ReadINIStr $LastDrive $EXEDIR\Data\settings\$AppIDSettings.ini $AppIDSettings LastDrive ${GetRoot} $EXEDIR $CurrentDrive ${IfThen} $LastDrive == "" ${|} StrCpy $LastDrive $CurrentDrive ${|} ${DebugMsg} "Current drive is $CurrentDrive, last drive is $LastDrive" ; Past the possible abort stage so it's safe to say we've run from this drive. WriteINIStr $DataDirectory\settings\$AppIDSettings.ini $AppIDSettings LastDrive $CurrentDrive !macroendVariables.nsh: Drives moved to PrePrimary.
Remove lines 124 - 129 ... and add them to the end... ${SegmentPrePrimary} StrCpy $0 $CurrentDrive 1 StrCpy $1 $LastDrive 1 ${SetEnvironmentVariable} PAL:Drive $CurrentDrive ${SetEnvironmentVariable} PAL:LastDrive $LastDrive ${SetEnvironmentVariable} PAL:DriveLetter $0 ${SetEnvironmentVariable} PAL:LastDriveLetter $1 !macroendPortableApps.comLauncher.nsi: DriveLetter segment removed from Init and Variables segment added to PrePrimary.
Function Init ;{{{1 ${RunSegment} PortableApps.comLauncherCustom ${RunSegment} Core ${RunSegment} Variables ... Function PrePrimary ;{{{1 ${RunSegment} PortableApps.comLauncherCustom ${RunSegment} Settings ${RunSegment} DriveLetter ${RunSegment} VariablesSo the only thing that's changed (I think) is that the drive letters are assigned after DefaultData has been copied instead of before. Did I break it again?
Moving DriveLetter to PrePrimary is just the Wrong Way to Do It. Working out the drive letter is definitely an initialisation task (and should be done as early as possible, too). I'll move Settings to Init instead, that's the Right Way to Do It, I think, for 2.1. Sorry for the trouble of it not working.
(My current plan is to release 2.1 within about a month, with a number of new features like OS detection and DLL registering, probably services, some improvements, and a lot of work on the manual. I'll see how I go. In the mean time, wait for a few days and I should have changed this behaviour in the repository and then you'll be able to work off the tip rather than the 2.0 line.)
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, we may have a problem.
TopOCR saves a lot of info in %WINDIR%\TopOCR.ini. On my XP box, TopOCR Portable cleans that up. xuesheng (one of my TopOCR Portable testers), though, reported that that file is not being properly cleaned up on his Win7 64-bit system, despite the appropriate PAL command. He thinks the problem is with the file virtualization employed on 64-bit systems; if this is the case, PAL has a pretty big hole.
Here's the whole story:
https://portableapps.com/node/21986#comment-151436 (original report of trouble)
https://portableapps.com/node/21986#comment-151563 (suspicion of file virtualization, including some good info from MSDN)
"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 don't believe directory virtualisation is limited to 64-bit; it applies to Vista and 7, mainly when running things in compatibility mode as far as I've had experience (my Dad had a lot of trouble with it sorting out a Python module install path where something said it was in one place, but clearly wasn't... this was the culprit).
I don't think there's really anything I can do about it. PAL is a proper Vista/7-compatible application and has no need of the virtualisation stuff. There's then no real way for it to access that stuff, whereas something it runs may need it... I think you're going to need custom code of some sort as a temporary measure (though exactly what you should test for, I have no idea; just Vista/7 - !include WinVer.nsh then ${If} ${AtLeastWinVista} - may do it but seems to me a very dangerous way of looking for it). What I think you should do is get in contact with the author and ask them please, please to change the directory it goes in as %WINDIR% is the Wrong Place, and has been since about Windows Me or possibly just NT. Things like that should never go in %WINDIR%.
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, I happen to know something about TopOCR which makes another release just to change %WINDIR% to something else useless. (I'm not sure how much I'm allowed to say, so that's all I will say for now)
xuesheng says detecting virtualization in use is pretty easy, so I'll ask him to come over here & toss you the info. My search didn't turn up anything useful, and your suggestion seems as dangerous as you say it is.
Thanks anyway!
"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."
The [FilesMove] description in the manual says "The target directory is the full path to the directory the file is copied to during the program execution. Do not include the file name."
If the target directory supplied ends in a trailing slash then when the program ends the launcher will remove the target directory if it is empty, even if the empty directory existed before the launcher started.
For example, if the launcher.ini file contains
this results in the launcher's runtime data file containing
Changing the launcher.ini file to
gets rid of the "RemoveIfEmpty:C:\Windows\=true" entry
The clear solution there is to not to put in trailing slashes which are Wrong. It appears that checking for the existence of C:\Windows\ says it doesn't exist - whereas C:\Windows or C:\Windows\*.* would. I don't plan on fixing this, as it's too much work to support bad values, and it's a very minor issue, but later I plan on writing a validator for launcher.ini files (probably 2.3-2.5, a fair way down the track; I'll see what demand is like. It might be worth doing it earlier just to stop people coming asking "why doesn't it work?" :P).
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
Perhaps the manual should mention that trailing slashes should not be used here?
Possibly it should, but really, on Windows a path to a directory is incorrect if it has a trailing slash... on *nix it's optional and allowed (directory completion in bash includes the slash when it's the only complete option) but on Windows checking for the existence of anything with a trailing slash will fail. People shouldn't be doing it in the first place, but a note in the manual (and making the stuff about not including the file name) would probably be a good idea. A validator would be the best solution.
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 think you are wrong about this. A quick look at the configuration data for several of the applications installed on my system found a lot of paths ending in \
(e.g. 7-Zip, ATI Catalyst display driver and associated utilities, MS .NEFramework, MS Intellipoint, OpenOffice.org, etc, etc)
Most applications will not use the lowest level file checking facilities of the operating system but will wrap analysers and fixers around it so that it makes sense. At the lowest level, it does seem to me that it doesn't work with trailing slashes... but really, it doesn't matter. IfFileExists in NSIS doesn't work properly with them
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
drives as paths are yet another case.
For example, the distinction between these two
C:\Users
C:\Users\
is very minor, whereas the difference between
C:
C:\
can be MUCH bigger, since there is a backwards compatability inheritance from DOS days, where a drive letter and a colon with no path at all means the current working directory on that drive, and not the root of it.
Roots of drives are always expressed within windows with a trailing slash, whereas subdirectories generally aren't.
If I use any of the standard NSIS registers ($0 to $9, $R0 to $R9) in my custom code segment do I need to worry about saving/restoring their values at the start/end of my custom code?
Each segment-hook is entirely self-contained (except for some correlation with other declared variables to make sure that they're defined). $0-$R9 are fine for you to use for whatever you like.
Glad you're helping on this virtualisation issue (no, I won't call it a bug - except in TopOCR for writing to WINDIR!)
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
Thanks for the clarification. I'd guessed it was OK to use them but the manual did not seem to mention them at all.
My original custom code idea has needed some revision but I hope to upload it soon (tomorrow?). It's about 100 lines long which is a bit long to post in a forum message so I think I'll use pastebin.
I can't get this latest one to compile...
The latest NSISu is missing the MoreInfo plugin. You can grab it from the NSISu Portable page and add it yourself. It'll be in the final version being posted tomorrow.
Sometimes, the impossible can become possible, if you're awesome!
OK Here they are, they may be stupid but hey if I don't ask I won't know:
Thanks
“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
Mind posting your launcher.ini file? The files should be transferred before Snarl starts, and something's seriously wrong if that's not happening.
"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 know directories move looks wrong BUT it is only way to get it to delete the APPDATA info. I also have the files needed for APPDATA preloaded into App/DefaultData folder. Also I have toyed with multiple versions of this ini making numerous changes to no avail.
“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
DirectoriesCleanupForce looks weird. I'm not sure if those quotes are supposed to be there or not, but I don't think they are. Also, you should be aware that will forcibly destroy that %APPDATA% folder, which could wipe out a local installation of Snarl.
For DirectoriesMove, try replacing the curly brace with a square bracket, like so:
[DirectoriesMove}
should be
[DirectoriesMove]
Hope that helps!
"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."
ok thanks about the } did not see that typo, the only reason why I forced the directory removal was that when I did not it left one subfolder...will give this s a try and let you know thanks again
“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
You should only use DirectoriesCleanupIfEmpty for that. If there's another subdirectory in there, then you need to do something about it too.
Also please remember to use <pre> for blocks of code, not <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
Here is my NEW Launcher.ini file as suggested by Chris I have used cleanupifempty
Guess what
I have had this deletion issue before in using MoveDirectories....
NFI what is going on but guess time to go restore my system to previous state so I can get my APPDATA folder back??
(BTW Mod Chis notice the tag?)
“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
Pages