MobileInfocenter

Comments on: Palm OS Cobalt Multitasking Explained

Jeff Kirvin has written an article further explaining how the upcoming Palm OS Cobalt will handle running multiple applications at once. He also looks at the Palm OS approach to multitasking, compared with Windows mobile.
Return to Story - Permalink

Article Comments

 (54 comments)

The following comments are owned by whoever posted them. PalmInfocenter is not responsible for them in any way.
Please Login or register here to add your comments.

Comments Closed Comments Closed
This article is no longer accepting new comments.

Down

Interesting...

atrizzah @ 3/18/2004 4:11:57 PM #
Hmm, I don't really know how I feel about this. Won't this make OS 5 and OS 6 apps totally incompatible? OS 5 apps won't be multitasked at all in OS 6, and OS 6 apps won't even be able to run on OS 5. I think it would be cool to have a button to put a single threaded application in the background. I imagine they'll probably include this functionality, though

Peace Out
Alan
RE: Interesting...
TTrules @ 3/18/2004 4:21:10 PM #
All I can say is, it's about time!

One Palm to rule them all!
RE: Interesting...
rened @ 3/18/2004 4:33:09 PM #
Why would you need a button to put an app in the background? There is a home button to bring you to the launcher which does about the same. Since _all_ programs exist in the main internal memory all the time.
Properly written programs bring you back to the place where you left it the last time.
The advantage of OS6 is that a worker thread can continue to do something. That's not the case for OS5 programs.


RE: Interesting...
mikecane @ 3/18/2004 5:14:23 PM #
>>>and OS 6 apps won't even be able to run on OS 5

Like, that's the point. Hello, McFly?!

RE: Interesting...
Kesh @ 3/19/2004 12:53:11 PM #
The apps aren't "totally incompatible." Just as you can't run an OS 5 app on a prior OS, you won't be able to run Cobalt apps on prior ones.

However, OS 5 apps should run just fine. Sure, they won't multitask... but they won't run any different than they do now. Right now, the apps all run as 'frontmost' threads, essentially, so that's what the OS 5 apps will do under Cobalt too. Running an OS 5 app won't kill your background threads on a Cobalt device.

We hope. ;)

RE: Interesting...
JKingGrim @ 3/19/2004 7:15:33 PM #
There are two APIs. 1.)The traditional APIs. Apps written with these will run on ANY version of POS. There may be restictions, depending on the features an app uses, for instance an app that only runs on OS3 and up. On Garnet and Cobalt, they run in PACE and can use armlets. 2.)The Protein APIs. Apps written with these will only run on Cobalt. Only these apps will recieve the benifits of the new features, such as multithreading. These apps will be ARM native.

It is very easy to create a 68k version of an app to run on old OSes, and then do little to no modifications and compile it ARM native. Adding in extra Cobalt features would take a little longer.

RE: Interesting...
atrizzah @ 3/20/2004 2:45:12 AM #
What I mean, is suppose you want to do any one of those things mentioned in the examples linked to in the explanation page, but you want to do it with an OS 5 app, unless the author has taken the time to make a threaded and an unthreaded version of the app, you are **** out of luck. Being able to background single-threaded apps would make this type of thing possible. I think it's positive to provide the option to developers of making their apps multithreaded, I just think that increased ability for single-threaded apps is good too

Peace Out
Alan

Attack of the Cobalt

mikecane @ 3/18/2004 5:11:25 PM #

Finally

palmkid @ 3/18/2004 5:16:42 PM #
Its about time they do this. They should've thought of this way back, like when OS4 was being sketched out. This is a smart move for Palm In my opinion.
RE: Finally
Token User @ 3/18/2004 5:58:44 PM #
Making this happen took two things ...

1. Hardware capable of doing multiple things at once. Sure, a Dragonball VZ 66 might have done it, but probably not. This ruled out anything pre 5.0 (or should we start callingthat Garnet now?)
2. BeOS engineers. The architecture sounds an awful lot like the multithread model in BeOS ... coincidence? I hope not. BeOS was an elegant OS that was doomed to failure (MS too big, Linux too free, which left BeOS too small and too expensive).

Is Cobalt really BeOS skinned down to PDA size? I really REALLY hope so.


~ "Don't be too proud of this technological terror you've constructed." - DV ~

RE: Finally
bcombee @ 3/18/2004 7:41:19 PM #
As stated in George Hoffman's interview, there is some BeOS code in Palm OS Cobalt, but it is mainly in the multimedia and graphics frameworks. The core OS along with its thread, process, and security models were done independently, although the team's experience with BeOS did affect the final form of these systems.

--
Ben Combee
http://combee.palmos.com - PDA programmer weblog
RE: Finally
Haber @ 3/19/2004 5:54:31 AM #
I think even the original Palm Pilots would have been hardware capable of cooperative multitasking. The old Macintoshes used an ~8MHz MC68000, and were capable of multitasking though the Multifinder. The Dragonball CPU, which was very similiar to the MC68000, had a clock speed of 16MHz. If the Macintosh could multitask at half the clock, I see no reason why the original Palm couldn't have done so

RE: Finally
Token User @ 3/19/2004 10:59:14 AM #
The old Macintoshes used an ~8MHz MC68000, and were capable of multitasking though the Multifinder.

I am not a Mac geek, but my understanding of the multifinder is that is allowed applicaiton switching, allowing you to return to an app in the same state that you left it. I certainly can't remeber being able compile in the background while having Word (MacWrite?) open in the background.

So, if you consider Multifinder multitasking, then I guess the PalmOS has had that capabiity since Palm Pilot 1000 days - switching between apps ("Home" == "Multifinder"), and entering the app where you left it. One advantage from the Mac was clicking on the window that was in the background brought it to the foreground - a luxury that the extra screen realestate the Mac had that the 160x160 display of the early PalmOS devices did not enjoy.

Bring on the true multithreaded OS.

BTW - Ben, I was not implying that direct code from BeOS was in the PalmOS, just that the engineering and experience brought over from that group has probably had a huge influence on the Cobalt design. I loved BeOS ... and I hope Cobalt will be the love child everyone is looking for.

~ "Don't be too proud of this technological terror you've constructed." - DV ~

RE: Finally
Haber @ 3/19/2004 4:11:11 PM #
Good point, it may have been switching. However, with the Palm Vx and up should have been doable, no?

RE: Finally
stickboy @ 3/19/2004 8:08:16 PM #
OS 5 and earlier did support threading. For example, on the deviced that support sound streaming, the audio playback is handled in a separate thread. A thread is also used for notifications and the like; these are the sorts of things that let alarms and attention dialogs and other things work.

IIRC, the obstacle on the 68K devices was that PalmSource did not own the kernel; they licensed it from someone else, and the terms of the agreement did not allow them to expose the threading mechanisms to anyone but the hardware licensees. (Plus, I think the number of allowed threads was very limited.)

PalmSource has been planning for this for /quite/ a while; Palm OS 5 was designed to be a stepping stone, and the Palm OS Emulator has for a long time warned developers about behaviors that would be incompatible in future OS versions.

Phasing everything out takes a long time, though, especially since, if you expect to switch to a new hardware architecture anyway, it doesn't make a lot of sense to rewrite your own kernel for the soon-to-be-obsolete one.

RE: Finally
Haber @ 3/20/2004 5:30:26 PM #
The Palm OS developer KB has this:

Palm OS is a multitasking operating system. How can I create a task?

Question
Palm OS is a multitasking operating system. How can I create a task?

Answer
Palm OS is built on top of a small kernel that Palm licensed from Kadak. The terms and conditions of that license specifically state that Palm may not expose the API for creating/manipulating tasks within the OS. If you need access to these calls you need to contact Kadak at (604) 734-2796, or visit their website at http://www.kadak.com
The Palm OS ROM is built with support for a very few tasks. There are only enough task slots for the ROM's needs. In order to support more tasks the ROM would need to be rebuilt.


RE: Finally
ganoe @ 3/21/2004 10:00:01 PM #
> I am not a Mac geek, but my understanding of the multifinder is that is allowed
> applicaiton switching, allowing you to return to an app in the same state that you left it.

I think you're right, but the Amiga and various Unix systems supported multitasking/multithreading on similarly powered processors (~8MHz MC68000) over a decade ago.

RE: Finally
Enfors @ 3/22/2004 5:27:29 AM #
Actually, the Amiga was able to multitask nearly TWO decades ago, with a 7.14 MHz Motorola 68000 processor and 512 KB of RAM. This was back in 1986. It used preemtive multitasking, just like modern Unix and Windows operating systems do. It worked like a charm. So yes, it would have been quite possible with earlier Palm processors too. But like others have stated, what stopped them was probably licensing issues.

-Enfors-
RE: Finally
mikecane @ 3/22/2004 10:56:37 AM #
It is too bad AmigaOS was never put into a PDA form factor. I recall what the Amiga could do -- and Cobalt still won't be able to do everything it could: Like multiple windows!

RE: Finally
mikecane @ 3/22/2004 11:12:16 AM #
Let me be the first to say that this stuff is giving me a headache. I think that what's needed is a DEMO that people can download to their Cobalt devices that will illustrate the various new features the OS is capable of. Anyone at PalmSource up to the task of creating such a demo that can be spread around the Net? I mean, none of you guys are actually taking WEEKENDS OFF, are you? This could be a demo we'd download, tap on, and it'd do a bunch of gee-whiz stuff with maybe popup explanations of the new features. (It'd also be nice to list the developers ... and maybe even a "Thanks to Mike Cane for the idea" line. >ROTFL!<)

RE: Finally
mikecane @ 3/22/2004 11:16:34 AM #
Ach! Bloody hell! PIC screwed up somehow -- the above post was *supposed* to appear all the way down, following hackbod's post about the details of Cobalt for devs.

RE: Finally
hackbod @ 3/22/2004 12:44:59 PM #
[quote]> Cobalt still won't be able to do everything it could: Like multiple windows[/quote]

What do you mean? Cobalt does multiple windows perfectly well, in many ways better than the Amiga did.


RE: Finally
mikecane @ 3/22/2004 3:27:15 PM #
I am defining windows as per app.

Window 1 - Calendar
Window 2 - Address book

for example. Just as Seymour can do on Pocket PC. I've been told this is not a feature of Cobalt. Tell me otherwise.

RE: Finally
freston @ 3/23/2004 12:49:42 AM #
> (It'd also be nice to list the developers ...

Actually the list of developers is already there, you only need to find it.


> and maybe even a "Thanks to Mike Cane for the idea" line. >ROTFL!<)

I doubt that will happen :)

RE: Finally
hackbod @ 3/24/2004 1:59:19 AM #
> I am defining windows as per app.

That can only lead to confusion. :) If you want any hope of being able to have a conversation about this stuff, then we need to use the same meanings for the words. And these meanings are pretty standard:

Window -- an autonomous area of the screen through which a program can draw UI and receive input from the user.

Process -- a protected memory space managed by the kernel. Other things outside of the process can't directly access it (especially its memory). (Unless specifically granted permission.)

Application -- a cohesive piece of code that allows the user to do some task.

These are each very different concepts, and can't just be used interchangeably.

> for example. Just as Seymour can do on Pocket PC.
> I've been told this is not a feature of Cobalt.
> Tell me otherwise.

I am not going to tell you that you can just take two existing Palm OS applications and run them at the same time. We aren't at all trying to hide this fact.

On the other hand, this is as much a limitation of current Palm OS apps (or more accurately the programming model they had to work with) as it is a limitation of Cobalt. All existing Palm OS apps basically operate as if they own the device -- screen and everything. There is a lot of code in Cobalt to give those applications an environment that makes it look like they still own the world, when in fact they don't any more. But the nature of all this stuff raises a lot of very tricky questions about how you will have two of these applications running at the same time.

Consider just one example: sublaunches. I love sublaunches. Basically how they work is that while one application is running, at any time you can have it end up jumping in to some other application to have the second app do something -- from being told that a database has changed, through showing an alert because an alarm went off, to getting an exchange request and thus sitting there reading from a stream and doing stuff with the data it gets.

My group got to spend a lot of time making the higher-level part of this stuff work on a real OS. And with a lot of duct tape and baling wire, hey, it amazingly does.

Well, it works when only one of these apps is running at a time.

But now I want to run two applications that both do this kind of thing.

Okay, here they are both running: Date Book and Address Book. Beautiful.

But wait! There is an entry in Date Book that the user wants to look up, so Date Book sublaunches Address Book! (Sorry I know you can't do this in Date Book, so it's a contrived example, but the point is that any Palm OS app can do this kind of thing at any time it wants, so we have to deal with it.)

Anyway, if you remember our model of a sublaunch, it is that the current application calls into the sublaunched application. But in our example here, the application we are calling in to is already running! What do we do?!?

Well we could say Date Book doesn't know about any other running applications, so it does the normal sublaunch of Address Book. But that won't work, because now we have multiple copies of Address Book running and it was never designed to be able to do that.

Okay then, the system knows that Address Book is running, so what if we just have Date Book stop and tell the currently running Address Book to execute this sublaunch? In fact there is already some code in the system that is similar to this, to be able to sublaunch applications in to different processes (in order to enforce security), so that seems perfect!

Or does it?

Well what if, at that very same moment, Address Book is also trying to sublaunch Date Book. That would sound like a deadlock between both applications. Not good. Not to mention the multitude of race conditions between the sublaunch request and the other application possibly being in the process of starting up or shutting down. Plus there are probably going to be some applications that have problems because they never before had to deal with a situation where they got sublaunched from somewhere else while themselves the top-level application.

The point of this all being, it's not like a year ago all the engineers at PalmSource sat down, said "hey if we tell marketing we can't run multiple applications at the same time then we can take the rest of the day off," and went out and had a big party. All at your expense.

What actually happened is that this is really just a hard problem -- because of our legacy it is much harder for us than it is for Microsoft to do the same thing. That legacy is generally good, it's why we are in such a strong position in the market, and it's well worth having all those applications, but sometimes it makes things a lot harder than we'd like. But it's just part of the trade-off between keeping compatibility with old applications and being able to push the operating system forward as quickly as possible.

In the future will we support running multiple applications at the same time? Sure we will. We are starting to today, and will most definitely make things much better as time goes on. Will we some day be able to just automatically run any two traditional Palm OS applications? I don't know; we'll see what it takes to address the issues. I can say that we haven't had a lot of time to really look in to how that might be accomplished, because for 6.0 there was such a tremendous number of other issues that we were -required- to address simply to get one application at a time running on the new system architecture.


RE: Finally
mikecane @ 3/24/2004 1:26:03 PM #
hackbod:

You have really gone above and beyond the call of duty in not only explaining things here, but giving us a peak of the thinking behind the scenes -- as well as frankly admitting some of the shortcomings of the current OS (no Seymour-like capability -- right now).

Thank you very, very much.

Paging hackbod
mikecane @ 3/24/2004 7:59:50 PM #
Eejit me! I'm not letting you go so easily, hackbod!

I have more questions!

1) Are there guidelines on how large a SLIP 'window" can be?

2) Same thing for pinlets.

3) How are fonts installed? Can all programs draw on them -- ie, word processing, database, spreadsheet programs? Are fonts automatically smoothed? Will we finally be free of converting fonts to, say, WordSmith's Finetype format?

4) Are there any Prefs for changing UI elements? Say, changing fonts in Title bars and dialogs? Are there Themes?

5) What provisions are there for *printing*? Does PalmSource see this as something that should be integrated into the OS, or will we have to rely on third-party solutions and the tower of babel of competing 'standards" that 3rd-party developers have to choose from?

TIA.

RE: Paging hackbod
hackbod @ 3/24/2004 10:05:45 PM #
> Eejit me! I'm not letting you go so easily, hackbod!

Of course not. :)

> 1) Are there guidelines on how large a SLIP
> 'window" can be?

Guidelines or restrictions? We don't really have any guidelines on this.

And in theory, there are no restrictions on size. A slip overlaps on top of any application windows as well as windows created by other threads, so it is free to cover as much space as it wants. (Though the system currently always gives it the full screen width.)

Unfortunately there is a bug in the version of Cobalt that will ship on the first devices, where the window manager wouldn't constrain the top of a slip to the top of the screen. So you have to be a bit careful about how much space you use -- worst case is a square screen with the status bar shown, giving you about 140 "dibits" of available space. (A dibit is the name we are using in Cobalt for the traditional low-density units, to distinguish it from "real" units like points, inches, centimeters.) If you aren't careful, the top of your slip can go up off the screen.

This problem has already been fixed, so following releases will do this right and correctly constrain the slip size. This will allow you to make a slip that uses all of the available space, for example, no matter how much that is.

> 2) Same thing for pinlets.

Again, no hard limits. With pinlets, though, you have to be careful about interactions with applications, because the pinlet pushes up the normal client area (i.e., the space available to normal windows). Thus:

(a) If your pinlet is unable to shrink down to the standard size, it can end up obscuring the bottom of application windows. This will happen for all existing applications, which can't deal with a screen smaller than 160 dibits. We encourage developers writing Protein applications to specify a minimum window size that is smaller than 160 dibits (if possible), so that in this situation they will shrink to make room for thhe pinlet.

(b) If your pinlet is absolutely unable to grow up to the standard size, then when running an application that doesn't support tall screens you will end up with a gap between the pinlet and the application. Fortunately it is easy to at least minimally deal with larger sizes -- just make the extra space empty -- so no pinlets should have a maximum size that is less than the standard pinlet size.

Btw, a pinlet can change its size on the fly through the normal WinSetConstraints() API, so you can do things like grow larger than usually (and possibly cover up part of the app) due to the user interacting with it. When this happens the system will automatically resize/move all application windows to conform to your new constraints.

(And slips can change their size dynamically, too -- the attention manager is now a slip and will change size when it needs add or remove attention items in its display.)

> 3) How are fonts installed?

We use standard TrueType fonts. To add new fonts to the system, you just build a standard PRC with a well known type code which has plain 'ol TrueType font files appearing in it as resources with a well-known resource type code. (I don't remember these codes, they should be in the SDK header file.) Once you put the PRC on the device and reboot, they will show up for everyone to use. (Unfortunately you currently have to reboot for the system to rescan fonts; that will be fixed in the future.)

In case that isn't clear, all it means is that there is nothing special about fonts, they're just standard TrueType font files (the exact file you find on Windows) placed into a standard PalmOS resource.

> Can all programs draw on
> them -- ie, word processing, database, spreadsheet
> programs?

There are new APIs for working with scalable fonts, all defined in the header GcFont.h. As long as an app is using those APIs, any fonts you install will be visible and usable in the application.

> Are fonts automatically smoothed?

Fonts are anti-aliased by default, though the GcFont API lets an application explicitly decide whether or not to draw with anti-aliased. (And also to enable or disable hinting.) The rendering of anti-aliased fonts is actually done by the normal Cobalt graphics system (we just get the shapes from the TrueType font and essentially use the Gc APIs to draw them), so applications have available to then that same quality of anti-aliasing for everything they draw.

> Will we
> finally be free of converting fonts to, say,
> WordSmith's Finetype format?

Yes, for applications using the new APIs. TrueType is our official font format!

> 4) Are there any Prefs for changing UI elements?
> Say, changing fonts in Title bars and dialogs? Are there Themes?

No. One of the things we were really disappointed about is that we didn't have time to update the UI even to use scalable fonts. The only things a user sees that actually use them are in the main form of the Launcher, the status bar, and a few of the slips. However, now that we have the underlying system architecture implemented, actually exploiting Cobalt's new graphics features in the UI is near the top of the list of things to do.

> 5) What provisions are there for *printing*?
> Does PalmSource see this as something that should be
> integrated into the OS,

It has certainly come up, but there is nothing I can say about plans or anything.

On the plus side, the new rendering model lends itself much better to printing (if you know PostScript, it will look extremely familiar), and the design of the Gc APIs makes this much more feasible to do. With Gc you are drawing into an explicitly specified "graphics context", which is not tied to a window. In fact, when drawing into an update-bases window, the graphics context you are drawing in to is actually not a window at all, but a special thing that turns all of your drawing commands into a stream that it sends them to another process that actually renders them.


RE: paging hackbod
mikecane @ 3/25/2004 11:00:48 AM #
Wow, this is very interesting!

More on my font obsession:

Can the 4 standard apps use the new TT fonts? That is, if I open Memos, will I still have just one face and a variety of sizes to choose from, or can I at least change everything to, say, Times?

And, yes, I understand what you're saying about PS. This is very exciting! You *must* get printing in there. That would be So Fekkin Amazing!

I will probably have more questions later. Thanks again for taking time to be here.

Paging hackbod 2
mikecane @ 3/26/2004 1:28:32 AM #
Tch! You didn't come back to answer the above post. Now you have *two* posts to deal with...

First, if you haven't, please go read

http://www.palminfocenter.com/view_story.asp?ID=2899

-- items 3 and 10 are still Outstanding. (There are others too, but these are my focus right now!)

You should see the sense of 3 right away. 64K Memos and pushbutton/jogscroll downdowndown or upupup? Nuff said.

Item 10: can't *anyone* at PalmSource see the sense of putting a "Graffiti slash" icon in the Status/Control/bottom bar? Why must, when all I want to do is Cut/Copy/Paste some text, I go through this nonsense when the DIA is retracted? --

1) Expand DIA
2) Draw slash
3) Tap icon in Command Bar
4) Collapse DIA

-- why can't it simply be like so:

1) Tap "Graffiti slash" icon in Task/Status/bottom bar
2) Tap icon in Command bar

Why doesn't that many sense?! Will you actually argue *against* that or simply admit, "Aw, shucks, none of us really *thought* of that..." I mean, doesn't the way I describe actually fit in with The Zen of Palm?!

While I've got your attention once again, let me ask some questions about the Media Player in OS6:

- exactly what kind of video files can it handle? Do you want to try to download each of these --

http://nitro.bok.net/pockettv.com/mpg/vga/

-- and see what each one does? (Actually, this test might not be worth a damn. Even if, *coughcough*, you happen to have an OS6ed palmOne device. So let me lower my expectations: If you do d/l the files, can you examine them and report if MP could handle all three?)

I'm rather keen on learning what sort of video MP will handle, especially after going through the CLIE Movie Player Gauntlet of Hell --

http://palminfocenter.com/forum/topic.asp?TOPIC_ID=21037

As for audio types, will it do Low-Bit-Rate MP3s? Specfically, LBR Old Time Radio (OTR) MP3s?

You can try, for example, any file here:

http://homepage.ntlworld.com/jaweb/page2.html

-- and while I'm at it, let me plug Mike Rohde's blog on this subject:

http://www.rohdesign.com/weblog/archives/000239.html

What provisions for DRM does the Media Player have?

Can the MP handle streaming audio/video?

More later... thanks in advance.



The fly in the ointment

bradhaak @ 3/18/2004 6:06:21 PM #
There are a couple of problems that this article doesn't point out.

First of all, ALL background threads run in the same address space. If one background thread crashes, it is liable to kill all background threads. The developer docs say that steps have been taken to restart the threads, bu you would probably lose any data or state info that was currently being processes.

Second, There is no mechanism provided to stop or kill background threads. In theory, you would do it from the app that started the thread, bu this doesn't seem like a great solution.

Outside of these concerns, the model seems really good for a memory constrained platform.

RE: The fly in the ointment
mikecane @ 3/18/2004 6:20:14 PM #
>>>There is no mechanism provided to stop or kill background threads.

First we had a boatload of Launchers.

Now we'll have a boatload of Thread Managers.

I bet those folks at Teal are already at work on it.

RE: The fly in the ointment
bcombee @ 3/18/2004 7:38:12 PM #
Background thread managers aren't really possible on Palm OS Cobalt. First, there's no mechanism to name a thread so you could tell which one to kill. Second, there's no OS call to kill a single thread -- a thread can terminate itself, but you can only kill an entire process.

Now, it may be possible to do this if developers agree on a thread information standard, where a program would store some info in a system database about threads they start and they provide a standard mechanism for the thread to determine that it should end ASAP. Since threads have their own event queues, this isn't too hard to do, but this isn't in the OS just yet.

--
Ben Combee
http://combee.palmos.com - PDA programmer weblog

RE: The fly in the ointment
mikecane @ 3/18/2004 11:35:18 PM #
>>>but this isn't in the OS just yet.

You lnow, Ben, that seems to be the standard fekkin answer to almost *any* question about OS 6. I mean, WTBF were they *doing* all this time? Plus they had the effrontery to *close* their office for the final two weeks of December!

If they keep up at this pace, they'll have entire *years* of that office being closed. And it'll be their own damned fault.

And these people *still* don't see a need for an icon in the Status Bar to invoke the Command Bar. I'd call them sub-geniuses, but that'd insult Bob.

RE: The fly in the ointment
freston @ 3/19/2004 12:44:37 AM #
> You lnow, Ben, that seems to be the standard fekkin
> answer to almost *any* question about OS 6. I mean,
> WTBF were they *doing* all this time? Plus they had the

Writing an OS.

> effrontery to *close* their office for the final two weeks
> of December!

That is simply not true. You are misinformed there.

> If they keep up at this pace, they'll have entire *years*
> of that office being closed. And it'll be their own damned
> fault.

Well writing an OS in two years seems pretty fast. Unfortunately while the OS supports a lot more than is shown in the APIs, there has been no time to provide programmatical access to all of the system features.

RE: The fly in the ointment
mikecane @ 3/19/2004 1:26:45 AM #
>>>That is simply not true. You are misinformed there.

"PalmSource Director of Competitive Analysis, Crhis Dunphy, stated in an email that the PalmSource offices have been closed for the holidays between Dec 24th and Jan 4th."

http://www.palminfocenter.com/print.asp?ID=6393

So it wasn't two *full* weeks. Damned close enough.

RE: The fly in the ointment
freston @ 3/19/2004 2:46:54 AM #
> >>>That is simply not true. You are misinformed there.
>
>
> "PalmSource Director of Competitive Analysis, Crhis
> Dunphy, stated in an email that the PalmSource offices
> have been closed for the holidays between Dec 24th and
> Jan 4th."
>
> http://www.palminfocenter.com/print.asp?ID=6393

He is in mistake there, since offices were open on Dec 24th
(morning hours.)

> So it wasn't two *full* weeks. Damned close enough.

I look at the calendar and that is: Dec 26th, 29th, 30th, 31st and Jan 2nd. Yes 1 week is close enough to 2 weeks :-))

Seriously now. After the final stretch (anybody that works in sw industry knows what the final stretch looks and feels like) taking 1+ week of rest is not a bad thing but a necessity. I know people there that were working inhuman work schedules to get Cobalt ready.

And that been said, it is sad that the APIs do not expose yet the engine within because of trying to keep the APIs as familiar as possible to developers[1]. And that some other stuff fell through (like enabling for developers a programmatic way of enumerating background threads.)

[1] see http://osnews.com/story.php?news_id=6148

RE: The fly in the ointment
mikecane @ 3/19/2004 1:10:15 PM #
>>>I look at the calendar and that is: Dec 26th, 29th, 30th, 31st and Jan 2nd. Yes 1 week is close enough to 2 weeks :-))

Of course you're right. I don't know what I was thinking, except it was very late when I typed that and I should have been doing something better: like sleeping! (Seems like I *was* sleeping when I typed it!)

RE: The fly in the ointment
JKingGrim @ 3/19/2004 7:28:39 PM #
This functionality is not in the OS because it is not needed. Background threads end themselves when finished, or can be ended by the app that created it. Thread naming conventions might not be available because PalmSource even wanted to dissuade thread managers. Why would devs want users to be poking arround and ending threads. That would be a whole nother hassle to have to worry about user intervention.

RE: The fly in the ointment
hackbod @ 3/20/2004 2:28:40 AM #
> Well writing an OS in two years seems pretty fast.

Now freston, don't exaggerate. Some parts of the OS must have been under development for -nearly- 2 1/2 years. :)


RE: The fly in the ointment
atrizzah @ 3/20/2004 2:53:39 AM #
I still worry about a loss of stability of the system due to errant threads

Peace Out
Alan
RE: The fly in the ointment
hackbod @ 3/20/2004 3:52:37 PM #
> I still worry about a loss of stability of the system due to errant threads

Ummmm... the big way to address stability is to use protected memory, which Cobalt does. If user code is doing something bad (either in an application or background process), then the system just kills that process and goes on in life. This is far better than the situation in Garnet.


Good Thing or Bad Thing?

aaronchow @ 3/18/2004 10:42:24 PM #
Having a background thread running can be good when you implemend them correctly, but I sense that spyware and virus writer can take advantage of this, too, so is there any security measurement that takes this into account?
RE: Good Thing or Bad Thing?
Konstantin @ 3/18/2004 11:20:22 PM #
I would not be preocuppied by viruses.
And for spyware/addware/malware is simplpe, do not install crappy software.

RE: Good Thing or Bad Thing?
bcombee @ 3/19/2004 2:02:02 AM #
One of the reasons it may be hard to port some software to OS 6 is that there is a lot more focus on security in the new OS. In particular, threads running in the background process can't get to the screen bits or the input queue of the user process, so it will be hard to make a "spyware" program. You could make malware that ran as a background thread and spied on other background threads, however; if you need to do secure computation, do it in the user app and don't stick it in a background thread.

--
Ben Combee
http://combee.palmos.com - PDA programmer weblog
RE: Good Thing or Bad Thing?
mikecane @ 3/19/2004 1:13:18 PM #
Ben: Have all the tools developers need to create Cobalt apps been made available? Are devs at work even now coding for Cobalt? Or must they first be seeded with dev hardware from, say, palmOne?

RE: Good Thing or Bad Thing?
JKingGrim @ 3/19/2004 7:33:18 PM #
The tools are there. The SDK and Eclipse is available. I believe Eclipse is still in beta, but it works. Even devs don't want to release apps compiled with a beta compiler, devs can still prepare the code.

RE: Good Thing or Bad Thing?
mikecane @ 3/19/2004 9:04:36 PM #
So when the first OS 6 device is announced -- which will probably be from palmOne -- we can expect a slew of "OS 6-ready" software announcements as well? And maybe even perhaps some "Formerly available only on the Pocket PC, now ported to Palm OS 6" announcements?

RE: Good Thing or Bad Thing?
aaronchow @ 3/20/2004 3:14:26 AM #
OFF-TOPIC:

Ben, thanks for clearing things up. Your help and comments are appreciated by Palm communities in general. :-)

RE: Good Thing or Bad Thing?
JKingGrim @ 3/21/2004 2:22:01 PM #
So when the first OS 6 device is announced -- which will probably be from palmOne -- we can expect a slew of "OS 6-ready" software announcements as well?

Yes.


And maybe even perhaps some "Formerly available only on the Pocket PC, now ported to Palm OS 6" announcements?

From http://ticalcemulator.calcnews.net/

Because many people asked me about a version for the Palm OS, I started to port it. I almost translated all the APIs to the Palm OS, and I was able to read the ROMs, but I got frustrated when I found about the 64k limit of the Operating System (I know that it is possible to segment the application... but It is really difficult and the processor is slow anyway). Fortunally I read that PalmOS 6 is coming at the end of December, and this limitation will be over, also truly support for the ARM processor. I will begin to work again on it when it is released.
Thats been there for a while though. I hope he's working on it. I hope more ports are comming too.

What is differernt compared to OS5?

Sho-Bud @ 3/20/2004 7:38:44 AM #
I ask this because after reading the column, it sounds like OS5 is doing the same thing, eg. I have Versamail download my e-mail every 30 minutes in the background using a bluetooth connection. Also MP3's allready play in the background.
(I'm using a T3)

RE: What is differernt compared to OS5?
hackbod @ 3/20/2004 6:35:32 PM #
First, the really big architectural difference between Garnet and Cobalt is that Cobalt is a protected memory system -- meaning it supports multiple distinct processes, each with their own protected address space. Making this change basically involved a ground-up redesign of the OS, since it originally very much assumed there was one global memory space. In practice what this generally meant was re-implementing most of the system services (Feature Manager and all) so they were no longer just a set of library calls, but instead a service running in a protected system process, with the public APIs now implemented as IPCs over to that service.

As far as multithreading goes, while there are some minimal multithreading capabilities in Garnet, it isn't really a part of the OS. For example, the only thread that can do any UI is the main application thread; the whole UI subsystem assumes a single threaded model for the entire device. In Cobalt we completely support multitreaded UI. Any thread can run its own event queue and windows if it wants to, and the system correctly multiplexes between these threads without them having to do anything special to share the screen.

The system takes advantage of this a lot by running system-level UI (the status bar, DIA, etc) in separate threads, so even if the application is crashed or stuck we can still give the user a responsive UI. Furthermore, many parts of the system UI run in system processes, so crashing applications or other user code will not disrupt them at all. You just see a dialog saying the app has crashed, tap okay, and the system quietly cleans it up and returns back to the launcher.

Another good example is communication. In Cobalt an application can easily spawn a thread that takes care of opening a network socket or whatever and doing IO on it, without having to manually multiplex with the UI thread. The IO subsystem is completely thread-safe, and like the UI it correctly multiplexes multiple thheads. This makes the implementation of communication apps immensely easier than on Garnet, and results in a better user experience because there is no way any IO operation can stop the UI.

Here's a concrete example of why Cobalt is so much better for communicator devices: to show a dialog when the device is receiving an incoming phone call, you can monitor for this and show the UI from your own thread, so it can be displayed regardless of what is happening in the current application. (In fact, licensees will probably have their own process for this stuff, so even if user code somewhere crashes the phone part will be completely safe and responsive.) You simply can't do this kind of thing in a reasonable way on Garnet.

In many parts of the system, the similarities of the Protein APIs to the original 68k APIs is really just a very impressive illusion. What is happening underneath is usually tremendously, radically different than what those APIs expose. For example, consider the whole concept of an "event queue" that an application or thread runs. This is actually just some compatibility code implemented on top of the real UI system in Cobalt which, instead of using anything like event queues, is designed as a distributed component system.


RE: What is differernt compared to OS5?
JKingGrim @ 3/21/2004 7:56:19 PM #
This is actually just some compatibility code implemented on top of the real UI system in Cobalt which, instead of using anything like event queues, is designed as a distributed component system.

How does that work? Is there going to be a transition in the future?

RE: What is differernt compared to OS5?
hackbod @ 3/24/2004 2:53:17 AM #
> How does that work?

Remarkably well? :)

> Is there going to be a transition in the future?

I don't know if I would use the phrase transition. We will progressively be exposing more and more of the underlying system, as the various parts get to the point that we are prepared to support them as third party APIs.


Top

Account

Register Register | Login Log in
user:
pass: