I've been trying to stay out of this. I burned way too much time and energy on OS advocacy debates in the past (search for Kirvin on comp.sys.os2.advocacy in Google Groups to see what I mean) and as I pointed out in my column last year called "Parity", PalmOS vs Windows Mobile really has become a Ford vs Chevy kind of debate.
That said, there's some serious confusion out there about how Cobalt (the OS formerly known as Palm OS 6) will handle multitasking. I happen to think it's pretty slick and elegant, not to mention a far more efficient paradigm for resource-constrained handheld computers. So I thought I'd take a shot at explaining how Cobalt will handle multiple applications working concurrently and compare it to the way Windows Mobile does the same thing. I'll try to keep the technobabble to a minimum.
First, let's look at the incumbent (oh, come on, it's an election year here in the US). Windows Mobile splits available memory into two segments, Storage and Program. Storage memory is like your hard drive; this is where the system saves data by default and it's also where you install programs. The more programs and data you have, the less available Storage memory you have. The rest of your memory is Program memory. This is like RAM on your PC and it's were running programs reside. When you run a program on a Windows Mobile device, the program is copied from Storage memory to Program memory (and hence, while you're running it, it takes up twice as much space as normal) and it stays in both places until you or the system closes it.
When you tap the X in the upper right corner of the screen on a Windows Mobile device, Windows doesn't close the application. It minimizes it, leaving the entire program running in the background. When you start a new program. it's also copied into Program memory. The more programs you have running (all but one of them minimized, since the Windows Mobile user interface can't display two applications side by side like you can on the desktop), the less Program memory you have.
Windows Mobile makes the boundary between Storage and Program memory dynamic in the form of a slider that you can move back and forth on the Memory screen. I generally move it as far to the left as possible, minimizing my Storage memory, then installing new applications and saving data to a memory card instead of internal memory. This has a downside in that documents not in internal memory will not by synced to the PC by Activesync. I live with it, though, because Windows Mobile is Windows, and it runs better the more program memory you give it. But you have to be careful with the slider; it you move it too far in either direction, the system will pop it back to the middle automatically. The slider will also auto-adjust as the system needs. If you run a lot of stuff at the same time, the system will move the slider to the left, giving you more Program memory at the expense of Storage memory.
If you have a lot of applications sitting in the background that aren't doing anything useful, how do you get rid of them? The official answer is that you don't. Windows Mobile will automatically close applications that have been idle for too long once you start to run out of memory. At least, that's the theory. In practice, the system waits too long and you see your system performance bog down long before Windows starts closing down inactive applications. As a result there's a thriving market in applications that replace the Windows "Smart Minimize" button with a real close button, allowing you to terminate applications that don't need to be left open. If you want to close the application, tap the X, but if you want to leave it running, tap the Start Menu and run something else over it.
While the Windows Mobile method of running applications works well enough, it's far from the only way to do it. PalmSource has taken a different approach in Cobalt that should work just as well, if not better.
In Cobalt, applications are written to run in multiple "threads". This means that instead of having one big program, you have two or more mini-programs working together but somewhat independently. A music player would have one thread to control the main interface screen, a different thread to actually decode and play music, and perhaps a third to pop up a little mini-console to control the player when the main screen isn't your current application. A web browser would have one thread for displaying web pages and a different thread for going out on the web and fetching those pages into your local cache. The background threads of these applications (the fetch process for the browser and the decode/play process for the music player) tend to be far smaller and more efficient than entire applications to do the same thing.
When you run an application in Palm OS, the previous application quits. When I'm running pedit, Agendus is no longer running at all. In Cobalt, this is still mostly true. The difference is that background threads can stick around as long as they're needed.
Let me give you an example of how this works. Let's say I'm working with my new Tungsten T4 running Cobalt.
I start my music player and load up some Oggs for background music. I tap Play, then tap Home to go back to the launcher.
The music player's interface thread quits, freeing up memory and processor load, but the playback thread continues to run, allowing me to keep listening to my music even though I'm not technically running the music player.
I tap on my web browser and start loading a large page, say, a long flame-infested rant about Palms versus Pocket PCs. I'm pulling this over Bluetooth from a GPRS phone connection, so it's roughly dialup speed. I don't want to wait, so I tap and hold on the Home icon.
Because I'd used my email program recently, it's in the little pop up list of applications. I tap on that and run my email program.
At this point, the web browser isn't actually running anymore. The fetch thread is still running in the background, pulling down HTML and images and dumping them into my cache. When it's done, it will go away on its own and notify the attention manager that the page has finished downloading.
In the meantime, I've got my email program running. I tap button to send and receive, then tap on the Home button again, then run my word processor.
While the email program itself has quit, the download thread chugs away in the background and saves the emails to my email program's database. When it's done, it will also notify the attention manager.
Okay, by now, I've got two waiting messages while I type in my word processor. I know this because the Attention Manager icon -- a little asterisk in a box -- is flashing in the upper left corner of the screen. I can ignore it as long as I want, and if I'm working on something where I don't want to break momentum -- a lot of these column flow better if they're written in one sitting -- I can just keep typing. When I do want to see what else is going on, I tap on the flashing asterisk and see two messages waiting. One tells me I have five new email messages, and the other tells me the web page has finished downloading. I tap the link for the mail first.
My word processor exits and my mail program starts up again. Since the now-terminated download thread already saved my new messages to the mail database, they're here and ready to read. I read all five, and reply to one, then tap send/receive again. The message starts sending in a background thread, and I tap the attention manager icon (which is still flashing because I haven't addressed the web browser's message) and I use it to take me to the web browser.
The mail program's interface thread exits while the send continues, and I'm back in my web browser where I started, viewing the completely loaded page.
Now, from the user's perspective, how is Cobalt's method of multitasking any different from the way Windows Mobile does it?
It's not, really. In both systems the user is allowed to run multiple programs and get stuff done in the background while doing other interactive stuff in the foreground. The difference, and it's a subtle one, is that the Cobalt method is a little more efficient, which should lead to better overall performance.
That's not to say the Cobalt method is necessarily better, just different. The downside to the more efficient multitasking is that the applications have to be written to support multiple threads. Applications written for Palm OS 5 (now called Garnet) and earlier will not be able to take advantage of multitasking at all. The best they can do is automatically save where they were you quit and ran another application so that when you run them again, you pick up where you left off. In Windows Mobile, applications don't have to do anything special to multitask since that is handled by Windows Mobile itself.
So which way is better? Who makes better trucks, Ford or Chevy? But just as there's no real answer there because the two companies are so evenly matched, there's little difference in the power and flexibility in the most recent versions of Windows Mobile and Palm OS.