[Dianne Hackborn]

Originally Posted by macrotor

You are unable to truly program for the high-end devices because Palm still wants the new OS to run on the economy devices. Hence, your comment about putting the Linux onto a 16RAM/16Flash device.

One correction: in fact it is not nearly so much palmOne who wants Cobalt on lower-end devices, but rather other device manufacturers (in particular phone manufacturers) who have these lower-end requirements. Remember that PalmSource does the software; the hardware requirements come from the licensees we work with.

(And if you find it a little ironic that palmOne would be the one with the higher-end devices, while still not having a Cobalt device... well I do too!)

Btw, this is part of the explanation for why early on when Cobalt was introduced, Garnet was being positioned as the more phone-oriented product: the phone space tends to push down really hard into lower-end hardware, since it is so price and size competative, so from that perspective the lighter-weight Garnet seemed like a good choice for it. At it turns out, however, phones are also the devices that have the most need for some of the modern features in Cobalt, so it is really a much better platform for that market, as long as we don't go nuts with assumptions about how fast hardware capabilities are going to grow.

Personally, I think that we went from a system that was way under-powered for the hardware it was running on (Garnet), to one that is probably a little over-powered for the class of hardware we have right now. In the short-term, that means we ended up doing a little more work than expected to optimize parts of it, but we definitely have a good foundation on which to build for many years to come.

Originally Posted by macrotor

I really hope I got that wrong, because you are about to get rained with all kinds of comments about "holding back and crippling" the high-end devices for the sake of the economy devices.

Since we only do the software, I can't address the hardware in specific devices. However, in terms of the operating system, what this mainly means is that scalability is much more important in the software on these devices than it is on a desktop operating system.

This is something that we had in mind from day one when designing Cobalt, and that goal has gone into a lot of its architecture. In particular, as I recently discussed elsewhere, we think that one of the things needed to achieve better scalability is to have a lot more flexibility in how processes are used, instead of the traditional approach where an application is directly associated with its own process.

To achieve this, nearly all of the Cobalt system software is built on top of a standard component framework similar to COM or CORBA (it is called the Binder, if you've seen that mentioned elsewhere), but designed for system-level services as well. One of the main things a component system does is hide where a particular object lives -- you just make a call on an interface, and the object you are talking with can be in the same process as you or some other process. The caller doesn't care, and the component framework will implement this call as a direct function call or cross-process call as needed.

Because of this, we can basically decide, at runtime, how we are going to distribute the operating system and applications across processes, in any way we want. If we run everything in the same process, all the process and IPC overhead goes away, allowing you to run on much lower-end hardware. That doesn't mean you can't scale up to higher-end hardware, and in fact as time goes by we will be able to do some really nice stuff like run a web browser application in one process while a plug-in like RealPlayer that is embedded inside its web page can run in another process. That way, if the plug-in crashes, the browser itself is not disrupted at all, and there is no extra work required of the browser or plug-in to make this happen.

Truth in advertising: the current Cobalt kernel has a fairly embedded mindset (read "hard-coded") when it comes to processes, which limits how much we can use this aspect of the system. We do use this feature for things like running multiple applications in the background process, but today we can't go so far as to run everything in a single process. That should change when we move to Linux.

Originally Posted by macrotor

Cooperative task-switching is great for squeezing the most performance out of a device, but it relies on all the programmers playing nice with each other. Multi-tasking has a high overhead cost. Remember how PPCs had a much more powerful processor, yet seem to run the same speed of POS4 devices? That's why.

I am not sure about the terminology here -- no version of PalmOS has ever used cooperative task-switching, they have always been built on top of a pre-emptive multithreaded kernel. The limitation was that they only exposed one of those threads to applications, and all of the higher-level parts of the system (UI and other things) were single-threaded, so there was essentially no multithreading at all available to applications.

Originally Posted by macrotor

Apple Computer use to do threaded task-switching, etc up to MacOS9. It made for a very fast system. However, many programs and extensions were starting to not play nice with each other. Stability was going down the tubes. Programmers were whining about how difficult it was to program for the Mac. Things had simply become too complex. Once the hardware became powerful enough, Apple switched to a robust, multi-tasking, protected memory system (OS X). Sure, it was a massive CPU-drain, but the new processors could take it, and now the user had stability and customized multi-tasking.

I am not familiar enough with MacOS to say for sure, but I would suspect that development difficulties on it had little to do with "threaded task-switching." For example, the Amiga allowed multiple applications to run at the same time, with a full pre-emptive scheduler, but had no memory protection (processes) at all. Yet programming for it was really wonderful, especially compared to other personal computers at the time. And it was doing this on an 8MHz 68k CPU.

My impression is that MacOS was suffering from the same issues as Garnet (and Windows 9x) -- the entire architecture was originally designed as essentially a single-threaded system, with no memory protection. Trying to turn such a thing into a modern system with full processes and threads is really difficult, and in fact not the way to make that transition: MacOS X, Windows NT, and Cobalt all took the approach of designing a new modern system architecture underneath, and providing a new implementation of their existing APIs on top of it.

Generally multithreading doesn't introduce much overhead -- as I said, PalmOS has always been built on top of a multithreaded kernel. The big hit comes with memory protection, which is one of the basic reasons why Cobalt is significantly more heavy-weight than Garnet.

Originally Posted by BobR

You know, I think this thread and others like it point out a
great opportunity for PalmSource to put out some simple whitepapers to clarify a few topics.

That is a really good idea. I'll try to talk with Michael Mace about it.

Originally Posted by BobR

With regard to multitasking in Cobalt, remember that So I think that with the exception of those shared threads not protecting as completely against inter-program interference, you can do pretty much the same basic things with Cobalt as Win Mobile multitasking. We may see it looking a lot better after some more UI changes which are coming after some of the core underlying and invisible work is done.

Yep, they are functionally pretty similar. The most obvious thing missing from Cobalt is that we don't provide a standard user interface to manage multiple running applications. However, in a recent newsletter I wrote an article that described some APIs a developer could use to write their own application to do this. (Note that this isn't because we don't think this is an important issue, it is because we think it is important enough that we really want to do it right, and not just reproduce the desktop experience.)

(Btw, we don't have a per-process limit on the amount of RAM you can use. There is a limit on the total RAM all running applications can use, which can be arbitrarily configured for the device depending on how much RAM it has.)

Originally Posted by BobR

But don't forget that there are ways to do all that in Cobalt. Hopefully I don't have this all wrong. But the basic assumption seems to be one app on the screen being used at one time, which is pretty reasonable. (So you may not see those split screen apps for a long time, unfortunately.) But with such small handheld screens, especially in phones, you may not really want that too much. I think you can still have popup screens running in parallel with, say, a small overlay or popup or maybe cutout screen for something like the mp3 player while you are doing word processing.

That is pretty much correct. There is one self-contained process running at a time as the "main application", and switching between main applications involves stopping the current one and starting a new one. However, the main application in no way owns the screen -- another application running at the same time as a "non-main" application (in the background process) can display a window whenever it wants, and the system will correctly multiplex it with other things on the screen. The window doesn't need to be full-screen; it can be a small dialog that floats on top of the main application's UI.

In fact, we support very sophisticated window compositing in Cobalt, so these secondary applications can do things like display a semi-translucent window that floats on top of other application windows, and allows pen events to go through to whatever is underneath. You can also create windows that have varying alpha levels -- for example, the on-screen graffiti window has a slightly translucent gray background to show you where it is, while the frames (showing the different graffiti areas) and ink in it are nearly or completely opaque. You can basically do whatever you want.

During our recent developer's conference, the LifeBalance people used this feature to write a background application that created a full-screen transparent window, in which they animated falling snowflakes. The effect was that you could be doing anything else on the device, while those snowflakes were falling down your screen on top of everything else. They had this running on one of the Cobalt devices that were floating around the conference.

Originally Posted by BobR

Or you can have various kinds of control bars to manage background processing for things like downloads. You could even have split screens for game interaction. But, yes, the applications are probably more responsible for managing how that works. That's another thing that will probably have to be improved in the OS.... support for developers to do that sort of thing more easily and gracefully.

To be honest, right now we are not spending much time on adding ways to split the screen between multiple applications. Our big challenge is actually how to deal with smaller screens -- for example, a 2.2" diagonal screen is quite common. That kind of display is pretty darn small for just a single traditional PalmOS application, let alone trying to cram more than one on it.