This release improves the runtime state saving mechanism which was introduced in version 2.1, to improve stability and decrease the probability of portable apps getting stuck in a non-functional state which could occasionally happen. Several other minor but significant alterations have been made, as described below. To normal portable app developers, there will be no apparent changes, except for the desire that all apps now be checked for support of UNC paths. More significant changes are underway for 3.0 (the next planned non-maintenance release).
The starting/stopping checks introduced in 2.1 were switched from using the RuntimeData INI file to using mutexes. This change allows system-wide blocking of apps in those phases, where the current method works installation-wide, i.e. it will not work if you run the same app from different directories.
A new pair of directory environment variables, PAL:LastPortableAppsBaseDirectory and PAL:PortableAppsBaseDirectory, have been added. These allow developers to replace the path to all the PortableApps.com-related directories in a single pass. (The variables are available for use in custom code also.)
Running the launcher from UNC paths (i.e. unmapped network shares, of the form \\server\share\etc) is now supported; however, because there is risk of data corruption if an app doesn’t take care of such paths correctly, for now running portable apps from UNC paths will trigger a warning. It’s up for each developer to determine if their portable app supports UNC paths correctly and set [Launch]:SupportsUNC accordingly.
In view of this change, app developers should avoid using PAL:DriveLetter as its value is meaningless on a UNC path. If you have a case where you wish to use it, please contact the PAL developers and explain the situation, as they wish to gain an understanding as to what is needed here.
In former times portable apps would not always complain if they were run from the system’s Program Files directory, leading to quite a few support requests over time where people had installed their portable apps to Program Files, not realising that this wasn’t supported and didn’t work properly, wondering why it wasn’t working properly. This situation has now been remedied, and the PortableApps.com Launcher will now forbid execution from the Program Files directory (in line with a change in the PortableApps.com Installer forbidding installation into this directory).
Enter search terms or a module, class or function name.