For Christmas I received a 1 GB Lexar JumpDrive. It's basically just a keychain-sized flash memory card that interfaces via USB. These are pretty common and are also known as pen drives or flash drives. You just plug it into any computer's USB port and it will (hopefully) be recognized as a form of removable media—like a floppy disk. I had seen these around but never pictured myself owning one until it actually came into my possession.

After using it for about a week, it became nearly essential to my computing experience. I no longer had to use Remote Desktop just to run a few Windows applications with my favorite settings. I could just plug the drive into any computer and be able to browse with my own customized Firefox, or listen to music with my favorite media player (and even keep the music on there, too).

Unfortunately, there are a few issues standing in the way of such desired portability (that is, being able to use a program—to its fullest—on any machine without the need for an installation procedure). In order to shed some light on this topic, I will:

  • discuss a few problems found in many applications
  • show you how I used a portable scripting environment (Python, if you're interested) to solve a common portability issue
  • offer some proposals for applications which would lend themselves nicely to portability
  • mention a few projects and programs that Do It Right™

The context will mostly be Windows-specific, as that is where the aforementioned issues tend to arise. This entry is going to be relatively long, so I only suggest continuing if you're interested in any of the items above. Now, read on—especially if you own a pen drive.

The demand for portable applications seems like the most promising use-case for pen drives. Sadly, it's also the most restricted! Most applications are simply not portable. Incompatible applications rely on registry settings on the local machine, or store information at an absolute path, or persist by using any other method of machine-dependent storage. This includes the majority of Windows applications. Since pen drives are meant to be used with any computer, the local registry and the drive letter assigned by the OS will rarely be the same from machine to machine.

Thankfully, with the increasing popularity of pen drives, an application's portability has become a more important consideration. John Haller managed to make portable distributions of both Mozilla Firefox and Thunderbird, appropriately naming them Portable Firefox and Portable Thunderbird. Michael "Fuzzyman" Foord and Bruno Thoorens packaged some common Python modules and IDEs into a portable Python environment called Movable Python. Being a frequent Firefox user and both a casual and occupational Python programmer, these distributions are the first I sought after.

On the multimedia side of things, foobar2000 (for music) and Media Player Classic (for video) have proven to be both portable and light-weight. In fact, they're what I use anyway, regardless of portability. Note that codecs used by Media Player Classic may turn out to be machine-dependent.

For communications, Miranda IM is not only the best portable AIM client I've used, but also the most customizable.

And as for remote access, the entire PuTTY suite exists as a collection of stand-alone binaries. It also may be beneficial to copy the Remote Desktop binary (mstsc.exe) from your local Windows installation onto a pen drive, even though it is fairly ubiquitous. For portable FTP access, I recommend the nice freeware client FileZilla.

Now, having these applications with me wherever I go is all well and good, but sometimes using them is a bit of a pain. The reason is that Windows shortcuts have no support for relative pathnames. Windows users are accustomed to using shortcuts to run their programs instead of manually locating the executables. But on a drive whose mounting point (drive letter) changes between machines, creating shortcuts is simply not an option. The pathnames referenced by the shortcuts will need to be updated every time the drive letter changes. One common workaround (if you don't want to go hunting for executables) is to launch portable programs using batch (.BAT) files, which support relative pathnames. Having been spoiled by Windows, I hate doing this because batch files can't use the application's icon. More importantly, it requires making a batch file for every program you want a 'shortcut' to.

Thankfully, the portable scripting environment provided by Movable Python offered me the chance to fix this problem. Using the pywin32 extensions with Movable Python, I was able to write a script that fixes all shortcuts on a pen drive appropriately when run from the drive.

The script is pretty simple, but if you intend to use it there are some things you should know. These are documented within the script.

You can find the script here.
The batch file I use to run this script with Movable Python is here.
This allows me to run the script each time I plug the pen drive into a different machine and have valid shortcuts for the rest of the session. You'll have to modify the batch file to (relatively) point to your Movable Python installation on the drive. By default the script will fix shortcuts located in the pen drive's root folder.

Using autorun.inf, I tried unsuccessfully to get this batch file to execute automatically whenever the drive is plugged in. Maybe someone else can get it to work.

While writing the script I ran into some issues with using the pywin32 extensions with Movable Python. The majority of my discussion with Michael Foord about these issues can be found at this page. The end result is that there now appears to be a Movable Python distribution which includes working pywin32 extensions by default.

There are a couple other, much more difficult applications I'd like to see built in the name of portability. It's likely that these aren't even possible due to protected memory and whatnot, but I will propose them anyway.

Number one, a per-application version of Remote Desktop. Often I will use my AIM client on a Remote Desktop session even if I have the executable locally. This is simply because if I have to shut down my laptop, change locations, or lose network availability, I still want to keep myself available and my conversations open. A per-application version of Remote Desktop could be restricted to the selected application's viewport and event context. The session wouldn't even need to necessarily 'take over' the whole machine like Remote Desktop currently does. Disconnecting the session would leave the application in the same final state on the remote machine. I don't think VNC allows for this kind of functionality, either. It is available on UNIX-like platforms, but I think only for command-line executables.

Number two, a way to page application memory to a specific, manageable location on a disk (i.e. a pen drive) for the purpose of state saving. This functionality partially exists to support Suspend/Sleep/Hibernation mode on many desktops and all laptops. This would simply need to write an application's memory space to disk. All state information—even, I think, down to what position a window's scrollbars were in—could be saved and reconstructed upon request. However, I'm not sure how much of a hacker it would take to write a program which could access the necessary memory.