Writing On Your Palm Says it's "Ford vs. Chevy"

[Jason Dunn]

<div class='os_post_top_link'><a href='http://www.writingonyourpalm.net/column040315.htm' target='_blank'>http://www.writingonyourpalm.net/column040315.htm</a><br /><br /></div>"Since PalmSource's DevCon last month, there's been a lot of bickering about PalmOS Cobalt's ability to multitask compared to Windows Mobile. It's not really an issue, and here's why. 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.<br /><br />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..."<br /><br />Jeff has put together an interesting article here, and it's worth the read (PalmSource was certainly clever in their implementation), but I don't agree with his conclusions for one simple reason: Palm is relying on developers to write a specific type of code to make their apps work in a specific way. That's all fine and well, but let's face it, not all developers will do that. I don't mean to offend developers out there, but the reality is that not all of them write clean code and do things the way they're supposed to be done. On my Motorola MPx200 Smartphone, if I leave a certain game running in the background (there's no exit function of course :roll:), my battery will drain from full to dead in less than 24 hours. Relying solely on developers to get things right can be a risky proposition. :?

[Ed Hansberry]

In playing around with Seymour that allows Pocket PCs to see two apps simultaneously in a split window view, it occurs to me that OS6 simply won't be able to do this as it doesn't support multiple foreground apps. Given devices like the larger Sony's with lots of screen real estate, that is a shame.

[juliankay]

Hey Jason, just out of interest, what programs make your MPx200 run out of battery power so quick? I've had the same thing quite a few times and I can't work it out!![/u]

[joelevi]

Hey Jason, just out of interest, what programs make your MPx200 run out of battery power so quick? I've had the same thing quite a few times and I can't work it out!![/u]

Same question here... and is it only a SmartPhone app, or could some of us PPC users have it and be draining our batteries, too :confused totally:
:microwave:

[PatrickD]

I would rather have the OS handle the multitasking rather than rely on developers to break their applications up into threads. While it may be more efficient in theory, it may also be more complicated and troublesome than its worth. I would like to see Microsoft forget about dividing RAM into storage and program areas. Just put a 20gig micro drive inside and leave RAM to be used for ... well RAM :wink:

[Jeff Kirvin]

Jeff has put together an interesting article here, and it's worth the read (PalmSource was certainly clever in their implementation), but I don't agree with his conclusions for one simple reason: Palm is relying on developers to write a specific type of code to make their apps work in a specific way. That's all fine and well, but let's face it, not all developers will do that. I don't mean to offend developers out there, but the reality is that not all of them write clean code and do things the way they're supposed to be done. On my Motorola MPx200 Smartphone, if I leave a certain game running in the background (there's no exit function of course :roll:), my battery will drain from full to dead in less than 24 hours. Relying solely on developers to get things right can be a risky proposition. :?

And I might argue that this is precisely the reason the PalmSource method is better for battery-driven, small-screen devices. A poorly written program can't monopolize the system in the background. If it doesn't have a damn good reason to be in the background, it simply terminates when you run something else.

Per Ed's comment, yes, something like Seymour would be nice on a HVGA screen, and it doesn't look like that will be possible in Cobalt. However, for brevity's sake I didn't go into everything in my column. Cobalt will also support a new kind of "applet" called Slip applications. These are small pop-up windows that appear at the bottom of the screen and allow access to background threads without actually running the entire full-screen UI again. Slip windows can house pretty much anything, so I expect to see the full gamut of clocks, memo pads, quick PIM item entry, even ebook reference available so you can do these things without terminating the current application. This also solves your "copy an address from email to PIM" problem since you'd be able to run a "new contact" Slip window over the email application and copy and paste that way. The Windows Mobile analog would be using Seymour to run Inbox and Contacts.

Per Jason's comment about developers, I agree, wholeheartedly. Cobalt's multitasking depends on developers doing the "right thing" with regards to writing clean, multithreaded applications. The vast majority of applications out there now will not multitask (ignoring the Garnet applications like Aeroplayer and Audible which do play in the background and other apps like pToolset which use Notification Manager to pop up when needed). Developers will have to write Cobalt-friendly apps for this to really take off. It's not unlike the transition from Mac OS9 to OSX in that respect.

That said, the developer at Astraware who wrote Bejeweled was able to port it to ARM-native, Cobalt-friendly code in about four hours. PalmSource has made this transition very easy, and I expect the "big name" Palm apps to have Cobalt-ready versions on the market before Cobalt devices hit the shelves.

[jmarkevich]

I'll have to see how it works. Multitasking still scares me, in the handheld sense...

However, it seems to me like the default "sloppy-developer" option is to NOT be multitaskable. You need to make the extra effort to write non-GUI threads, which should have a good reason to multitask (syncing, mail, network, music, whatever).

I never considered this approach, it makes good sense, from my armchair. Now let's get it into some devices and SEE.

[Sven Johannsen]

......if I leave a certain game running in the background (there's no exit function of course :roll:), my battery will drain from full to dead in less than 24 hours. Relying solely on developers to get things right can be a risky proposition. :?

See, there. The guy does it 'right', and you don't like that either. :wink:

[Zack Mahdavi]

That said, the developer at Astraware who wrote Bejeweled was able to port it to ARM-native, Cobalt-friendly code in about four hours. PalmSource has made this transition very easy, and I expect the "big name" Palm apps to have Cobalt-ready versions on the market before Cobalt devices hit the shelves.

Jeff, I completely agree with you. There will be some programs that will never be updated, but the developers that want to make money will definitely upgrade their programs.

It sort of reminds me of the transition from 160 x 160 screens to 320 x 320 screens. The developers that wanted to entice people to upgrade or to keep using their products were the first to support the high resolution screens. The same has been happening as developers work their way to support 320 x 480 screens.

It sounds like a big transition, but just like the Mac OS 9 to OS X transition in 2001, this transition for Palm will guarantee that they will stay competitive for years to come. One thing we don't want is for Microsoft to get a monopoly in the handheld market. A monopoly in a market leads to a loss of innovation.

[dorelse]

My confusion comes in when I think of IM's...will a Cobalt version of say Yahoo IM be able to stay 'active' (I mean actively logged into Yahoo IM, and show me as logged on to my IM contacts) while I'm surfing the web, as well as allowing me to run AOL IM, MSN IM all at the same time, all actively showing me as online. Etc. (which I can do today with a PPC)

(I'm assuming I'm using a Wifi Cobalt PDA btw.)

My assumption has gone from no, to Yes, with the following caveats...they must be coded properly for Cobalt to keep those thread as background thread, and they'll need to generate a Slip window so I can flip back to them when I wish to send an IM? Is that correct?

[Jeff Kirvin]

My confusion comes in when I think of IM's...will a Cobalt version of say Yahoo IM be able to stay 'active' (I mean actively logged into Yahoo IM, and show me as logged on to my IM contacts) while I'm surfing the web, as well as allowing me to run AOL IM, MSN IM all at the same time, all actively showing me as online. Etc. (which I can do today with a PPC)

(I'm assuming I'm using a Wifi Cobalt PDA btw.)

My assumption has gone from no, to Yes, with the following caveats...they must be coded properly for Cobalt to keep those thread as background thread, and they'll need to generate a Slip window so I can flip back to them when I wish to send an IM? Is that correct?

Yes, that's correct. A properly-written IM app for Cobalt will keep all your login threads alive in the background and pop up a Slip window to write messages. It would probably use Attention Manager to let you know when new messages come in (currently a flashing * in the upper left corner, but this should be a button on the toolbar in Cobalt).

[djdj]

This article actually brings up a question...

I thought that Windows Mobile didn't have to copy the executable file into program memory if it is stored on the device's internal storage memory. I was under the impression it could be run directly from storage memory, using only as much program memory as needed for dynamic storage of documents, variables, objects, etc. I thought I remembered reading this somewhere once upon a time.

Onto the lazy developer issue...

While it may be true that lazy developers will lean towards writing single threaded apps, this could be made much easier if the development tools are designed properly... If, for example, it was made very easy to divide the application into multple threads and exchange data between them, the chance of a lazy developer actually writing a multithreaded app are much higher.

I can't claim to know the first thing about the development tools for Cobalt, but if I was to guess I'd say that there probably isn't anything like that out there yet, but given time there might be. Such a tool would be welcome on the WM side as well.

I have to admit that I like the idea of multithreading apps whenever possible as suggested in the article, but being a developer myself and knowing just how hard it is to get multiple threads to behave nicely together, I can appreciate the amount of work that it takes and can easily see how most developers will just choose to avoid it.

[Doug Raeburn]

This article actually brings up a question...

I thought that Windows Mobile didn't have to copy the executable file into program memory if it is stored on the device's internal storage memory. I was under the impression it could be run directly from storage memory, using only as much program memory as needed for dynamic storage of documents, variables, objects, etc. I thought I remembered reading this somewhere once upon a time.


That's correct...

"XIP stands for Execute in Place. XIP means that a program is stored in rom or flash and it is actually executed right from the rom. Microsoft has extended XIP to also refer to the ability for specific areas of the flash rom to be updated without updating the whole flash rom at once."

http://www.cewindows.net/faqs/pocketpc2002xip.htm

[Jeff Kirvin]

This article actually brings up a question...

I thought that Windows Mobile didn't have to copy the executable file into program memory if it is stored on the device's internal storage memory. I was under the impression it could be run directly from storage memory, using only as much program memory as needed for dynamic storage of documents, variables, objects, etc. I thought I remembered reading this somewhere once upon a time.

That's not what I was told by the WM developers at Mobius.

I have to admit that I like the idea of multithreading apps whenever possible as suggested in the article, but being a developer myself and knowing just how hard it is to get multiple threads to behave nicely together, I can appreciate the amount of work that it takes and can easily see how most developers will just choose to avoid it.

And for most applications, that's okay. Let's face it, there aren't all that many applications that really benefit from multitasking. Most games will do just fine saving state and exiting, only to pick up right were you left off when you start them up again. Same for ebook readers, word processors, spreadsheets, etc. Outside of media players and networking apps (browsers, email, IM), multitasking isn't really all that important on a handheld.

[Jeff Kirvin]

This article actually brings up a question...

I thought that Windows Mobile didn't have to copy the executable file into program memory if it is stored on the device's internal storage memory. I was under the impression it could be run directly from storage memory, using only as much program memory as needed for dynamic storage of documents, variables, objects, etc. I thought I remembered reading this somewhere once upon a time.


That's correct...

"XIP stands for Execute in Place. XIP means that a program is stored in rom or flash and it is actually executed right from the rom. Microsoft has extended XIP to also refer to the ability for specific areas of the flash rom to be updated without updating the whole flash rom at once."

http://www.cewindows.net/faqs/pocketpc2002xip.htm

That works for the ROM applications, but not stuff stored in Storage RAM. TextMaker is copied kit and caboodle into Program memory. That's why I had to stop using it on my 32MB PPCs. It was just too big.

[Zack Mahdavi]

While it may be true that lazy developers will lean towards writing single threaded apps, this could be made much easier if the development tools are designed properly... If, for example, it was made very easy to divide the application into multple threads and exchange data between them, the chance of a lazy developer actually writing a multithreaded app are much higher.

I agree... writing multithreaded applications can be the biggest pain in the world. However, as long as you stick to a methodical way of writing programs (ie. always lock in a beginning of a function.... always use while instead of if for wait statements, etc), writing multithreaded programs can be much easier.

I'm sure PalmSource will lay out a set of rules to follow when writing multithreaded programs. That will make the developer's life easier... well, that's assuming they obey the rules.

[RobPPC]

My confusion comes in when I think of IM's...will a Cobalt version of say Yahoo IM be able to stay 'active' (I mean actively logged into Yahoo IM, and show me as logged on to my IM contacts) while I'm surfing the web, as well as allowing me to run AOL IM, MSN IM all at the same time, all actively showing me as online. Etc. (which I can do today with a PPC)

(I'm assuming I'm using a Wifi Cobalt PDA btw.)

My assumption has gone from no, to Yes, with the following caveats...they must be coded properly for Cobalt to keep those thread as background thread, and they'll need to generate a Slip window so I can flip back to them when I wish to send an IM? Is that correct?

You can actually do this now with both Verichat and Chatter. Chatter leaves a thread running in the background under OS5 and Verichat uses a SMS gateway and a SMS filter (looks for something in the SMS header) and pops up over any running application.

If I'm not mistaken, OS5 actually has pre-emptive multi-tasking but not for the UI thread...if this is true, it somewhat sounds like OS6 isn't that huge of a jump. I could very well be wrong on this.

[Jeff Kirvin]

You can actually do this now with both Verichat and Chatter. Chatter leaves a thread running in the background under OS5 and Verichat uses a SMS gateway and a SMS filter (looks for something in the SMS header) and pops up over any running application.

If I'm not mistaken, OS5 actually has pre-emptive multi-tasking but not for the UI thread...if this is true, it somewhat sounds like OS6 isn't that huge of a jump. I could very well be wrong on this.

Multitasking in Garnet is a bit more limited than in Cobalt, but far more than most people give it credit for. I have no problems listening to oggs or Audible in the background on my Garnet Powered Tungsten E, and as you mention, many IM and email programs already work just fine in the background. Honestly, between Garnet's Notification Manager multitasking and save-state task switching, I'm pretty happy with the way Palms multitask already. Cobalt will make this more robust and more efficient.

[djdj]

That works for the ROM applications, but not stuff stored in Storage RAM. TextMaker is copied kit and caboodle into Program memory. That's why I had to stop using it on my 32MB PPCs. It was just too big.

Maybe this is something MS ought to address in WM in the future. I know they probably won't, but it would make memory usage much more efficient.

I know that Windows on the desktop is capable of running apps from cache, which is similar, so it is probably technically possible.

[Will T Smith]

I think it was really nothing but spin. They effectively told us that WinCE apps don't close when you hit the X button and Palm apps do. So Palm will use threads and thats better ?????

My understanding is that Palm OS6 will not pre-emptively multi-task. The fact that they will force developers to write their OWN multi-tasking code CONFIRMS this. Effectively, it's the same as Windows 3.1 or pre-OSX Mac. Apps use cooperative multi-tasking. Your app must perform a measured amount of work and then release the processor for other users.

Basically, the operating system should handle swapping processes. The methodology is well defined and has been used on Unix since ... FOREVER. If you combine this with a process priority model, everything works fine.

Does the WinCE method have downsides. Well yes. First, we all know that the X button should close apps like it's told (forget the fact that this is a function of the Desktop Shell, not the OS). Some applications could do a lot of "busy work" and chew up CPU and memory resources. How does this differ from Palms "elegant" thread method .... NOT AT ALL.

The fact is that the "multi-tasked" apps in Palm can still act like horses asses and steal CPU resources. The big difference is that Palm will force developers to write extra code to get it to run in the background. So MOST Palm apps won't be capable of multi-tasking. Furthermore, the Palm implementations will be far buggier because developers will have to write work allocation and synchronization code.

Ahh, but Palm will let developers fine tune multi-tasking says Palm .... Well, so does WinCE. Yes, REAL threads are available on PocketPC. So a developer could dump backgroud "busy work" into a thread and run it PRE-EMPTIVELY in low priority. They only need to write syncronization routines, they don't have to do work rationing.

Of course, I could be wrong. Palm 6 may pre-emptively multi-task their threads at an OS level. In such a case, Palm will make it's developers write lots of extra code to do something that the OS is inherintly capable of. It could be a "policy" thing created to make developers think about how their apps should behave in the background (though a pre-emptive OS can assign the "foreground" app higher priority so the background apps don't get in the way).

Who knows. But I think the lady doth protest too much about her multi-tasking and process scheduling capabilities.

[Jeff Kirvin]

My understanding is that Palm OS6 will not pre-emptively multi-task. The fact that they will force developers to write their OWN multi-tasking code CONFIRMS this. Effectively, it's the same as Windows 3.1 or pre-OSX Mac. Apps use cooperative multi-tasking. Your app must perform a measured amount of work and then release the processor for other users.

Not exactly. The way this works is that the overall system has 16 available processes (compared to 32 for CE). The foreground application takes one, the system (I think) takes one, and one is shared between all background threads. These background threads, while sharing a single process ID, are pre-emptively timesliced by the OS, so no single thread can monopolize the CPU. This is far more efficient than MacOS9/Win3.1-style cooperative multitasking. Cobalt is a true 32-bit pre-emptive multitasking OS, it just handles it a little differently than Windows. PalmSource showed the power of this threading by doing a Be-style graphics demo at DevCon. They showed a rotating cube playing an MPEG4 movie on each face as the cube rotated and the movie played both at a consistent 30 fps. This was on a 200MHz Xscale.

Does Cobalt require that the developer explicitly enable multitasking? Yes. Does this make sense on a low-memory, low-CPU-speed, battery-driven, handheld size device? Yes. Apps that need to multitask get full pre-emptive power, but apps that don't (like Jason's battery hogging game), simply go away when you're not using them.

[Jason Dunn]

Hey Jason, just out of interest, what programs make your MPx200 run out of battery power so quick? I've had the same thing quite a few times and I can't work it out!![/u]

Lemonade Tycoon from JAMDAT. When I'm done playing the game I have to use a task killer to nuke the app or severe battery drainage will occur.

[lapchinj]

I think that it’s a cool implementation and it’s worth looking into for the PPC side also. Programs should be modularized. Running in threads is not bad since it seems that the OS takes care of what to swap out. But how does the OS handle the background threads if the threads are too many or too big? Are they preemptively swapped out?

I don’t think that there is a big problem with programmers doing the right thing if the API’s are good. Back in the pre ver.1 days of OS/2 we brought over ‘C’ code that was written on a Data General mini that used no proprietary extensions and it compiled and ran with only a minor change to file name length. When I came over into the Microsoft world I don’t think that I really ever wrote any ‘C’ code that could be compiled with another compiler (Borland comes to mind) let alone another platform. So whoever wants to beat the system will succeed with a little work. Microsoft makes it very easy to do it either way – but that’s a side effect of making the programmers life easier.

Besides Chevy ROCKS… (on with the wars) :mrgreen:

Jeff-

[joelevi]

My confusion comes in when I think of IM's...will a Cobalt version of say Yahoo IM be able to stay 'active' (I mean actively logged into Yahoo IM, and show me as logged on to my IM contacts) while I'm surfing the web, as well as allowing me to run AOL IM, MSN IM all at the same time, all actively showing me as online. Etc. (which I can do today with a PPC)

(I'm assuming I'm using a Wifi Cobalt PDA btw.)

My assumption has gone from no, to Yes, with the following caveats...they must be coded properly for Cobalt to keep those thread as background thread, and they'll need to generate a Slip window so I can flip back to them when I wish to send an IM? Is that correct?

I use my iPaq 4155 in this manner all the time... MSN Messenger is open in the background with 2-3 converstations going... PIE is loading a web page, and I'm typing notes with my Stowaway IR keyboard into Pocket Word, entering dates in my calendar and names in my Address Book, ans swapping between them as needed.

Can your palm do that?

[Jeff Kirvin]

I use my iPaq 4155 in this manner all the time... MSN Messenger is open in the background with 2-3 converstations going... PIE is loading a web page, and I'm typing notes with my Stowaway IR keyboard into Pocket Word, entering dates in my calendar and names in my Address Book, ans swapping between them as needed.

Can your palm do that?

Actually, with the exception of loading the web page in the background, yes, my Tungsten E with Palm OS Garnet 5.21 can do that quite easily. And the web page thing will be addressed with Cobalt.

This is what I mean by Ford vs Chevy. All this "my PDA is better than your PDA" oneupsmanship is increasingly futile and ridiculous. Both platforms can do the same things just about equally as well as the other. They differ slightly in implementation, but there's no clear winner either way.

[tw]

Does Cobalt require that the developer explicitly enable multitasking? Yes. Does this make sense on a low-memory, low-CPU-speed, battery-driven, handheld size device? Yes. Apps that need to multitask get full pre-emptive power, but apps that don't (like Jason's battery hogging game), simply go away when you're not using them.

I think Will T Smith made some good points. In addition I think you forgot to mention in your article that Windows Mobile supports multithreading too and it's quite efficient.

Pocket IE and many other apps for WM are multithreaded. For example if you write protocol handlers or filters for PIE you have to make them multithreading-safe since PIE uses different threads for the user interface, downloads, filtering etc..

As a developer you can write your Windows Mobile app exactly like a Cobalt app if you like. There is nothing in WM which prevents you to exit your user interface thread when your app has not the top window and freeing all resources. Of course you would have to do it in a proper way, i.e. you should use a different thread for the user interface than the main thread. But that wouldn't be a big deal (except perhaps that you couldn't use the "skeleton" source code created by the assistants of eVC++ unchanged).

But I doubt that for most "normal" apps exiting the user interface thread would make much sense. Because the big disadvantage is that the app has to reallocate all the resources and to redraw the user interface etc.. That would involve also a lot of state saving. Also the app would have to find "dangling" threads because otherwise racing conditions could occur.

I don't like the idea that the web browser would have to re-render e.g. the eBay web page all the time, or a game would have to save the state all the time if I switch back and forth between Messenger, a game and a web browser (e.g. eBay ...), just because their user interface threads are exiting all the time.

Anyway you could write in WM your programs exactly like in Cobalt. At least this is what I think after reading your description of Cobalt's limited multitasking capabilities.

[Ed Hansberry]

This is what I mean by Ford vs Chevy. All this "my PDA is better than your PDA" oneupsmanship is increasingly futile and ridiculous. Both platforms can do the same things just about equally as well as the other.
Frankly, I've heard the same thing for years. I had a prominent web site owner tell me point blank in the spring of 2002 that there was nothing the PPC could do that the Palm couldn't. Is ridiculous as it sounds, it comes down to youe definition of "same." Spin it how you want it. OS6 cannot multitask apps the way the Smartphone, PPC, Mac, Linux or Windows XP/NT/2K can. All 5 of those OSs preimptively multitask all processes and the independent threads those processes spawn. OS6 must have specifically written threads to do this, which sounds a lot like a TSR under DOS. It can be your opinion this is the same effect, it can be your opinion that it is conceptually better for a handheld platform.

Quite frankly I am sick of PalmSource telling me it has the perfect answer for everything. :roll: Again.

[CR]

Multitasking arguments aside, POS vs WM won't be Ford vs Chevy until I can copy over my big-whatever.file to my pda from my home desktop and be able to access it on my pda and later copy it over to my work desktop if necessary. Put in a real file system, and then it'll be closer...

Of course, I haven't thoroughly researched POS 6, so I may be off base. I guess not everyone REALLY needs that sort of functionality, but I think just about anyone who seriously needs a multitasking pda could probably use a real file system too.

Also, everyone knows that Chevy wins every time. 8)

I think the good old acronyms go: Found On Road, Dead and Cracked Head, Every Valve Rattles, Oil Leaks Every Time.

[drac]

Kudos to Jeff on an excellent article.

I'm quite impressed by what I've read of the concept of PalmOS6 multitasking, though I am skeptically waiting to see if the concept will play out well in practise.



I think you forgot to mention in your article that Windows Mobile supports multithreading too and it's quite efficient.
Basically what happens is that PalmOS6 imposes deliberate limitations in an attempt to optimise the user experience, just as all OS's do.

What I see here is that many PPC users are chafing at the idea of unaccustomed limitations without thinking through whether or not those limitations will actually affect the end-user experience.


As a developer you can write your Windows Mobile app exactly like a Cobalt app if you like. There is nothing in WM which prevents you to exit your user interface thread when your app has not the top window and freeing all resources. Of course you would have to do it in a proper way, i.e. you should use a different thread for the user interface than the main thread. But that wouldn't be a big deal (except perhaps that you couldn't use the "skeleton" source code created by the assistants of eVC++ unchanged).

But I doubt that for most "normal" apps exiting the user interface thread would make much sense. Because the big disadvantage is that the app has to reallocate all the resources and to redraw the user interface etc.. That would involve also a lot of state saving. Also the app would have to find "dangling" threads because otherwise racing conditions could occur.

I don't like the idea that the web browser would have to re-render e.g. the eBay web page all the time, or a game would have to save the state all the time if I switch back and forth between Messenger, a game and a web browser (e.g. eBay ...), just because their user interface threads are exiting all the time.
My understanding is that most of the time, apps need to redraw the user interface anyway. I know that windows have to be redrawn under Windows when one switches back to them, whether or not the app was open in memory, and my understanding is that the same is true for WM.

So I don't see the need for redrawing to be a disadvantage of the PalmOS multitasking model, but rather a reality that both PalmOS and WM have to shoulder.


You also neglect the advantage that exiting the user interface thread as well as non-necessary processor-intensive threads has: reduction in processor and memory usage. Such reduction is crucial when using any device on which power and/or memory are significantly limited, including mobile devices.



As I said, the jury should still be out on whether or not this Cobalt model works effectively; but it seems like a pretty sweet idea to me.


Multitasking arguments aside, POS vs WM won't be Ford vs Chevy until I can copy over my big-whatever.file to my pda from my home desktop and be able to access it on my pda and later copy it over to my work desktop if necessary. Put in a real file system, and then it'll be closer...
I actually thoroughly disagree. PalmOS devices have access to Windows-type filesystems via external memory cards. OS-level handling of such memory cards is in desperate need of improvement, but I think that it makes sense to retain the advantages of a database-driven structure (http://msdn.microsoft.com/Longhorn/understanding/pillars/WinFS/default.aspx) for internal memory, while improving the handling of memory card filesystem support in order to provide functionality like that which you describe.

[jonathanchoo]

Multitasking arguments aside, POS vs WM won't be Ford vs Chevy until I can copy over my big-whatever.file to my pda from my home desktop and be able to access it on my pda and later copy it over to my work desktop if necessary. Put in a real file system, and then it'll be closer...



Real file system? How do you define that? Of course those who uses Windows PC exclusively will think that the Windows method is de facto file system and expects other OSes to behave the same. It does not work that way. Now to mention WM still can't work with ALL big-whatever.files out there

[orol]

Multitasking arguments aside, POS vs WM won't be Ford vs Chevy until I can copy over my big-whatever.file to my pda from my home desktop and be able to access it on my pda and later copy it over to my work desktop if necessary. Put in a real file system, and then it'll be closer...

Of course, I haven't thoroughly researched POS 6, so I may be off base. I guess not everyone REALLY needs that sort of functionality, but I think just about anyone who seriously needs a multitasking pda could probably use a real file system too.

Also, everyone knows that Chevy wins every time. 8)

I think the good old acronyms go: Found On Road, Dead and Cracked Head, Every Valve Rattles, Oil Leaks Every Time.

actually you cannot copy much into ram anyway (even on 128MB MDAII) why ? because you want to have big chunk of memory for the running applications

btw it looks like everyone is ignoring the "origin" of both systems

whereas PPC / WM is actually shrinken down windows (in a way) and POS is basically organizer OS on steroids ..

to each his own .. however if anyone would come with such nich hardware as sony clie UX50 with windows mobile on it I'd jump over .. but I don't want classic PDA I want more .. I want communicator

and how writes more then a couple of appointments, short memos on PDA with stulus is insane .. I want keyboard ..

HP 4350 is a nice start .. but everything else on the PPCs side is still an organizer .. there are no communicators over there ..

[Ed Hansberry]

Real file system? How do you define that? Of course those who uses Windows PC exclusively will think that the Windows method is de facto file system and expects other OSes to behave the same. It does not work that way. Now to mention WM still can't work with ALL big-whatever.files out there
A real file system like Macs, Linux and Windows PCs have. One that doesn't demand that in order to use the whatever.files they must be converted to a database format. You can't even copy something as simple as a .jpg or .wav to a Palm in RAM without converting it.

[CR]

I could see how the POS database driven file system would be convenient and possibly faster if it was only used as it was intended to be used in POS 3. It is not and will never be convenient to have to convert a text file to a pdb before you can copy it over to your pda. I guess palm could get around that with a passle of conversion filters, but that would seriously compicate syncing. There are just too many different types of files that get thrown around.

As far as having to use the storage card to transport your whatever.files, that is also not really convenient. If it can handle the real life file types on a storage card, then why not in memory? I don't know about you, but I have a couple of different storage cards that I use. First, they are two slow to run some things off of. Second, there are some things that I need to access at the same time as things that may be on other cards, and I don't have the time to make sure that everything that I may need is on all of my carious storage cards.

I'll have to half-way agree about the big-whatevere.file. I have no idea as to why MS put a 16MB size limit on files in storage memory. That may have changed with WM2003, but it probably hasn't. At any rate I can still drop in a couple of MSDN chm files so that I have a little developer reference while I'm designing away from my desk, and if I feel like it, I can throw in a properly encoded avi with my favorite tv show ( a 20 minute episode runs around 15MB ). With a POS device, I couldn't do either of those much less actually use them if they were on a storage card.

...and before anyone says having to reencode the video clips for the PPC is the same as having to do it for the POS, it isn't. I can still use the clips on my desktop machine and they are pretty close to the same quality as the original seeing as they usually come from a terrible, blocky, out-of-sync asf *grumbles about Windows Media being closed and kinda crappy compared to the alternatives*.

[Ed Hansberry]

I have no idea as to why MS put a 16MB size limit on files in storage memory. That may have changed with WM2003, but it probably hasn't.
I have WM2003 but don't honestly know if that limit is gone. It isn't a PPC issue - it gets back tO the CE core. I suspect this is something MS has on their CE5 todo list. Remember that when CE came about, 16MB PCs were still around. 16MB in a handheld wasn't a consideration. Now with 128MB devices, it neeDs to be. :-)

Same thing with the POS database. Fine for OS3 PIM devices. Palm needs to dump it now though.

[Jeff Kirvin]

A real file system like Macs, Linux and Windows PCs have. One that doesn't demand that in order to use the whatever.files they must be converted to a database format. You can't even copy something as simple as a .jpg or .wav to a Palm in RAM without converting it.

Sorta. Several PalmOS vendors (Tapwave, Sony) have figured out ways to put JPGs, WAVs, MP3s in internal memory. This is usually accomplished by creating a virtual VFS volumn in memory.

There are a lot of advantages to a database "soup" as opposed to a tree based file system, as Microsoft has discovered with Longhorn. In the end, though, there's pros and cons to both. I like the fact that I get the best of both worlds with Palms, a soup in memory and tree-based file system on cards.

And btw, copying arbitrary files to the card is every bit as easy in PalmOS as Windows Mobile, and I can access unconverted .Doc, .Xls, MP3, Ogg, .txt and other files just fine on my Palm.

Seriously, if you guys would take a closer look at what Palms are really capable of today rather than going on what you remember them doing, you'd see there's not as much of a difference in what they can do compared to Windows Mobile as you think.

[cdunphy]

Quite frankly I am sick of PalmSource telling me it has the perfect answer for everything. :roll: Again.

Ed.... I've been one of the voices for Palm / PalmSource for over 3 years now, and I've NEVER said anything close to that. And I've never heard anyone else say that we had the perfect answer either.

There is no such thing as perfect.

In fact - our message has always emphasized that there is NO one ideal way to build a handheld. Diversity in hardware and software is the real killer app for mobility, and Palm OS powers the most diverse hardware and software out there. We think that for most people, most of the time, it is a better choice. But that does not mean that the Pocket PC is not a valid choice for some people. It is.

There seems to be a lot of the "Pocket PC rulez, Palm OS droolez" type juvenile platform flame war stuff coming from the Pocket PC world.... But then again, that's typical from the underdog. You used to see the same sort of stuff from Mac and Amiga fanatics.

It is really simple in the end though. Both platforms do a lot of things differently - and depending on your own personal tastes and even sense of style - one OR the other will fit you best.

Use it. Love it even. But recognize that it is not the ONLY way....

There is more than one way to mobile nirvana... :-)

- chris

PS: Jeff, thanks for inserting your calm, rational, and balanced voice into this conversation. I think you've corrected a LOT of misconceptions.

[Ed Hansberry]

Ed.... I've been one of the voices for Palm / PalmSource for over 3 years now, and I've NEVER said anything close to that. And I've never heard anyone else say that we had the perfect answer either.
Chris, you publish "The Path To Enlightenment (http://www.palmos.com/dev/support/docs/zenofpalm/Enlightenment.html#940701)" suggesting that anyone not on that path is not enlightened.

It still boasts of "Let a companion PC application do the heavy work" as if you are proud to have limited feature/doc compatibility on the device.

Your figure 1.4 and 1.7 shows Palm is in the sweet spot and the Pocket PC isn't. That isn't another way to say perfect?

Sorry if my calling it the way I see it bothers you. It has never been about the technology with me. To this day I still recommend PalmOS devices to people that are interested in a PIM solution, though much less so than the past because smart phones are today more powerful than $100 PDAs. It has always been the arrogance of Palm claiming they are superior, talking down Windows CE/Pocket PC while all the time your non-Palm Inc. partners are shoehorning Pocket PC features into PalmOS devices. Handspring went so far as to create a slot on the back of their devices so another computer, called a springboard, could do processes no pure PalmOS device could. Handera added CF capabilities. Sony is synonymous with innovation in the PDA space. All done with proprietary solutions because the PalmOS wasn't capable of it, and it has introduced a mess. What was the phrase used by Nagel - slightly chaotic in the short run (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=21473)?"

I've publicly stated several times I'd switch to Palm or some as yet unknown handheld platform if it suited my needs better, so yeah, I keep up with what Palm does. If my conclusion that the Pocket PC is still the best tool for the job comes across as "'Pocket PC rulez, Palm OS droolez' type juvenile platform flame war stuff" to you then you shouldn't be so sensitive. I've blasted Microsoft far more on several things, including but not limited to their mind boggling no close button mindset. Unfortunately, I've asked them several times what are they going to do when Palm comes out with a multitasking OS that supports running several apps at once and they put a close button in the product. That was 2000. Here we are in 2004 and my "what if" is still meaningless as OS6 still won't be able to truly multitask in ways I use my Pocket PC daily. Reading emails while pages in IE download and render in the background, copying between a contact form and emails, etc.

Your comparison to Mac and Amiga fanatics is invalid too. Neither of those even came close to double digit market share. Windows Mobile grows every year faster than Palm is and is number one in some countries. Honestly, Palm is more comparable to Larry Ellison at Oracle. Blasting Microsoft's product at every turn, claiming their database is the ultimate all the while Microsoft SQL Server is gaining share every year.

Keep dismissing them Chris, claiming they are the underdog. Microsoft seems to be releasing new revisions every 12 months now, releases that aren't paradigm shifts from a developer standpoint. An overwhelming majority of apps and utilities work just fine from one OS to the next without rewrites. The OS just sees those apps and treats them as a process. They run in the background just fine. Nothing even close to the paradigm shift going from OS4 to OS5 and now to OS6. Sure, some OS4/5 apps will run fine on OS6. Many will in fact. About zero percent will take advantage of the new multitasking OS6 supports. That makes your OS6 device an OS5 device until your favorite apps are rewritten for OS6.

What happens when Palm finally gives up the limited database in RAM? I've seen comparisons of Palm's database concept to Longhorn. That is like comparing ListPro or HanDBase to SQL Server. If users can't copy simple JPGs to RAM without conversions, something is wrong. So when Palm eventually fixes this, will apps have to be rewritten to see a RAM based file system? Very likely. Meanwhile, Pocket PC's file system APIs are largely unchanged from a developer stand point since 1997.

At some point, Palm developers are going to revolt at the constant changing requiring significant work with each OS release. They are already revolting over the myriad of screen resolution APIs and I've not seen one thankful that OS6 doesn't support native landscape mode, meaning they will have to still deal with it. OEMs can't like that. Palm Solutions is even open to the possibility of other platforms (http://www.pocketpcthoughts.com/forums/viewtopic.php?t=25276), including the Pocket PC.

Rant over.

[hackbod]

btw it looks like everyone is ignoring the "origin" of both systems

whereas PPC / WM is actually shrinken down windows (in a way) and POS is basically organizer OS on steroids ..

Palm OS Garnet (a.k.a. 5.x) is an organizer OS on steroids, architecturally basically the same as the first version of Palm OS.

Palm OS Cobalt is a completely new operating system, designed specifically for media and communition oriented personal devices. Almost nothing of the old Palm OS architecture remains, except as compatibility code running on top of the new system architecture.

[hackbod]

As a developer you can write your Windows Mobile app exactly like a Cobalt app if you like. There is nothing in WM which prevents you to exit your user interface thread when your app has not the top window and freeing all resources.

It's actually more complicated than that. To make this work, you need to be able to start up and shut down applications extremely efficiently -- taking more than 1/2 second to do so is quickly entering the realm of too slow for a satisfying user experience. We put a significant amount of effort into optimizing these operations in Cobalt, including some pretty interesting tricks behind the scenes, so that we could use this approach.

I don't have any idea what the performance is on Pocket PC for starting and stopping applications, so maybe the performance is good enough there.

Of course you would have to do it in a proper way, i.e. you should use a different thread for the user interface than the main thread.

That's not really how it works. In Cobalt an application can spawn threads either in its local process, or in a separate "background" process. All threads it spawns in its local process will be torn down along with it when the application exits, just like on Pocket PC. Any threads it specifically places in the background process will, however, remain running, and there are APIs for it to easily publish those threads and re-connect with them when the full application starts up again.

In generally implementing these background threads is basically the same as writing a normal thread, except of course it is in a different process than your application so you need to communicate with it by sending messages (since they don't share the same globals).

I don't like the idea that the web browser would have to re-render e.g. the eBay web page all the time, or a game would have to save the state all the time if I switch back and forth between Messenger, a game and a web browser (e.g. eBay ...), just because their user interface threads are exiting all the time.

Palm OS apps have always saved state between runs, so things like games are used to this and it generally isn't a problem. In the case of a web browser, generally the time to render the page is much smaller than the time to retrieve it over the network, so as long as you have a reasonable cache it shouldn't be that big a deal. (And if you really wanted to get all fancy, you could put part of your browser UI in a background thread, and use that to display the web page.)

[hackbod]

Yes, that's correct. A properly-written IM app for Cobalt will keep all your login threads alive in the background and pop up a Slip window to write messages. It would probably use Attention Manager to let you know when new messages come in (currently a flashing * in the upper left corner, but this should be a button on the toolbar in Cobalt).

A small correction -- Cobalt apps are free to run UI from any thread they want, in their application process or the background process. The UI system is completely thread safe, and takes care of arbitrating between multiple competing threads, including enforcing window clipping regions and all that other good stuff you expect from a Real Operating System.

Slips (and pinlets) are actually normal UI threads, the only difference being that the window they are running has been embedded inside of the appropriate sub-section of the display.

[drac]

Ed:
Rant over.
If you would be willing to post your points in non-rant format, I would be happy to respond to them.

[Zack Mahdavi]

Your comparison to Mac and Amiga fanatics is invalid too. Neither of those even came close to double digit market share. Windows Mobile grows every year faster than Palm is and is number one in some countries. Honestly, Palm is more comparable to Larry Ellison at Oracle. Blasting Microsoft's product at every turn, claiming their database is the ultimate all the while Microsoft SQL Server is gaining share every year.

Ohh.. don't get me started there. I used to hate Oracle until I was forced to make an Oracle database... :) Now I love it, especially its multiplatform support. Microsoft's SQL server doesn't come with client tools for practically every non-debunk operating system around.

But yeah, Larry Ellison needs to shut up and do some innovating.

[Ed Hansberry]

Ohh.. don't get me started there. I used to hate Oracle until I was forced to make an Oracle database... :) Now I love it, especially its multiplatform support. Microsoft's SQL server doesn't come with client tools for practically every non-debunk operating system around.Notice I didn't say SQL Server was superior to Oracle. :wink: It does fit a majority of needs though. :D

[Zack Mahdavi]

Ohh.. don't get me started there. I used to hate Oracle until I was forced to make an Oracle database... :) Now I love it, especially its multiplatform support. Microsoft's SQL server doesn't come with client tools for practically every non-debunk operating system around.Notice I didn't say SQL Server was superior to Oracle. :wink: It does fit a majority of needs though. :D

Hehe, I realized that Ed. By the way, you've made some really good points on this forum.

I'm looking forward for the release of Cobalt, so that we can all compare the actual performance of these operating systems as opposed to their implementation..

[tw]

I think you forgot to mention in your article that Windows Mobile supports multithreading too and it's quite efficient.
Basically what happens is that PalmOS6 imposes deliberate limitations in an attempt to optimise the user experience, just as all OS's do.

What I see here is that many PPC users are chafing at the idea of unaccustomed limitations without thinking through whether or not those limitations will actually affect the end-user experience.

Well, what I see here is that many Palm advocats praise every new PalmOS limitation to the skies without thinking through whether or not you can impose exactly the same limitations onto yourself (as a developer) on the PPC platform - if you want it.

Again - on the PPC you are just not forced to use the same threading model for all kinds of apps. You can use the model that suits your application best including the same threading model Cobalt uses - but which happens to be Cobalt's only threading model.

BTW, I remember very well how the absence of multimedia support in past PalmOS versions was praised by Palm advocats. Multimedia on PDAs was unnecessary and a bad thing until Palms got it...

As a developer you can write your Windows Mobile app exactly like a Cobalt app if you like. There is nothing in WM which prevents you to exit your user interface thread when your app has not the top window and freeing all resources. Of course you would have to do it in a proper way, i.e. you should use a different thread for the user interface than the main thread. But that wouldn't be a big deal (except perhaps that you couldn't use the "skeleton" source code created by the assistants of eVC++ unchanged).

But I doubt that for most "normal" apps exiting the user interface thread would make much sense. Because the big disadvantage is that the app has to reallocate all the resources and to redraw the user interface etc.. That would involve also a lot of state saving. Also the app would have to find "dangling" threads because otherwise racing conditions could occur.

I don't like the idea that the web browser would have to re-render e.g. the eBay web page all the time, or a game would have to save the state all the time if I switch back and forth between Messenger, a game and a web browser (e.g. eBay ...), just because their user interface threads are exiting all the time.
My understanding is that most of the time, apps need to redraw the user interface anyway. I know that windows have to be redrawn under Windows when one switches back to them, whether or not the app was open in memory, and my understanding is that the same is true for WM.

So I don't see the need for redrawing to be a disadvantage of the PalmOS multitasking model, but rather a reality that both PalmOS and WM have to shoulder.

No, that simplifying view is not correct. The reality is a bit more complex.

First of all, yes in general Win32 apps need to redraw the UI (or mostly only small parts of it) when something was obscured and gets exposed. Then they receive so-called WM_PAINT messages. But that happens only when the obscuring window(s) have not the "CS_SAVEBITS" style set in their window class (WNDCLASS). For example all menus, dialog boxes, combo list boxes etc. have the CS_SAVEBITS style by default. But it can be used for any window. When you use this style for a window the display driver or the GDI saves a bitmap copy of the screen image that the window obscures. When the window is closed the screen image is restored quickly by using the stored bitmap without the app having to redraw something. The decision where to use CS_SAVEBITS is up to the developer.

Secondly, and that's the important point, handling WM_PAINT messages is by far not the same thing effortwise as reconstructing the whole UI from scratch from data and/or resources all the time just because a user switches between different apps. I will give an simple example below.

You also neglect the advantage that exiting the user interface thread as well as non-necessary processor-intensive threads has: reduction in processor and memory usage. Such reduction is crucial when using any device on which power and/or memory are significantly limited, including mobile devices.

No, I do not. I just point out that the argument holds not much water. First of all the UI threads of idle processes in WM in the background are all but "processor-intensive". In fact they get almost no CPU time. Well perhaps additonal non-UI worker threads do. But that's not different under Cobalt. It's easy to check that out with a good task manager.

And as for the memory usage, for most apps not some UI controls allocate the most memory. In most apps it is the business logic code which allocates and fills the most memory in terms of constructing objects or whatever. In many cases constructing objects etc. requires a significant effort.

Let me give you an example: when a web browser has to render a web page it has to process the HTML code and to create a bitmap representation of it in memory (which can be larger than the screen btw.). That processing and rendering can and will take some time depending on the size and on the content of the HTML page as well as on the user settings, e.g. resizing to the small screen or not etc.. When the web browser receives now a redraw message (WM_PAINT) for the main window it will just use the temp bitmap in memory for redrwaing. That's not a big deal. But reprocessing all the HTML code just because the user switched for 10 seconds to an Instant-Messaging client app or some other app and the web browsers UI thread was exited and the temp memory was released is a big deal. It gets even worse if it's a large non-cacheable (dynamic) web page download e.g. via an expensive cell phone connection. Than it has to be even downloaded again...

Well you could argue that the Cobalt web browser could cache recently rendered pages as bitmaps somewhere in RAM. But that makes things not easier for the developer and the whole argument about saving RAM goes right out of the window.

As I said, the jury should still be out on whether or not this Cobalt model works effectively; but it seems like a pretty sweet idea to me.

As I just explained, it's easy to imagine that this sweet idea doesn't work well for many kinds of apps. There are lots of other examples where the Cobalt threading model doesn't fit. Imagine business apps which have to work with large DBs and have to put parts of it in RAM and construct objects from it for fast UI access etc..

In WM you have multiple choices. You can use a Cobalt-style threading model or you can use any other single-thread or multiple-threads model which fits your application best.

Let's face it the one-has-to-fit-for-all model of Cobalt with just 16 threads is more or less some auxiliary feature. It is by far not the same thing as WMs multitasking and multithreading capabilities just in another flavor or something with which you can do the same things just more "efficiently" as the original article claimed. That's my point.

[c38b2]

By default, any app in WM is multitasking with the UI hidden in the background while not in use. With cobalt, Palm retains the ability to close apps that would have closed on POS5 and lower - but now the apps can start system threads to continue data processing even when the program isn't running. Since you can really only interact with one program at a time on a PDA I see this as the most efficient option.

[tw]

By default, any app in WM is multitasking with the UI hidden in the background while not in use.

No, they do - of course - not. That is a misconception about how Windows works. Because WM works in this regard in the same way like XP for example.

Only running threads receive CPU time. But a UI thread in the backround is not a running thread as long as there are no Windows messages for it. The main loop of any UI thread in Windows is a message processing loop. The message loop blocks while waiting for messages from the system to be put into the thread's message queue. It blocks in the kernel. That means if the windows of the thread are in background (and have not set any timers etc.) it sleeps and gets no CPU.

So there is no advantage whatsoever in the Cobald model - which - I have to repeat it again - you could implement on the PPC too.

[Ed Hansberry]

By default, any app in WM is multitasking with the UI hidden in the background while not in use. With cobalt, Palm retains the ability to close apps that would have closed on POS5 and lower - but now the apps can start system threads to continue data processing even when the program isn't running. Since you can really only interact with one program at a time on a PDA I see this as the most efficient option.
Then I challenge you to copy items from a an email into their respective fields in a contact form, or use a program such as Seymour that allows two windows open at once.

I'll be curious to see how VNC or TS clients work on the Palm. I often get processes running in a TS session then do something else on the PPC waiting for the server to do its thing. Will the terminal window retain screen refreshes like it does on the PPC where I can periodically switch back and monitor the progress, or will it have to request a full redraw since the graphical part is shut down?

[hackbod]

Microsoft seems to be releasing new revisions every 12 months now, releases that aren't paradigm shifts from a developer standpoint.

This is kind-of a strange argument -- Palm OS has done two huge shifts recently, going to ARM hardware and now the new system architecture in Cobalt. Application compatibility for both of those releases has generally been quite high. In fact the switch to ARM was in most cases not a "paradigm shift" at all from a developer perspective, since they were still writing the same old 68k apps. I think developers would have liked much more of a shift at that point!

The fact is that Palm OS is in a transitional period -- it was designed earlier than windows CE, to run on much lower-end hardware, to support a particular kind of device. It didn't start out on ARM class of hardware, so there needed to be a shift to that in OS 5. It didn't start out on systems with any kind of memory protection or need of modern OS features, so the system architecture needed to shift to that in Cobalt.

This is basically like the transition from Windows 95 (or more like Windows 3.1 :)) to NT. Or an even closer comparison would be Mac OS: from 68k to PowerPC, and from OS 9 to OSX. Was it a bad thing that Microsoft and Apple did those changes?

And as for releasing new revisions every 12 months, we just released TWO new versions -- 5.4 (Garnet) and 6.0 (Cobalt)! And let's see, I think 5.0 itself was released to licensees in late 2001, so it looks to me that during a period of 2 1/2 years there were 5 OS releases, two of them being extremely major releases.

Granted, OS 5 has been developing somewhat slowly -- there were some big additions over that time (sampled audio playback, HVGA screens, QVGA screens, tall screens), though overall there weren't huge changes. But that's mostly because over the last 2 years PalmSource has been writing a completely new operating system.

An overwhelming majority of apps and utilities work just fine from one OS to the next without rewrites. The OS just sees those apps and treats them as a process.]

Cobalt does just treat all existing applications as processes. In fact usually when a sublaunch happens, it now creates a new process in which to execute the sublaunch. I am sure we will have more uses of background application processes in future releases, but that requires some significant design work, including very basic -- but difficult -- questions about how the UI should work for this kind of thing.

You could consider the introduction of slips as some early UI exploration into this; I think the concept of slips is an extremely powerful thing that we have just barely tapped at this point.

They run in the background just fine. Nothing even close to the paradigm shift going from OS4 to OS5 and now to OS6. Sure, some OS4/5 apps will run fine on OS6. Many will in fact. About zero percent will take advantage of the new multitasking OS6 supports. That makes your OS6 device an OS5 device until your favorite apps are rewritten for OS6.

That is pretty misleading. Existing Palm OS apps will work like they always have and were designed to do. They don't cripple the system, however -- while they are running any modern app can bring up UI or do whatever they want. The fact that an old application is running doesn't have any impact on the rest of the system or new applications.

What happens when Palm finally gives up the limited database in RAM? I've seen comparisons of Palm's database concept to Longhorn. That is like comparing ListPro or HanDBase to SQL Server. If users can't copy simple JPGs to RAM without conversions, something is wrong. So when Palm eventually fixes this, will apps have to be rewritten to see a RAM based file system? Very likely.

I agree the comparison to Longhorn is a bit of a stretch, but Cobalt's databases are significantly improved (re-written like almost everything else in the OS). There are new schema databases, which have much more traditional database semantics, including the ability to do SQL queries on them. The 64k limitation on size has been removed, so it is entirely practical to build a database containing images, just like you'd expect: define a schema with columns for name, whatever metadata you want like width and height, and a column for the image in which you can place the raw image file. Because there is no longer a size limitation, there is no need to do conversions.

Meanwhile, Pocket PC's file system APIs are largely unchanged from a developer stand point since 1997.

So should Microsoft not be doing Longhorn? When is "unchanging" good and when is it bad?

At some point, Palm developers are going to revolt at the constant changing requiring significant work with each OS release.

Nearly every developer I talked to at the developer conference about Cobalt was thrilled with the changes. Sure, it would be nice if things were absolutely 100% compatible and if, when they ran their app on the new OS, it would automatically acquire all the new features... but developers generally understand this isn't the way things work.

They are already revolting over the myriad of screen resolution APIs and I've not seen one thankful that OS6 doesn't support native landscape mode, meaning they will have to still deal with it. OEMs can't like that.

Yes, fragmentation of APIs has been a problem -- it is part of the challenge of allowing licensees to significantly innovate. But there is a big either/or situation: Pocket PC devices basically aren't getting landscape or higher resolution screens until now, because Microsoft doesn't allow them nearly as much flexibility. It's hard to find a middle ground between the two, though we are making progress in reducing a lot of the fragmentation.

For example: the high density APIs have been defined and implemented by PalmSource for the last two years. All current devices support the same APIs, and they scale well to other resolutions like QVGA and VGA. The landscape APIs started to fragment, but PalmSource has defined a standard for licensees to use until the PalmSource implementation can arrive. We defined new window manager APIs in Cobalt to make it much easier to support a wider variety of screen configurations -- basically if developers follow the new rules, when landscape appears in Cobalt their applications will magically use it.

The comment "I've not seen one thankful that OS6 doesn't support native landscape mode" is very funny. I haven't seen a developer thankful that an OS didn't include numerous different features in a release. A better question would be: would you like it to include landscape and come out 3 months later, or have a version now without landscape? You can always find more features to add, but you need to draw a line if you are going to get a release out... especially when you are talking about something as big as a new operating system. Like the 95/NT and OS9/OSX transitions, the first version of Cobalt has a tremendous number of new features but isn't quite up to Garnet in some areas. You can be sure those will be addressed, and faster than Microsoft did with NT.

[hackbod]

I'll be curious to see how VNC or TS clients work on the Palm. I often get processes running in a TS session then do something else on the PPC waiting for the server to do its thing. Will the terminal window retain screen refreshes like it does on the PPC where I can periodically switch back and monitor the progress, or will it have to request a full redraw since the graphical part is shut down?

This is getting old. To repeat: code running in the background process can do pretty much whatever the main application can do. It doesn't need to "shut down" the "graphical part" if it doesn't want to.

Here are the official limitations of the background process:


- All windows must be update-based (we don't let this code pretend like it owns the screen).
- No sublaunches or notifications execute here (though an app can use a separate API to receive lighter-weight "background notifications" in this process).


That is pretty much it. In the standard OS configuration the background process is used for all kinds of stuff -- playing audio, running slips, running pinlets, running the attention manager, showing the "incoming call" alert, etc., etc. These are all in separate threads, doing their own thing, using wonderful preemptive multitasking, and not caring a whit if the currently running main application is a traditional 68k app or a new Protein app.

Using the background process is extremely easy. There is a single API you call to create a thread there. Your application is loaded by the system in that thread and its main entry point called to tell it that it is running in the background process. There are a few small extensions to the traditional event manager APIs that let you communicate between multiple threads running their own event loops -- whether they are in the same process or different ones. Except for the restrictions listed above, you can run your whole app there if you really want to.
[/list][/list]

[tw]

This is getting old. To repeat: code running in the background process can do pretty much whatever the main application can do. It doesn't need to "shut down" the "graphical part" if it doesn't want to.

But if you do that it would be the same you do on "normal" multitasking OS like Unix, Linux (including embedded Linux), Windows or BeOS do - just in a more crippeled and complicated way (for the developer). At least it seems so.

Well I still do not understand the reasoning behind this strange concept. Probably mobile processors get even more fast and faster and require nevertheless less power, PDAs get more and more RAM etc.. So why wasting time and energy on optimzing something which might be obsolete in 12 months (well if it isn't already obsolete). Or is it the result of 2 years of development or something?

BTW, I liked BeOS. BeOS (which Palm bought) had a very efficient multitasking too... Good enough for todays mobile CPUs. I wish Cobald would be more Be than Palm...



Here are the official limitations of the background process:


- No sublaunches or notifications execute here (though an app can use a separate API to receive lighter-weight "background notifications" in this process).

Does that mean that for example a web browser which puts its UI thread into the background process cannot create additional threads? Or can it?


That is pretty much it. In the standard OS configuration the background process is used for all kinds of stuff -- playing audio, running slips, running pinlets, running the attention manager, showing the "incoming call" alert, etc., etc. These are all in separate threads, doing their own thing, using wonderful preemptive multitasking, and not caring a whit if the currently running main application is a traditional 68k app or a new Protein app.
How many of the 16 threads in the background process are available for user apps in the standard OS config?


Using the background process is extremely easy. There is a single API you call to create a thread there. Your application is loaded by the system in that thread and its main entry point called to tell it that it is running in the background process. There are a few small extensions to the traditional event manager APIs that let you communicate between multiple threads running their own event loops -- whether they are in the same process or different ones. Except for the restrictions listed above, you can run your whole app there if you really want to.

But only if the app is single threaded? Or can a app create additional threads while running in the background process?

And it cannot start another process because that would kill the currently running foreground process. Right?

And if a app is running as a normal process (i.e. the only one which can run besides the background process at a time) it doesn't share the same virtual memory space with threads it creates in the background process. Correct? Or does it?

When you have to transfer large binary objects, for example images, from a background thread to a foreground thread or vice-versa, how do you do that? Do you have to use some kind of shared memory feature?

[hackbod]

But if you do that it would be the same you do on "normal" multitasking OS like Unix, Linux (including embedded Linux), Windows or BeOS do - just in a more crippeled and complicated way (for the developer). At least it seems so.

Yes, it does multithreading just like other modern operating systems (modern Unix implementations, Windows, Mac OS X, etc). It's not more crippled or complicated, it's exactly the same. There are a couple APIs for managing threads, including SysThreadCreate() to create a new thread in your own process.

Well I still do not understand the reasoning behind this strange concept. Probably mobile processors get even more fast and faster and require nevertheless less power, PDAs get more and more RAM etc.. So why wasting time and energy on optimzing something which might be obsolete in 12 months (well if it isn't already obsolete). Or is it the result of 2 years of development or something?

Part of this is because currently a 200MHz ARM processor is not the equivalent of a 200MHz Pentium. In particular, you can't implement the traditional Unix process model (all process memory mapped into the same address ranged, being remapped at a context switch) in an efficient way on current ARM CPUs. This is the reason for the 32 process limit (with each of those processes only able to address 32 megs of memory) on Pocket PC. We also make use of an ARM feature called domains to significantly improve the context switch time, which also imposes limits on the number of processes.

Another part of this is that all current Palm OS applications have been designed around the model of starting and stopping when app switches occur, and being able to do that very efficiently. There are advantages to this model on a handheld device, so it would be unfortunate to just throw it out. We'd like to keep the good things about the Palm OS user interaction model, while making it much easier to write more complex applications now that there is a modern OS underneath.

Another way to look at this: writing code that runs in the background process is no different than writing it for any other process. You call an API, your app code gets loaded there, a thread calls it, and off you go. The only difference is you'll be sharing that process with others (though won't normally notice it). But there is nothing inherent in the system model that requires this; you can expect in future releases there to be much more extensive use of processes and APIs for third party developers to create and manage them.

Finally, just blindly relying on improving hardware performance is not as easy a thing in the handheld area, since it can severely limit the range of devices you can run on. Cobalt is already much heavier weight than previous versions of the OS (but it's all worth it! :)), and there is a lot of desire to continue to do work on optimizing the system to support even lower-end hardware, while at the same time pushing out the upper-end of hardware we can make good use of.

BTW, I liked BeOS. BeOS (which Palm bought) had a very efficient multitasking too... Good enough for todays mobile CPUs. I wish Cobald would be more Be than Palm...

Well thanks. I was an engineer at Be. :) Cobalt internally is actually much more like BeOS than it is like previous versions of the OS. If you want to know some more about the system architecture, another person from Be answered from questions from OS News here: http://osnews.com/story.php?news_id=6148.

Does that mean that for example a web browser which puts its UI thread into the background process cannot create additional threads? Or can it?

Sure it can. The same threading APIs work the same way everywhere.

How many of the 16 threads in the background process are available for user apps in the standard OS config?

It depends. :) Partly it depends on what is happening (for example if a slip is up it may have a thread dedicated to it), but also a lot of the underlying system is based on an IPC model that uses thread pools instead of dedicating threads to particular tasks, so there often isn't a direct mapping of thread usage to operation.

Btw, the "16 threads in the background process" number comes from the fact that the default configuration we ship to licesees allows 32 threads for user processes, of which there are generally 2. But a licensee is free to change this number depending on the capabilities of the device. There are very few -- if any -- signficant hard limits on resources (unlike previous versions of the OS), but mostly just policies that can be decided for each particular device.

But only if the app is single threaded? Or can a app create additional threads while running in the background process?

It can create threads in either process.

And it cannot start another process because that would kill the currently running foreground process. Right?

Well... there are a couple of things you can do. SysUIAppSwitch() will cause the current application to exit and a new one to run, yes. However the API SysAppLaunchDeferred() can be called from any thread in the system, and causes a new process to be created and run without exiting the current application. The SysAppLaunchDeferred() API is providing the traditional Palm OS application model, which is like a nested application execution -- the current application thread effictively waits until the "sublaunched" application has finished running. (But if the current application has created other threads in its process, they will still run while the sublaunched app is running.)

And if a app is running as a normal process (i.e. the only one which can run besides the background process at a time) it doesn't share the same virtual memory space with threads it creates in the background process. Correct? Or does it?

Correct, they are two different processes with their own address spaces. The process model is basically the same as other operating systems. The only difference is in top-level policy decisions about how to use those processes.

When you have to transfer large binary objects, for example images, from a background thread to a foreground thread or vice-versa, how do you do that? Do you have to use some kind of shared memory feature?

Yeah, shared memory works well. There are a lot of traditional Palm OS facilities -- FtrPtrNew() and classic or extended databases -- that are essentially various flavors of shared memory mechanisms in Cobalt.