Linked by Thom Holwerda on Mon 11th Mar 2013 14:51 UTC
PDAs, Cellphones, Wireless After a few months of planning, several weeks of work, and possibly a few kilometres of aimless pacing through the living room, I'm happy to present "Palm: I'm ready to wallow now". This massive article (22,000 words) covers countless aspects of Palm, its devices, its operating system, and the company's importance to the mobile industry. I start with a detailed look at the history of handwriting recognition, after which I move on to the four hardware products I believe are crucial in understanding Palm as a company. Of course, I also dive into Palm OS, covering the kernel, its filesystem (or lack thereof), 'multitasking' capabilities, user experience, and much more. Important Palm OS licensees like Sony and Handspring make an appearance, and I cover the failed attempt at modernising the Palm OS: Palm OS 6 Cobalt. Finally, the conclusion ties it all together. For the first time in OSNews' history, you can also buy this article to support OSNews and make more articles like this possible in the future (don't worry - the regular online version is free, as always!). I suggest you grab a coffee, sit back, and enjoy.
Permalink for comment 555406
To read all comments associated with this story, please click here.
Member since:

Thanks for the detailed article. I mostly read the section on Cobalt, since that is primarily what I am familiar w.r.t. Palm, and I thought I could add a few things to the information you have.

Ultimately, there was very little of traditional BeOS in PalmOS Cobalt. The main technologies that came from Be were things that were under development for the "next generation" BeOS that was being driven by Be's focus shift to BeIA from a desktop OS. The foundation for that was the Binder system which, after Cobalt went away, was ultimately open-sourced as OpenBinder and I have archived at for reference.

Nothing like the OpenBinder software was ever used in BeOS -- the implementation in Cobalt and ultimately open-sourced was the third iteration of the design, which was a complete redesign and rewrite from the binder system that was implemented (and barely shipped) in BeIA. However a lot of the implementation of the original OpenBinder code and higher-level frameworks was done on top of BeOS, until there was a sufficient environment to work on it in the core code that would ultimately become Cobalt.

There were a bunch of higher-level parts of the system built on top of Binder for Cobalt, such as a distributed view hierarchy / UI toolkit / windowing system, the media system, etc. These were by and large implemented after Be was acquired by Palm, by mostly ex-Be engineers working at Palm and then PalmSource. The "rich graphics support" was also largely the result of a rendering engine implemented by ex-Be engineers while at PalmSource. Many of these engineers had also been deeply involved in the design and implementation of BeOS, and were taking the lessons learned there to create improved designs for Cobalt. For example, the BeOS rendering system was extremely primitive compared to the new one implemented in Cobalt; the Cobalt system was actually much more like what we expect now on these devices, with full anti-aliased 2d path-based rendering and rich alpha-blending (and not incidentally designed with expectations of being able to take advantage of OpenGL-based GPUs in the future).

The graphics marketing material is actually kind-of funny. That whole "screen sizes of up to 32000×32000 pixels" thing? Yeah, well, all that is based on is the fact that pixel coordinates where 16 bit integers. Which is of course *stupid* because by this point using 16 bit coordinates is pretty stupid -- it's just for compatibility reasons, and in fact 32000 pixels is not a lot once you start thinking about scrolling through large data sets. If I recall right, this came about because some marketing people came to us wanting to know about the maximum screen resolution the new system would be able to support, and what do you really say to that? Well the maximum range of a coordinate on screen.

The initial Cobalt implementation was a transition from the old to new PalmOS. Everything under the hood was an entirely new OS with a much more advanced object-oriented application model, UI system, and other features. However, to get the first product out, there wasn't time to finish all of those pieces, so they were only being used to implement a compatibility layer that sat on top to provide the traditional environment for existing Palm applications. I believe all of the applications you see in the simulator are traditional PalmOS applications (on top of the compatibility layer) -- at this point in the new framework there were basic widgets (buttons, check boxes, etc), simple view layout managers, and a lot of other infrastructure, but it was still missing some final higher-level pieces (like list views) and the API was still too in-flux to be able to write complete applications on top of it.

A *lot* of work was put into that compatibility layer. Many engineers grumbled about how much time was being spent on it and taking away from time to flesh out the New Hotness. ;) It wasn't just old PalmOS in a compatibility box -- all the original PalmOS drawing primitives in it were re-mapped to the new path-based renderer, each form the application made was mapped to a formal window object in the new underlying Cobalt architecture, etc. This allowed us to expose a lot of the features of the invisible new architecture to the old application model, such rendering fonts with TrueType and a new rich 2d drawing API that can be used along-side the traditional Palm APIs, or the status bar slips which were implemented by running a limited Palm API compatibility box to allow the developer to put a traditional form UI in this separate screen area. Plus there was still PACE running, so it could run your old 68k Palm applications inside of PACE on top of the traditional Palm ARM API compatibility layer on top of the new Cobalt architecture. Thinking about this too much would make your head hurt, but ultimately it all worked quite seamlessly.

As far as the lack of manufacturers picking up Cobalt, there were a number of reasons I saw for this:

- At that point device manufacturers still didn’t appreciate the importance of software (hardware was the primary focus, then software), and so didn’t see any reason to buy it when they could as well build it since they were already creating the main part, the hardware, anyway.

- Device manufacturers were and still are very aware of what happened in the PC industry, where one platform provider came to dominate it and turn all of the hardware into a commodity. They didn’t want this to happen to them, so were not only deeply suspect of Microsoft, but of any other company that looked to be trying to become a Microsoft in their world.

- This was a very transitional phase in the industry: PDA style devices were frankly fairly niche compared to the mobile phone market, mobile phones were rapidly getting more advanced and becoming more PDA like, and the Palm-style stylus-based UI did not seem like something that would be much more than a niche compared to traditional phone UIs.

- It was a huge investment for a company to ship their first PalmOS Cobalt product because the entire platform was unique and so needed custom driver work for every piece of hardware on the device. This was part of the motivation for the later switch to adopting Linux as the kernel. (It was also a significant part of the reason for Android building on Linux, which worked out very well there. Linux is entirely sufficient as a kernel for a mobile OS, it’s the stuff that is normally taken on top in user space that will kill you. Which kernel is being used for a device is basically irrelevant for the user’s experience.)

- As far as Palm not adopting PalmSource, I didn’t have enough interaction with them to be able to more than speculate. There was definitely a lot of bad blood with the Be acquisition, where Palm engineers saw the platform they had been working on for years being thrown away and replaced with something new (though not with BeOS in any real sense, just with new software designed and written primarily by Be engineers while at Palm/PalmSource). Many of the engineers who were most unhappy with the upheaval in the software at PalmSource moved back to Palm to continue work there on the old PalmOS platform.

One thing I don’t think that had anything to do with Cobalt’s adoption was Apple. If nothing else, the timing just doesn’t work out: during the time from when Cobalt was done and available to manufacturers until Apple first showed the iPhone I was involved with implementing a large part of a completely new UI design based on the new frameworks in Cobalt, watched that get dropped, left the company for Google and, starting at pretty much ground zero of a raw Linux kernel, worked with a small team to build an entirely new operating system that was well on its way to being done. Cobalt was being shopped around in early 2004; Apple didn’t acquire FingerWorks until 2005. Even way later when Android was being shopped around it was hard to get interest in that (even with it being open source!) due to the same issues with manu

Reply Score: 8