You are here

The Tower of Babel in the Land of

Chris Morgan's picture
Submitted by Chris Morgan on September 4, 2009 - 4:16am

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.


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.


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:

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 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.


Currently all our launchers are all NSIS launchers; the "new family of launchers" - i.e. the generic 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 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 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 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 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 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.


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 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 ('s could be much simpler, needing no dependency management or application configuration).


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.


Chris Morgan's picture

John has said a couple of times that post-installation compression is not practicable due to drive speeds et cetera. It seems to me that there's one facet of this which has not been explored, so I'm going to explore it here.

(This post is really more discussion of all sorts of things in general to do with languages, and future change... I think that this fits in here.)

Compression doesn't need to take place on the [USB] disk - it's quite feasable to extract to $PLUGINSDIR, and then to compress things there and copy them out. A possible option would be a components page entry, "Compress app" (I wonder, does NSIS support a negative section size with AddSize? Otherwise it'd need to be "Don't compress app"). This would make installation take longer, but it would produce smaller downloads as well. Possibly just worthwhile thinking about some time in the future, when the language is changed. Again, there are pros and cons of it. On both sides, it only affects the time of installation: smaller download, but longer install time.

More the reason why this could fit in with this discussion here is that UPX could be a good addition to a Runtime (as a runtime included with the platform, that is, rather than a development library).

Once again, I would like comments and questions... feel free to say that you hate PHP and why would you ever use it for a desktop application, and that GTK is horrible, and why would you ever use it, etc. etc. Do try it first though Smile (GTK can't be that bad... the GNOME desktop is written with it, and it's used in various popular applications such as GIMP and Inkscape.)

I'm sorry if I've got people upset by this blog post, I didn't intend it that way at all. I'm just trying to catalyse discussion, and suggest a possibility which is not obvious 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

Simeon's picture

I liked reading through your thoughts. First, I have to say that I don't know anything about programming except for NSIS. Sad That's not much but it allowed me to make some Apps portable so I think its worth something. Smile

I know that other programming languages are way more powerful and might be easier to use, but does that justify a complete rewrite?

The upside would be "cross-platform-ability" but as most Programs are windows, that might not way in so much. On the other hand it could be a first step in the multi platform direction, something that would be rally cool for windows-linux-users like myself!

So in conclusion, I like the idea for the future, but I wouldnt like to see it happen soon because I fear the additional lag it would bring to the development because of the rewrite.

"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate

Chris Morgan's picture

Thanks for commenting, Simeon Smile

John has said in one or two (or is it none?) places on the forums that it's going to happen some time, and in IRC a few times it has been discussed briefly. So the question is not so much whether we do it as how do we do it - that's what I'm trying to help facilitate here. I would imagine that we would then have some platform-specific applications (Windows only, Linux only, Mac only) but I tend to invisiage more a thing where for e.g. Java applications they're all together, and for other types, have it so that you install the Win32 version, install the Linux version, install the Mac OS X version into the same place if you want more than one platform. However, that's quite a way in the future.

A complete rewrite will be necessary, yes, but that won't take as long as writing the original application... in fact I think that if doing a rewrite, it might even end up with some of the future features coming in earlier because they're easier to integrate when writing it that doing it all and then fixing it up (as an example, integration of an application getter more powerful, but simpler than, the NSIS Updater). I think the best way for a lot of it is to have John continue on with the Platform as it is, while "others" port it to C++/wxWidgets or PHP-GTK or whatever we decide on. Branching. Then, if a new release of the Delphi version comes out, you can forward-port them to the new version. In my opinion they could be simultaneously managed without much retardation of progress. Currently John's been so busy with the other things of that we haven't been getting new releases of the Platform as fast as usual anyway...

I for one would be quite willing to pause development on Manta to start porting the Platform to PHP-GTK. C++ and wxWidgets I'd be slower on as I'd need to pick up more C++ and wxWidgets on the way.

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