The Tower of Babel in the Land of PortableApps.com

Starting summary

We're switching the Menu from Delphi at some time, it's best if we do it soon, before it becomes too big a job, and also to get into the cross-platform market quickly; currently the best-looking options are C++/wxWidgets and PHP/PHP-GTK. (For launchers as well as the whole Platform.)

Feel free to skip my discussion of Manta.

Manta

Some of you may know that I have long disliked the sort of solution XAMPP is, and that I planned to create a "real" web server solution, built with modularity in mind, easily configurable, with packages for everything under the sun from Apache to IIS (Windows only, not compatible with The Portable Switch on), from PostgreSQL to SQLite, from concrete5 to Drupal to Wordpress to Plone to Django, from Python to PHP, and you get the idea. That has been forming, and is under development: it's called Manta. Anyway, that's not what I'm writing this about. Think of it as free advertising if you like. But moderators, don't delete that link yet, I'm going on to explain the significance of it.

While preparing to start on Manta though, I had to decide for myself on what to language to program it in; I looked at a number of options; I wanted something small, easily extensible, and cross-platform. For languages, I only looked much at four; C++, Java, Python and PHP. Java I swiftly discarded, as for most web server users a JRE or JDK will be overhead to the order of 100MB (for some users it would be no overhead, namely users of Tomcat, Glassfish, and other Java programs). With C++ it is possible to use a DLL system or something else to make it extensible, but without quite a bit of work, it's not all that extensible how I wanted it. So that left Python and PHP - though I could also have looked more at Perl or Tcl/Tk or Lua, but I know nothing about them, while I know some about C++ - and experience would be good for the future, quite a bit about Python, and am perfectly at home with PHP.

Languages and GUI toolkits

I decided to look at GUI toolkits first. (Disclaimer: all filesizes here are just as I remember them, and are not necessarily terribly accurate.) I looked at wxWidgets, Qt and a little bit at GTK (and also WinBinder for PHP, but it's not very good and Windows-only); Qt is very big (often 30MB, and I couldn't compile PHP-Qt immediately so I left it), wxWidgets is somewhat smaller (8-12MB, and wxPHP is practically nowhere), but GTK is the smallest (only 7-8MB). For languages, C++ will naturally produce the smallest options (though PHP compiled with Roadsend should compete pretty well as it compiles the code rather than including it along with a PHP compiler bundled up), and PHP is fairly small (1-2MB), and Python is larger (5-6MB compiled). Anyway, to cut a long story short, I ended up deciding on the not-very obvious combination which I tried last of all (I'd been focusing on Python for some reason), and did not turn back from.

PHP-GTK.

Total overhead for users (thus users who won't be using PHP at all in their server environment): about 8MB (after UPX). This is a couple of megabytes smaller than any other "serious" combination (compressed and compiled wxPython apps weigh in at about 10MB, c.f. Task Coach Portable, 10MB, and BPBible Portable, 12MB as it includes the SWORD API which is a couple of MB), excluding C++. While this may not seem small, it's worthwhile remembering that you can then run any PHP or PHP-GTK thing (plus any extensions needed) for that weight (perhaps you are starting to get my meaning). And the overhead is nothing at all (Manta source excluded) for Linux users with GNOME, who will be using PHP for their Manta-based web server.

To finish off my Manta section in here, PHP-GTK really is quite nice to work in, and I've made quite a lot of progress with Manta in it. Anyway, now I'm up to dealing with the thing which is relevant for this post: PortableApps.com.

Feel free to start reading this article from this point.

Recently, John has been mentioning the possibility (probability long term) of changing the programming language and GUI toolkit used in the PortableApps.com Platform, and that got me to thinking (a dangerous thing at the best of times). Last I heard, he was favouring wxPython, and it's a perfectly good solution, but I don't like it all that much (don't bother asking why, I have no real reason). If you don't use a compiled version (i.e. py2exe), you've got yourself a 30-40MB overhead (all compiled, it's only 10MB... still larger than PHP-GTK unbundled). I'd like to propose PHP and GTK as one (less obvious) solution, and my reasoning follows.

Launchers

Currently all our launchers are all NSIS launchers; the "new family of launchers" - i.e. the generic PortableApps.com Launcher which John and I have been working on, is also NSIS, but configured by INI files. However, although it's a great idea, and a step in the right direction, having looked at more launchers for my work in this area, I don't think that this comparatively simplistic technique is enough. Sometimes you need more logical ordering for things (see the BPBible Portable launcher), which need to be done in a given order of INI setting, file replacement, etc., and sometimes things are just too complex (see the OpenOffice.org Portable launcher for a very good example). Before I address that, I'll add the pro of our current system; you can start applications just by running the executable AppNamePortable.exe. However, this is not the be-all and end-all of our work. One thing that has occurred to me is launchers with a PortableApps.com script file with functions/macros/etc.; this could be done in several languages.

• NSIS: PortableApps.comLauncherRuntime.nsh, with all the functions we need so that it can become a matter of a few lines to code something up, very similar to how my PortableApps.com Launcher tests have done it - e.g. ${MoveDirectory} Data\settings $APPDATA\AppName, and then have it keep a list of those changes (similar to how LogicLib does it), so that at the end, you just insert a macro or have an invisible section or something to move everything back etc. We'd still have executables as the basis for running things.
• C++: PortableApps.comLauncherRuntime.cpp (and .h I presume), similar to above, but with different techniques (functions, possibly via hooks, I dunno yet). We'd still have executables as the basis for running things.
• PHP/Python: PortableApps.comLauncherRuntime.(php|py), same as with C++, but with storing the PHP/Python runtimes in CommonFiles, or PortableApps.comRuntime, or anywhere. Note also that the PortableApps.com Platform could use the same runtime (though of course if it were Python you were dealing with you'd want to be careful about techniques, you wouldn't want to use py2exe at all, just from the source distribution, and that's pretty hefty, and has lots of files, while PHP is more consolidated, with only a couple of dozen or so files all up, even with PHP-GTK). We could have a simple C++ executable to launch the interpreter with the launcher file if we wanted, thus preserving current functionality.

Now I'll conveniently assume we've moved to PHP for this argument. Our launchers could be included from inside the PortableApps.com Platform if it were also PHP-GTK, but there's a problem with this - in PHP you can't catch fatal errors (the closest you get is output buffering, see this technique as reference; it's not easy or necessarily safe to continue though.), so you'd (probably) want to fork php-win.exe for each new launcher to make sure that the menu didn't "crash" when you opened some program.

Platform

it's written in Delphi at the moment, and that produces fairly small, Windows only packages. PHP-GTK would make bigger (Windows, Mac OS X, Linux w/out GTK) programs, but they'd be cross-platform, and easily modifiable, which is a great pro. Also I think you'd be more likely to get people offering help (a mixed bag), I for one would really want to help, and be able to too (a change from the current system where John's the only one who can do anything, as it's using a build system which costs money, and isn't for sale any more either (leastways I can't find Delphi 2006 for (legal) sale, and I seem to recall John saying it didn't work with Delphi 2010)...

Updater/Application Manager

Also things like the PortableApps.com Updater could be done much more efficiently in the other languages than in NSIS; I've already been making for Manta a lot of that functionality, with its package manager (PortableApps.com's could be much simpler, needing no dependency management or application configuration).

Conclusion

Wow. This is waaaay longer than I planned on making it. Hopefully you've read far enough to read this. Anyway, I think I've gone on enough for the moment, running out of things to say. I would really like comments and questions.

P.S. this is a very long post, and is discontiguous in spots, sorry about that.