Chris's code-related ideas, plans and proposals

This page is mainly for me to note down ideas that I have, which will be mainly about the PortableApps.com Universal Launcher, PortableApps.com Installer and similar related things (I can't help with the Platform yet so I won't try to offer suggestions). I'll continue to update this page as I develop code for my ideas and as I come up with more ideas. Feel free to comment on the ideas.

Ideas and plans

Contents:

• Spaces in path fixer
• Long path fixer
• Moving the application to a different directory
• Unified Subversion password management support
• Unified Qt registry support
• UNC paths

Spaces in path fixer

(PortableApps.com Installer, PortableApps.com Universal Launcher)

At least one of our applications doesn't work with spaces in its path (Stellarium Portable). The solution with it is that the launcher pops up an error message box if you run it with spaces in the path. This could be improved with an extra thing in AppInfo to specify applications which can't cope with spaces in paths; then the LeaveDirectory function in PortableApps.comInstaller.nsi and the Universal Launcher could pick this up, so that you can't install it to a location with spaces, and to make it much easier to block running where it'll just crash.

Long path fixer

(PortableApps.com Installer, PortableApps.com Universal Launcher)

As above with detecting problems with spaces. In the PortableApps.com Installer wizard, scan the App directory to find the longest path that it will have to deal with, and then add a snippet to the LeaveDirectory function in PortableApps.comInstaller.nsi to complain if they specify a directory longer than 254-StrLen path characters long. For example, in OpenOffice.org Portable the longest path name is App\openoffice\share\uno_packages\cache\registry\com.sun.star.comp.deployment.configuration.PackageRegistryBackend\registry\data\org\openoffice\Office\Linguistic.xcu (165 characters) so it would restrict the installation path to 89 characters (89+slash+165=255 which is the longest safe path length). What's more, also this length should be placed somewhere where the PortableApps.com Universal Launcher will see it (putting it into AppInfo seems a good idea, maybe we could have a section [Limitations] which the installer wizard would add it to) and complain if it's too long (as with the above space-in-path). This would also tie in with portable application directory moving.

Moving the application to a different directory

(PortableApps.com Universal Launcher)

Many of our applications (Songbird comes to mind) can't cope with them being moved to a different directory. Drive letters we can cope with, but sometimes we won't be able to cope with moving. Plan A: make it so that the PortableApps.com Universal Launcher (and our implementations with the Launcher) will always update all paths. Nice idea, but I'm not sure if we'll be able to handle it too easily. I'll see. Plan B: make the launcher detect when it goes to a different path (not just drive letter) which is easy, and then warn the user that it may not work because they did that, are they sure the want to continue? We could also do it as a field in the launcher configuration, so that the launcher will "know" that it will work fine (ignore), or there are side-effects (warn) or that it won't work (stop them before they corrupt things).

Unified Subversion password management support

(PortableApps.com Universal Launcher)

Currently we have a couple of applications in development which work with Subversion. My own Subcommander Portable [2.0 Beta 4] currently doesn't keep saved passwords with it (which is bad), and gluxon's Eclipse does, but there is a problem when we have multiple applications which "do anything" with Subversion passwords. If you tell the SVN client to save the password you enter, it will be saved (by the SVN client backend) in $APPDATA\Subversion (and you can't get round it with any environment variable changing). Thus we can see that the data has to be backed up and moved, the way we do with various things. Now let's pose a scenario; I fix Subcommander so that it backs up to $APPDATA\Subversion-BackupBySubcommanderPortable, while Eclipse still uses $APPDATA\Subversion-BackupByEclipsePortable.

1. Open Subcommander Portable [SP]. Local settings in -BackupBySP, SP saved passwords local.
2. Open Eclipse Portable [EP]. Local settings in -BackupBySP, SP saved passwords in -BackupByEP, EP saved passwords local.
3. Save passwords, use saved passwords, get things all muddled further...
4. Close SP [warning bells ring... closure not nested]. EP passwords in SP (!), local passwords local, SP passwords in -BackupByEP.
5. Close EP. EP passwords in SP, local passwords in EP, SP passwords local. Whoops. Big security hole there.

This is pretty obviously a problem. So I need to write a snippet of code which will backup to a consistent location, and store Subversion settings in a common location - I reckon that CommonFiles\Data\Subversion would be a good location. The applications will then find one another (write a file in $APPDATA\PortableApps.comSubversionSupport.dat which will identify all the applications using it), and if we get applications which will be using different sets of Subversion passwords (e.g. F:\PortableApps\SubcommanderPortable and then run G:\PortableApps\EclipsePortable), don't copy the new lot of passwords across and just warn the user that any passwords used will be a different set of saved ones or something. This bit is the hard bit to do well. On closure of all applications with a line in this $APPDATA\PortableApps.comSubversionSupport.dat, the last one will move the files back to CommonFiles\Data\Subversion and restore $APPDATA\Subversion-BackupByPortableApps.com.

Unified Qt registry support

(PortableApps.com Universal Launcher)

I need to investigate this problem a bit more to come up with definitive answers. I wrote a simple code snippet for dealing with a lot of this here (there, now I can't lose that again so easily), and mainly just need to extend that a bit. The customColors thing will need a bit more looking at.

UNC paths

(PortableApps.com Universal Launcher)

None of our applications which do anything changing drive letters support UNC paths (\\computer\share\...); the way we do it all is just unconducive to network paths at all.

StrCpy $0 $EXEDIR 2
${If} $0 == "\\"
    MessageBox MB_OK|MB_ICONSTOP "$(LauncherNoUNCSupport)"
    Abort
${EndIf}

The LangString LauncherNoUNCSupport would be "$PORTABLEAPPNAME can not run directly from a network path and will now close. Please mount $PORTABLEAPPNAME to a network drive and try again."

Also while thinking of this, I found that we've used MB_ICONEXCLAMATION for our "can't start" type messages. I think we should use MB_ICONSTOP which is much more accurate.

Proposals

I think it could help if we add a [Limitations] section to AppInfo\appinfo.ini (or maybe a new file, AppInfo\limitations.ini). This is particularly related to the first three plans above. It will have a few values in it (and more can be added as needed):

• ForceNoSpaces=false|true (default false) - when true this one will make the installer refuse to install to a path with spaces in it, and the launcher complain and refuse to run in a path with spaces in it.
• InternalPathLength=integer - this one will be set by the PortableApps.com Installer wizard, to an integer equating to the length of the longest path needed, so that the installer can refuse to install and the launcher refuse to run, in a path ($INSTDIR for installer, $EXEDIR for launcher), the StrLen of which is longer than 254-InternalPathLength characters. This value will not be for developers to set, it will be for internal use only.
• SupportsDirectoryMoving=no|partial|possible|yes (default possible). The launcher will store in Data\settings\AppNamePortableSettings.ini the last directory it ran in and if it doesn't match (ignoring drive letter) with the current one, then: switch SupportsDirectoryMoving { case no: pop a message box saying it won't work until they move it back and save them from corrupting their data; case partial: warn them that it will probably break something and ask if they really want to continue; case possible: warn them that it may or may not break things and ask if they really want to continue, case true: continue; }

Update notes:

• 3/11/2009: initial content
• 21/11/2009: added "UNC paths"