The voice, the man, the… machine. That’s George Hoffman for you. According to people who have worked with him (including my husband) he is one of the brightest Be, Inc. engineers ever. These days, George works at PalmSource, Inc. as the Director of Applications and Services. In his free time he sings with an (a cappella) vocal band of 4, Hookslide (check out their .wmv promo video clip)! In this interview we talk about PalmOS 6, aka Cobalt. We discuss the architecture of the OS, its capabilities, its market targets and more. Screenshots of Cobalt are included.
1. What processors does the new OS 6 run on? What are the specs you would feel comfortable on running OS6?
George Hoffman: Palm OS Cobalt should run on any ARM9 core with the 4T instruction set, though we are able to take advantage of 5T instructions as well. In terms of memory, it’s designed to run out of 16Mb of ROM and anywhere from 16 to 256Mb of RAM.
Our reference hardware is the Intel PXA255 X-Scale processor, running at 200Mhz. This is probably near the low end of what we expect to see Palm OS Cobalt shipping on in the market, though processor speed is only part of the story, of course. Just because a processor might be less than 200Mhz, it shouldn’t be discounted as potential platform. We’ve seen processors with much lower clock speeds but higher performance memory configurations that achieve similarly compelling Palm OS Cobalt performance.
2. What facility is there for graphics? (OpenGL/2D/3D, accelerated?)
George Hoffman: Quite a lot, actually. Despite what some of our competitors might like to pretend, the handheld visual interface of the future will not be like the desktop. It will be far more fluidly integrated and truly customizable, reflecting the very personal nature of these devices. In order to allow functionally integrated components to integrate visually – that is, to allow components from various vendors to share the limited screen real-estate available on a handheld and cooperate to present a unified visual interface – rich graphical rendering and compositing capabilities must be provided at the OS level.
Palm OS Cobalt completely replaces the old Palm OS “blitter” with a suite of new system-level graphical rendering technologies designed for high-performance, very high quality graphical rendering. At the core of these technologies is the new Palm OS rendering model, which is a Postscript-like (some might say “SVG-like”) 2D drawing API which is designed to be substantially accelerated with 3D hardware.
This new rendering model will be progressively exposed over several releases, and only portions (though major ones) are available in the initial Palm OS Cobalt SDK. Among the features supported today are arbitrary path stroking and filling (where paths are defined with lines, Bezier curves and arcs), anti-aliased rasterization, arbitrarily complex clipping regions, PS-like state stacks, gradients, bitmap tiling and scaling, arbitrary 2D transformations, and alpha blending. These features appear today in the form of the “Gc” rendering APIs that are available in the Palm OS Cobalt SDK. In future releases, more of this model will be unveiled, including greater support for complex compositing and filtering.
We’re also introducing high-quality scalable fonts for the first time. TrueType font rendering is standard, and we include a basic set of fonts which can be easily extended by our licensees or by developers. Fonts are integrated into the rendering model, and as such they can be painted, clipped, clipped to, and composited just like anything else. In fact, TrueType fonts are rendered using the same low-level rasterizer as is used to render “normal” user-defined paths.
We’re pretty excited to see what developers will do with this stuff!
I should not say too much about our plans on the 3D or OpenGL fronts, but rest assured that it is an area of interest for us. In particular, we’re keeping a close eye on the adoption curve of mobile 3D hardware in handhelds and I believe we will be well positioned to take deep advantage of such hardware as it starts to appear broadly.
3. Is the API grouped in modular kits like in BeOS? Please explain to us the OS architecture a bit.
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.
6. Would this OS work as a full featured OS on a Tablet? (eg. could it compete with Windows Tablet?)
George Hoffman: If you’re asking if Palm OS Cobalt can compete feature-for-feature with Window XP Tablet PC Edition, the answer is clearly no. Sadly, Cobalt will also not mow your lawn, feed your dog, or stand on its head and spit purple chiclets. If people want those things, they should look for another platform.
Palm OS Cobalt is designed to enable new classes of devices, and if a licensee wanted to build a tablet form-factor device with it they would have a powerful set of tools to use. The essential difference between the handheld and tablet form factors is the screen size and resolution, and it should be clear from some of my earlier answers that we’ve done the hard work already to scale up to arbitrarily large screen sizes, share that screen between processes, allow many windows to be onscreen and active at once, and so on.
There would be some issues that a device vendor who wanted to make a tablet with this initial version would need to tackle. These are mostly UI issues, and/or related to compatibility with existing applications. Our current PIM apps, for example, are optimized for a handheld form-factor and could use some tuning to provide an optimal experience on larger screens. This is true of most third-party apps, as well. But it’s likely that someone making a Palm OS Cobalt tablet would be interested in doing a suite of applications for it anyway, since the usage model is somewhat different from that of a smaller-form-factor PDA.
We’ve already done a lot of work to enable scaling to different device form factors, and that work is continuing. We feel that the variety of form factors that Palm OS can run on is a huge asset, and we’re doing everything we can to enable expansion onto every form factor for which there is a demand. So I think it is quite likely that you’ll eventually see a tablet form-factor using some current or future version of Palm OS Cobalt. I’m not sure that it would be flattering to that future device to call it a competitor to the Windows Tablet PC, since I would hope it would be more successful and less blandly generic than that product.
7. How is backwards binary and source compatibility with previous PalmOS versions?
George Hoffman: Well, Palm OS Cobalt is the first version of Palm OS to support native ARM applications. These APIs are called the “Protein” APIs, and they are about 95% source code compatible with well-behaved applications written as 68k apps on 5.X and previous versions of Palm OS. Initial feedback about the effort needed to “port” applications from the 68k APIs to the Protein APIs is that the effort is very minimal. Generally, the only places where existing APIs were changed are where they had to be in order to support a protected memory environment (for example, to remove assumptions about all applications sharing the same address space.)
That said, existing 68k applications continue to run quite well, including those that make use of PNOs (PACE Native Objects, which are blobs of ARM native code used for performance-critical paths on Palm OS 5.X/Garnet). The PACE layer (Palm OS Application Compatibility Layer) has been improved and we’ve tested against a large suite of popular applications. We’ve also been working closely with developers of applications that for one reason or another could not be supported via PACE (for example, if they make use of unsupported system calls or access private structures). We’ve seeded many of those developers and gotten them to clean up their apps to work smoothly across Cobalt, Garnet, and in some cases Palm OS 4.X and earlier.
The compatibility numbers are quite good; in fact, within the set of applications used for compatibility testing, our compatibility numbers are better than during the 4.X to 5.X transition. This is pretty impressive, given that we’ve been through a near complete rewrite.
8. Any plans to integrate more mobile phone capabilities to the OS and let PDA hardware manufacturers to do so easier as the two markets seem to come closer these days?
George Hoffman: Absolutely! Wireless mobile communicators and “smartphones” are one of the primary markets in which we intend both Palm OS Cobalt and Garnet to be leading players. Both products include new telephony features, and integration of these features into the rest of the OS is a big priority. Another demo at the developer conference this week was one in which a Palm OS Cobalt device, while playing a movie, was able to receive a phone call and check some stock quotes while talking, all while the movie continued to play.
Based on the amount of momentum that we’ve already picked up with Palm OS 5.X/Garnet devices like the Treo 600 and the Samsung i500, we think we’re really poised for a big market growth for Palm OS based smartphones. Palm OS Garnet and Cobalt are both designed to support that growth, and you’ll see far more integration of these types of features going forward.