George Hoffman: Palm OS Cobalt is a true microkernel architecture. The kernel provides only very low level memory-management, protection, and message passing services. Everything else is built on top of these services. Many application-level services are implemented entirely in shared libraries, while that functionality which requires maintenance of persistent state or synchronized access to shared resources is implemented in system servers that live in one or more background processes that define protection domains.
The I/O sub-system, for example, lives in its own process and is granted special privileges that allow it to respond to interrupts, touch hardware directly, and so on. Other important processes include the Data Manager process, which is responsible for managing all of the Palm OS databases (including the new secure and encrypted databases), and the "system" process, in which many other services are collected like the Window and Surface Managers (and thus a significant portion of the display sub-system) and "finer grain" services like the Feature Manager and Notification Manager.
The underlying architecture is quite aggressively modular, and is largely based on a fairly comprehensive object model and component management system. That said, the API itself is not any more or less modular than it has been in previous versions of Palm OS. Although the system has been largely rewritten, it was a primary goal of the rewrite to continue to support the existing APIs as much as possible.
In fact, the existing Palm OS APIs are factored into "managers" that handle different tasks, but the factoring is by functionality, not by object orientation (which was the dominant decomposition of the BeOS kits). This approach works very well for most of what the APIs do currently, but there is a lot of great stuff "under the covers" that we want to start providing more directly to developers which will be difficult to expose using the current style of API. So I think it’s safe to say that you will start to see some object oriented influences as the Protein APIs evolve, because this is a highly effective way to limit API complexity as features are added. You already start to see some of this in the new multimedia APIs, for example. We’ll of course be working to make the migration as smooth as possible for our developers.
4. What multimedia possibilities exist for this OS? What about web cameras, video playback, mp3/wma etc.
George Hoffman: Palm OS Cobalt introduces a brand-new multimedia framework, and I’d say that this framework really blows the doors off of multimedia possibilities for the platform. The MultimediaLib APIs (which are what is initially being provided to application developers) provide pretty powerful functionality in and of themselves. On the back-end, they are based on a node graph-based framework that is a highly evolved descendent of the BeOS Media Kit. I can say with certainty that this framework can and will scale both down *and* up better than the BeOS Media Kit ever did or could have. In addition, a lot of work has been done in the area of making really simple media tasks just that – simple – without compromising the power needed by really demanding apps.
And… just as a final teaser: at the PalmSource Developer Conference this week, we showed a demo which demonstrated the flexibility of an MPEG4 video being decoded in realtime and sent through a filter that displayed it in various ways using the new "Gc" rendering APIs, including mapping it onto a cube. To those BeOS fans out there, this should sound eerily familiar…
5. How are threads handled, is there some real multitasking now? What about performance?
George Hoffman: This is a true preemptively multi-threaded, multi-process OS, and developers can create additional threads both within their own applications and in a common "background" process. Most system APIs are accessible from any thread, including UI operations like opening windows and drawing. There are facilities for developers to create threads in the background and talk with them from "foreground" applications. There is still a notion of "the current application", but this distinction will progressively become more of a UI-level policy and less of an architectural differentiation made for compatibility reasons.
By performance, I assume you mean the speed of context switching, and I can assure you that this is very fast. The ARM processor has a mechanism called "domains" which places some limitations on the maximum number of processes, but in return provides very high performance context switching.
- "Interview with George Hoffman, Page 1/3"
- "Interview with George Hoffman, Page 2/3"
- "Interview with George Hoffman, Page 3/3"
