Yay! It's what you've all been waiting for since the 18th of May.
Download the PortableApps.com Launcher 2.2 Beta 1 [1MB download / 3MB installed]
(MD5: 32dd22c4a8f84a785ea3bf7990c35a34)
2.2 is more better than 2.1 than 2.1 was than 2.0.
What more do you need to know?
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
so does this make it betterer that the other or bettererer?
LOL Great job Chris
“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
Chris, can we get a PortableAppsRoot and LastPortableAppsRoot variable in for 2.2 final? This is the biggest thing missing from PAL (in my humble opinion) as it results in broken most recently opened files lists and automatic last opening of files for folks running from DropBox and similar services where the parent directory for both PortableApps and Documents changes with each use (From C:\Users\UserName\DropBox to C:\Documents and Settings\OtherUserName\DropBox for example). We'd basically be storing the parent directory of the PortableApps directory, so two up from AppNamePortable where the launcher runs. In cases where AppNamePortable is in the root directory or the launcher is in the root, we'd just store the drive letter sans backslash to keep it consistent in using it. Thoughts?
Also, this is using mutexes now instead of the INI file that gets left behind resulting in the app unable to open in the case of a system crash, power outtage or drive pull, correct?
Sometimes, the impossible can become possible, if you're awesome!
1. We are not doing
Last*variables anymore, due to the addition of the[LastRunEnvironment]section.2. Do you prefer
PortableAppsRootorPAL:PortableAppsRoot? Should we do them with the other environment variables too? Remember, we will need to create them if not running from the Platform.3. Try it! (kill the launcher with the app running and then close the app)
I will left the discussions regarding the feasibility of
PortableAppsRootto Chris.Previously known as kAlug.
I think we may be taking things a bit in the wrong direction PAL-wise. Requiring devs to manually store and retrieve stuff when we could accomplish nearly everything with just 3 pairs (LastDrive to Drive, LastLauncherPath to LauncherPath and LastPortableAppsRootPath to PortableAppsRootPath*) seems like overkill. Those 3 things would cover everything we do in every single app we have released... and I know the 200ish apps I created and/or maintain really well. And most apps would use all 3. Honestly, I'd like to write a ReplaceAll FileWriteN type and LastAllPaths/AllPaths special variable that would handle those 3 replacements with a single INI entry. Nearly every app would use it and it would make creating and maintaining apps WAY less work.
If you want to get more advanced, it might be helpful to store the LastPortableAppsDocuments and PortableAppsDocuments (and Music, Video, Pictures) for the rare case where a user manually changes that path which we'll be supporting in the future.
I honestly can't think of a use for storing anything beyond that and the example given in that section of the PAL manual is trivial to accomplish with the above 3 variable pairs. If you'd like to keep the feature in for folks who want to use it and the few apps that may require, I'm all for it.[kAlug correctly pointed out that some apps will need local app paths stored between settings like APPDATA or LOCALAPPDATA] But requiring devs to have to do it all manually for standard locations just makes creation, debugging and maintaining launchers way more complicated than it should be.Let's the 3 of us have a chat about how to approach this before moving forward.
* in the above, PortableAppsRootPath refers to the path holding the PortableApps and Documents directories and the Start.exe if using the platform. Maybe PortableAppsParent makes more sense as a name.
UPDATE: Here's a real world example with an InkscapePortable.ini entry: http://pastebin.com/9AsYiNMi
Sometimes, the impossible can become possible, if you're awesome!
The code is already in place; I just need to document it and have some questions answered:
%sin the format specifier fine?PAL:Drivewithout a directory separator? What about adding it (or creating a new variable)?Previously known as kAlug.
There are a several apps that will store a drive letter in settings as
and not X:\. In those, we replace it with a preceding string for both the find and replace, something like the file:/// you included in the example. I believe Chris said he'd have his validator error on just using the %s bit for that entry without an additional string before it.
Sometimes, the impossible can become possible, if you're awesome!
1. You haven't answered any of my questions.
2. I was thinking on replacing it with the separator and then letting the user replace the no-separator drive in another
FileWrite. Sometimes the format will be just%s.Previously known as kAlug.
I've renamed some options:
Previously known as kAlug.
Sorry I didn't properly answer in my first reply.
If we go the ReplaceAll route with the Docs, Videos, etc directories, we could save a lot of time by checking if those relative paths have changed and, if not, skipping that replace and just doing the drive letter replace.
Sometimes, the impossible can become possible, if you're awesome!
PortableAppsRoot when we'll already replace PortableApps.comDocuments, PortableApps.comPictures,PortableApps.comMusic, PortableApps.comVideos and PAL:PortableAppsDir?
Previously known as kAlug.
Some users will likely create their own folders at that level outside the platform and I'd like to allow for that.
Sometimes, the impossible can become possible, if you're awesome!
Will be the names of those specific folders' (Videos, Documents, etc.) localized, or will be the user able to rename them? If not, wouldn't be possible for us to replace just PortableAppsRoot?
Previously known as kAlug.
They will eventually be localized. And users can alter them as well. I was considering just updated the PortableAppsRootPath, but if we also did Docs, etc, it would allow those to be altered/renamed and have apps still find files. I know it's a bit of an outlier. I guess it comes down to performance. But if we could have the launcher check to see if the paths in relation to the PARoot are unchanged (Example, videos is still at Document\Videos) to skip those replacements and just do the PARoot. A bit more coding work, but would make us able to handle the outlier case with no impact to normal performance. Make sense?
Sometimes, the impossible can become possible, if you're awesome!
What about opening the launcher.ini file and reading its first two bytes and then closing it every time we need to read a section with arbitrary values in order to check if it's UTF-16LE, like we do currently?
What I'm a bit worried is that, for every feature we add to the launcher, its source becomes a bit more unreadable (look at FileWrite; couldn't we refactor it?). But it's doable. So, Video, Music, Pictures, Documents, PortableApps, AppDir, DataDir and Drive (PortableAppsRoot isn't implemented yet)?
Refactoring-related: I think I've found a way to make the Launcher compiled (like the installer), using a PortableApps.comLauncher.nsh and a launcher.ini parser, so e.g. a
[FileWrite]:Type=Replacewould become something like!insertmacro FileWrite:Replace[CS] ${find} ${replace}(does any app uses the Encoding parameter?).I've stopped working on PAL for a while because I'm writing a guide on creating portable apps; could you point me to the rationale and history of the PortableApps.com Installer?
/* Yes, too many subjects for just one comment :evil: */
Previously known as kAlug.
Couldn't we just check the launcher.ini for UTF16LE once and remember it in a launcher-wide variable?
PortableAppsRoot doesn't exist yet.
Ummm... is there supposed to be a rationale for the PA.c Installer? It's mostly been worked on one the fly with no overarching plan. Heck, it started out before we even used LogicLib.nsh, so it still has bits from before that in it. It could probably stand a rewrite at some point, especially considering some of what I'm adding (language-switched download URLs and MD5s, etc).
Sometimes, the impossible can become possible, if you're awesome!
The macro which checks for UTF-16LE is generic. It default for the lancher.ini, but can work with any other app. In orderr to skip the check, I would need to be able to copy and compare file handles (are them just integers?).
So, [we are going to replace the variables for] Video, Music, Pictures, Documents, PortableApps, AppDir, DataDir and Drive? (PortableAppsRoot [isn't in the list because it] isn't implemented yet.)
(Haven't time to write anymore)
Previously known as kAlug.
Yes, that would be the list. We may not need a separate PortableAppsRoot var handled. It could just be the parent of PortableApps in this replace procedure.
As for file handles, they are integers. But as the whole of the launcher deals with launcher.ini, couldn't you just check it once and then tell everything to skip the check? Heck, you could even do it with a launcher-wide var that all procs check called GlobalSkipUTFLECheck or similar.
Sometimes, the impossible can become possible, if you're awesome!
Custom code should be able to use that too.
As for refactoring, you mixed things.
Once I finish this Replace feature, I'll start refactoring PAL's code so we can made it compilable (and highly optimized: we won't need ForEachINIPair anymore :smile:).
Related to PAI, what I need is: why had you write it (in the very beginning)? i.e. I need something to add to the last section of this.
Also, do we really need [FileWrite]:Encoding?
Previously known as kAlug.
In the beginning, it was because we realized Zip files were simply insufficient for distributing apps. Upgrades were a big issue (since unzipping an app over an existing one wouldn't remove files that were no longer used and actually broke apps like Firefox). But distribution became an issue as well (folks with slower connections appreciated the smaller size of the EXEs). Being able to display an EULA on install as required (by Firefox, for example) was also a factor. There are some more details on the What is a portable app page: https://portableapps.com/about/what_is_a_portable_app
Sometimes, the impossible can become possible, if you're awesome!
I just want to chime in and say that I too dont understand why we'd be ditching Last*. I like it the way it is and I see no need to change it. Its easy to use and understandable from a logic point of view. And its a historically grown fact from the old times we had custom-fit nsi-launchers
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Rephrasing: "I do not see the need for new automatic
Last*environment variables; also remember it will hit the launcher's performance." (rephrasing that moment; does not necessarily reflect what I am thinking now).Previously known as kAlug.
Are there plans to handle temporary internet files in the future (if possible)?
That will be difficult if they are stored. When using the Windows browser component to download specific things, you can set it not to use the cache. We do that in the download component within the PA.c Updater/App Store for instance. But when you instantiate the browser within an app, it's just like opening up IE, so cache gets stored in cache. You might be able to redirect it by redirecting the whole USERPROFILE but that can cause it's own issues (breaks Desktop and may break Documents, TEMP is written to wherever you are, any apps launched from it will inherit that fake USERPROFILE, some PCs may not have permission to redirect it, etc).
Sometimes, the impossible can become possible, if you're awesome!
How do you set this component to not use cache? I peeked at the Updater source, but it looks to me like the only way your downloading is with inetc.
I modified the Inetc code to not use the cache as it's the Inetc C code that makes the actual API call to Windows to download stuff, not the updater's NSIS code. It's one of the settings in the API call. As far as I know, you can't set the browser component (embedded in your app) not to use cache.
Sometimes, the impossible can become possible, if you're awesome!
How should we go about doing these apps... should we consider cache as "personal data" and avoid making portable apps that use the feature, or do we ignore it and call it "automatically generated by windows"?
Because the app I'm talking about it Google Earth (there are a few others, as well) and, along with its own cache, it leaves a bunch of stuff in the temporary internet files folder, which I've always considered strange. I thought about just wiping that folder on each exit, but that may take some time and delete "(personal?) data".
It's a question worth considering. Temporary Internet Files aren't really personal data as, at most, they're cached web pages and images. They could, however, cache pages with personal details on it if a web server is misconfigured to allow said pages to be cached (assuming we're talking about browsing here). The only way to disable it for something like Google Earth would be to recompile the app, which is obviously not feasible. And since Google Earth wouldn't have any personal data in the cache, we could make exceptions for apps like that with a note about the cache on the app's homepage. Thoughts?
Sometimes, the impossible can become possible, if you're awesome!
Yeah, I like the idea.
I would feel better if the cache could be deleted / no cache would be created. For the paranoid of us, what place I looked up in Google Earth could be very personal. But on the other hand if its too much work, maybe its not worth the effort and finally if I am cautious, I wouldnt use google at all.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Considering that any network admin could easily track it, keeping the cache is no privacy intrusion at all.
Sometimes, the impossible can become possible, if you're awesome!
For example Cameyo and ThinApp ?
I've once dealt with ThinApped programs and them sometimes were making their own "Temporary Internet Files" in their on private folder that sits along this giant EXE file.
I don't know how this is dealt with in Cameyo.
So what I would to say is that it is possible, has been done, and I think doesn't need any recompilation, or maybe there programs really peek into program structure and change executable code.
The thing is that what if I run a portable app in multiple computers I would be leaving behind some garbage.
Both of those solutions virtualize the apps. And it's actually illegal for Google Earth to be distributed in either of their packages, so it's not something we could do even if we wanted to. Not to mention that ThinApp is $5,000 (+ distribution fees) and Cameyo is a bit buggy and has legal issues (they distribute TONS of illegal software in their online repository with the support of the Cameyo devs, so I definitely wouldn't trust their software). So, neither of those are in any way an option for a project like ours that only operates transparently and legally.
So, seeing as there are no free and legal virtualization options, we're left without virtualizing. We could redirect the entire USERPROFILE which would include the Temporary Internet Files, but that may cause other issues within Google Earth.
Sometimes, the impossible can become possible, if you're awesome!
So what about support for LocalLow? Google Earth has been saving in what appears to be %LOCALAPPDATA% in XP, but in reality is AppData\LocalLow in Vista/7. It might be possible to get the path with the SHGetKnownFolderPath function with with FOLDERID_LocalAppDataLow (as suggested by sar3th).
What's the status on this?
@Chris: I wanted to do some reorganization in the header files in
Other\Sourcebefore landing .NET support. I want to split the includes in three folders: those from other projects (external), code we developed (for PAL) and maintain ourselves but which can be used by others (reusable) and headers specific for PAL (internal).Previously known as kAlug.