I didn’t really know where to put the final two sections of this article, so I decided to create a small miscellaneous chapter specifically for them. In this chapter, I’ll first detail the importance of Palm OS licensing, after which I’ll dive into the future of Palm OS, as seen from 2004 (which means Cobalt).
Licensing Palm OS
While often overlooked, you can’t really write a detailed article about Palm and the Palm OS without diving into the many companies that licensed the Palm OS for use on their own devices. Sure, Palm itself commanded the vast majority of the Palm OS market, but the licensees played a crucial role in the evolving ecosystem: they became test beds for new features, technologies, and ideas.
From very early on in its existence, Palm intended to license Palm OS to third parties. Instead of scavenging around trying to scrounge up a licensee or two, like so many modern platforms have to do, Palm scored big right at the very beginning: five months after the original Palm Pilot started shipping, they scored IBM. The industry giant was going to sell rebranded Pilots, which eventually arrived on the market about a year later in September 1997 as the IBM Workpad 10u. IBM continued to rebadge Palm OS devices until 2001.
Vertical markets were also interested in Palm OS. And so, in March 1998, Symbol launched the SPT1500, a Palm III-like device with a larger forehead to accommodate a SE 900 Pico Scan Engine (apparently a revolutionary small barcode scanner). You could also get a version of the SPT1500 with wifi built-in (no joke – it had spectrum24). As far as I can tell, this makes it the first Palm device with wifi built-in.
From 1999 and onwards, there’s an explosion in Palm OS licensees, many of which would play crucial roles in the on-going development of the platform and its supporting ecosystem. HandEra (formerly TRG) launched the TRGpro in October 1999, first to introduce a Compact Flash slot. In 2001, HandEra would launch the HandEra 330 – not only was this one of the first (not the first, though, but we’ll get to that one in a second) devices with a ‘high’ resolution display (320×240 instead of the usual 160×160), it also introduced a feature that would become standard on all higher resolution Palm devices: a virtual Graffiti input area.
October 1999 also saw the introduction of the first ever Palm OS device with mobile phone technology built-in, making it one of the very first smartphones on the market: the Qualcomm pdQ. Hardware-wise it was identical to the Palm IIIe, but came with CDMA technology so you could call and even browse the web and send and receive email. Weirdly enough, the phone and Palm OS features were separated; the phone functionality ran its own firmware, and communication between that firmware and the Palm OS was limited. Later versions, after Qualcomm was acquired by Kyocera, improved this integration substantially.
Other than loads of Palm OS devices from smaller, lesser-known companies (my favourites: the AlphaSmart Dana and the Tapwave Zodiac), several big names would become Palm OS licensees: Nokia (never released a device as far as I know, but there’s this), Samsung, Acer, Fossil (for smartwatches – currently all the rage again), Garmin, and Lenovo. As interesting as these were, they were small-time compared to the two big ones: Sony and Handspring.
Sony became a Palm OS licensee in 1999, and unlike some of the other licensees, it really tried to push the envelope for the Palm OS platform with its line of CLIÉ devices. While the first CLIÉ – the PEG-S300 – didn’t exactly set the world on fire in 2000, it did have a unique design aesthetic that broke the mold a bit, and it had a more expensive version with a colour screen, too. This wasn’t the first Palm OS device with a colour screen, but it was among the first.
After getting their feet wet with those first few Palm OS devices, Sony really started to drag the Palm OS platform forward, kicking and screaming. Released in March 2001, the CLIÉ N700C was the first Palm OS device to sport a “high” resolution display, and it did so in a way that didn’t break application compatibility: it simply doubled all the pixels from the standard Palm OS resolution of 160×160 to 320×320 (all that is old is new again). It wasn’t until November 2002 that Palm itself released a device with a 320×320 resolution, the Palm Tungsten T.
Even before Palm adopted the 320×320 resolution for its higher-end devices, Sony had already stepped up the game with what I think is the most iconic of all CLIÉ devices: the CLIÉ NR70. The NR70 introduced the characteristic flip-and-twist design with a full QWERTY keyboard; you could flip the screen open like on a clamshell phone, and you could then twist the display around and close it back up to arrive at a more conventional form factor. It sported a resolution of 320×480, although applications had to be designed to support it (Palm wouldn’t adopt this resolution until two years later (!) with the slider Tungsten T3).
The NR70 had a more expensive brother: the NR70V. The V-model added yet another first for the Palm OS platform: an integrated digital camera with 0.1 megapixel. Sony also released the somewhat odd-looking PEGA-MSC1, a digital camera in the form of a Memory Stick which could shoot pictures at a maximum resolution of 320×240. You could use this with select CLIÉs with Memory Stick slots. Just to illustrate how far ahead of the curve Sony was: only two years later did Palm release its first device with a camera (the Zire 71).
I’ve always wanted a CLIÉ back when they were still current, but they were quite hard to come by where I lived. A few years ago I bought two CLIÉs from one of our French readers, one of which is the PEG-NX80V, one of the later flip-and-twist models. Its camera no longer works and the display has odd discolouring issues (I intend to open it up to see if I can fix it), but the whole form factor is quite pleasant. The keyboard is rubbish (impossible to properly type on), but twisting and turning the display is very satisfying. It’s sad the mobile world has pretty much converged on boring slabs – I’d love Sony to release a modern, dual-screen interpretation of the flip-and-twist design.
Other than these specific firsts that Sony brought to the Palm OS ecosystem, a big focus of the company was multimedia – imaging, video, ATRAC and MP3 playback with remote control-equipped headphones (my NX80V has a stylus tip built into the remote!), and so on. This wasn’t really a focus for Palm, but Sony showed them how it was done. In fact, Sony was so far ahead by this point that not Palm, but Sony was the first to launch a Palm OS 5 device (and, thus the first ARM device). Heck, Sony even went so far as to develop its own unique ARM processor for CLIÉ devices.
Before announcing the end of the CLIÉ line for European and North-American markets in June 2004, Sony had one last crazy trick up its sleeve for the world: the CLIÉ PEG-UX50. The UX50 (and its cheaper sibling, the UX40) was a really tiny Palm OS laptop with a twisting display. Pretty it was not, but it more than made up for it with its sheer awesomeness. I’d love to have one of these.
Japan got to enjoy the CLIÉ line for a year longer still, but in early 2005 the curtain closed in Japan, too. However, Sony just couldn’t resist going nuts one more time, and in late 2004, it released a… Palm OS tablet: the PEG-VZ90. This crazy-looking contraption sported an OLED display, and has so much ‘want’ written all over it that it was only available in Japan. I’m fairly certain when I say none of us have ever seen one of these exotic beasts in real life (yet another reason to visit Japan).
And with that, the CLÉ line met its end. Sony had made significant contributions to the Palm OS ecosystem, and its focus on improving the multimedia aspects of the platform benefitted all Palm OS users. Their sales never even came close to that of Palm itself, but they left a definitive mark on the Palm industry.
Handspring is an entirely different animal than Sony or any of the other Palm OS licensees. The company has a very unique history in that it was founded by none other than Jeff Hawkins himself. In 1998, Hawkins and Donna Dubinsky had become unhappy with where 3Com – then owner of Palm – was taking the platform, since they realised that the PDA business wasn’t going to stay around forever. “The handheld computing business is going to go away,” Hawkins said at the time, “It’s going to become part of the cell phone business.” Hawkins was always one step ahead of everyone else.
So, Hawkins and Dubinsky left Palm, and founded a new company called Handspring. They licensed the Palm OS right away, and one year later, September 1999, it released its first two PDAs: the Visor and Visor Deluxe. Handspring’s first distinctive feature was the Springboard expansion slot; a proprietary slot that could house just about anything from memory cards to cameras, GPS modules, cellular modules, MP3 players, wifi, BlueTooth, barcode scanners, games, and much, much more. The importance of the Springboard slot’s ability to house mobile phone technology is evidenced by the fact that all Visor PDAs were equipped with a microphone specifically for phone expansions.
The craziest accessory every to be made for Springboard? I doubt you want to know, so skip the next quote box if you don’t.
Raynet Technologies unveiled today the world’s first body massager Springboard module for the Handspring Visor. Designed by Singapore Corporation, Raynet Technologies Pte Ltd, the Raycom Personal Massager converts the Handspring Visor handheld into a massaging device, while maintaining other computing operations.
It’s even been reviewed. I didn’t bother to read it, but here you go.
Handspring continued to build and sell the Visor line until it was discontinued in 2002, because the company had something far more special up its sleeve: the Handspring Treo. The Treo 180 was the first of the line, and came in a version with a QWERTY keyboard and a version with a Graffiti input area (the Treo 180g). Handspring released several more models before it was acquired… By Palm.
Following the Merger, Palm would continue to release several new and updated Treo models. They were quite popular – in fact, in the US, Palm enjoyed a smartphone market share in late 2005 of 31%, second only to RIM’s 55%. As far as I can tell, the Palm Centro, released in late 2007, is the last Palm OS device Palm ever made – before switching to webOS. It ran Palm OS 5.4.9.
Handspring innovated both in and outside the Palm OS ecosystem with the versatile expansion slot and, more importantly, with the Treo. Thanks to the Treo and its success, Palm was given a crucial stay on the way to its demise, which gave it just enough time to develop the next chapter in the company’s history – but that’s a story that has already been told.
Where to go from here (if here is 2004): Palm OS 6 ‘Cobalt’
Before I let you go, there’s one last chapter to this story before we wrap things up. This won’t be a happy chapter, and it won’t be about remarkable aspects of the Palm OS you didn’t know about, nor will it be about cool technology from the ’50s. With this last chapter, I won’t be able to strike the string of nostalgia either – because we’re going to talk about something that has never been released.
For those of you who’ve seen Fucking Ã…mÃ¥l (and for those of you who haven’t: shame on you), remember that gut-wrenching scene that dragged on – intentionally – for what seemed like bloody hours where nobody showed up for Agnes’ party? Where director Lukas Moodysson forced you to watch the naïve hopefulness of Agnes’ mother as a stark contrast to Agnes’ depressed anger?
Well, Cobalt is like Agnes. Nobody showed up for Cobalt’s party either.
So far, I’ve been largely successful in ignoring the ownership situation of Palm OS, but for this last chapter I can no longer get around it. I’m not going into too many details, so here’s the Cliff’s Notes: Palm thought it was a great idea to create a wholly owned subsidiary dedicated to the development of Palm OS, called PalmSource, in 2002. They thought they had an even greater idea when they spun PalmSource off as an independent company in 2003. PalmSource was then acquired by ACCESS in September 2005.
Before being acquired by ACCESS, PalmSource worked on the future of Palm OS: Palm OS 6, better known as Cobalt. PalmSource took this matter quite seriously, and went for an almost ground-up rewrite; they stated around 80% of the code was rewritten. Cobalt was meant to bring the Palm OS into the 21st century, and included many features that had long eluded the platform. Sadly, since not a single licensee adopted Cobalt, information on it is patchy, at best.
First and foremost, just as Jim Schram had already predicted way back in 2002 when talking about the then-new MCK kernel in Palm OS 5, Cobalt finally exposed the system’s inherent ability to multitask to application developers. It was a fully ARM-native 32bit operating system with multitasking and multithreading, so multiple applications and services could run at the same time. It had a background processing model designed to “reduce most memory problems commonly associated with multitasking in mobile devices”.
Related to this, Cobalt also introduced protected memory, so that a crashing application would no longer be able to drag down the entire system. In addition, the maximum RAM and ROM limits were both raised to 256 MB, with the ability to raise this even higher in the future. Loads of security features (like industry-standard encryption stuff for enterprises) were added as well as core parts of the operating system, and it had a brand-new communications framework based on STREAMS, which supported multiple concurrent communication sessions.
A particularly interesting aspect of Cobalt was its new, extensible multimedia framework. As most of you will know all too well, Palm bought Be, Inc. and the BeOS in 2001 (yes, OSNews dates back that far!), and since BeOS is software, it ended up at PalmSource after it was spun off. Cobalt’s multimedia framework and its “rich graphics and multimedia features” came from BeOS, and may even have been designed and written by former Be engineers (I can’t find confirmation that actual Be engineers worked on it, though).
Coded by our Be superheroes or not, the BeOS-derived framework brought Palm OS up to speed with the rest of the industry, and provided it with, among other things, rich graphics support with “paths, rotation, gradient fills, anti-aliasing, outline fonts and transparency”, and supported screen sizes of up to 32000×32000 pixels (!). It also supported various audio and video formats, and developers and licensees (ha!) could easily add support for more.
Cobalt included an emulator so it could run applications written for Palm OS 5 and earlier. However, only “well-behaved” applications would run without modifications, while more complex ones would need modifications. Supposedly, Astraware’s David Oakley ‘ported’ Bejeweled to Cobalt in less than half a day. Of course, developers could also write applications specifically for Cobalt, which were called Palm OS Protein applications. Interestingly enough, these could apparently be compiled for both ARM and… x86. I have no idea if ACCESS had plans for an x86 Palm OS.
On 10 February 2004, Cobalt was released unto the world – however, nobody, not even Palm, licensed it, preferring to ship Palm OS 5.4.9 instead. So, PalmSource went back to work and released Cobalt 6.1 in September 2004, which added an “enhanced” user interface (it looks exactly the same as before, just with slightly differently-designed buttons), and integrated a few things that were optional before (like BlueTooth and wifi). Sadly, nobody wanted Cobalt 6.1 either.
Since Cobalt never made it to market, there’s not a whole lot to add here – I can’t refer to reviews of devices, I can’t talk about personal experiences, nothing. All we have is a preview by Brighthand’s Ed Hardy, who notes, among other things, that yes, the BeOS-inspired multimedia framework could display a movie playing on all sides of a spinning cube. Which is very, very useful in real life computing scenarios both mobile and desktop, and don’t you dare tell me otherwise.
It’s worth noting that there is actually a freely available Palm OS Cobalt emulator that was provided by ACCESS. It’s still available, and runs on Windows 8 just fine. It runs the full Cobalt operating system in a window, and you can change several settings like resolution, memory, and so on. It’s pretty fast, but looks dated (despite the updated UI), and it misses several key applications (like the browser or an email client). Still, because you’re controlling it with a mouse and there’s little you can actually do with it, it can’t possibly form the basis of something resembling a review.
And this is where Cobalt’s story ended – or so I thought. I always thought that not a single Cobalt device was ever made – but during the long process of planning and writing this article, I stumbled upon an article by Bob Russell at mobileread, which confirms that Cobalt devices certainly did exist. The report is corroborated by David Beers, a Palm OS developer who actually handled one of the prototype devices.
A company called Oswin Technology, based in Singapore, designed and built two devices running Cobalt in 2005 that were offered for sale at the last PalmSource DevCon before ACCESS acquired PalmSource. Russell even provides three full-page scans of the advertisements for the devices, which list all the specifications and two beautiful photographs of the devices. One was a candybar phone, the other a slider (?), but otherwise had nearly identical specifications. They sported a FreeScale i.MX21 processor, and 64MB RAM/128 MB ROM.
They aren’t exactly beautiful or anything, but they are – as far as I know – the only complete Cobalt devices ever made. I wonder how many were sold at the time; I guess it depends on their price, and on just how many people were at that specific PalmSource DevCon. I wouldn’t peg the number at much higher than a few dozen, making this one of the most exotic Palm OS devices ever made – perhaps the most exotic. Interestingly enough, it seems that one of the two devices did make its way to market as the Zircon Axia A108 – running Windows CE.
The elephant in the room right now is of course why, exactly, Cobalt failed to attract licensees. I think the answer to this question doesn’t really have anything to do with Cobalt itself, but more with the storm that was brewing in Cupertino. By this point, all traditional Palm OS licensees had left the platform behind, except for Palm itself (and even they defiled their heritage by selling several Windows Mobile Treos), meaning that unless PalmSource could attract new licensees, it would have to rely on Palm.
However, I don’t think it’s far-fetched to believe that because several of Palm’s employees had ties to Apple, they were aware – to a certain degree – of the work Apple was doing on the iPhone, and that Cobalt would not be competitive enough. In other words, no matter how much of an improvement Cobalt was compared to Palm OS 5.x, Palm didn’t believe it was good enough to take on Apple’s upcoming iPhone.
And from what I’ve seen of Cobalt, they were right.
While Cobalt’s story ends here, ACCESS didn’t stop trying to squeeze more blood from the dry, withered stone that is Palm OS. Aside from Palm OS 6.x, PalmSource/ACCESS had also developed Palm OS 5.5, which was designed to run in a dedicated virtual machine so other possible smartphone platforms could run Palm OS applications (it made its way to Nokia’s internet tablets). Like Cobalt, nobody was really interested in this thing either.
However, this product, later renamed to the Garnet VM, was to play a crucial role in ACCESS’ next attempt at gaining traction in the smartphone market: the ACCESS Linux Platform. As its name implies, ALP was a Linux environment based around Gtk+ and GNOME technologies, which could also run mobile Java applications. On top of that, Garnet VM was built-in to provide compatibility with applications for Palm OS 5.x and earlier. Its user interface was essentially a slightly more modern-looking Gtk+ recreation of the Palm OS graphical user interface (although the last version, from 2009, doesn’t have much in common with Palm OS any more).
ACCESS failed to find any licensees for ALP. Its website stands as a 404-ridden tomb of broken dreams and unfulfilled aspirations.
As a sort-of conclusion to the Palm OS and Cobalt chapters, here’s a short overview of the major Palm OS releases.
- Palm OS 1.0: 1996
- Palm OS 2.0: 1997
- Palm OS 3.0: 1998
- Palm OS 3.5: 2000 (a point release, but a major one)
- Palm OS 4.0: 2001
- Palm OS 5.0: 2002
- Palm OS 6.0: 2004
- Palm OS 6.1: 2004 (September – the final Palm OS release)
And that’s all she wrote.
Anyone got a link to the PDF?
Seriously, I’ll read the article later when I have some time
I kinda like the experiment. Let’s get rid of the shitty ad based culture – which I don’t see anyway as I use an ad blocker, who does?? – and get back to paying people for making content.
I hope Adam gets a slice too for hosting the site.
You will get my money Thom
Edited 2013-03-11 16:16 UTC
I agree with you. I will purchase as well, I would like to support this, and the ad driven model just promotes views with incendiary headlines.
The ads on osnews aren’t annoying at all, I’ve deactivated my adblocker here.
As long as these 2 points (no annyoing ads and good content) are valid I don’t see any need for an adblocker.
I bought the PDF. I’d like to see more long article with deep insight in history, development and decisions of a company. Maybe also some (technical) interviews with developers (e.g. with Jolla / Mer people)?
I can’t disagree more. The whole idea of advertising is to brainwash you to buy something or to buy a specific brand.
Clearly this brainwashing is working else advertsing would have stopped a very long time ago…
To me it seems that every year humans become more and more a consumer, someone you can sell something to, an economic resource rather than a fellow traveller of life.
I also don’t buy into the argument that else ‘many sites would disappear as you deprive authors from an income’. Before 2000 most websites including OSNews -still is- were a labour of love, content was good, web design often bad geocity anyone??. After the commercialisation of the net, it’s often a dime a dozen.
Just take a look at technology sites: engadget, theverge, ars technica, pocket lint, boy genius report, anand, pcpro uk, wired, slashgear, etc etc.
Now surely they look slightly different and all have a slightly different angle but by large they review the same products. Often their existence is to make money from product announcements by showing (bucket) loads of ads beside the products AND to sell browsing stats to companies (the verge has EIGHT trackers listed by Ghostery).
IMHO it would be extremely welcome if we lose some if not most of these sites, rather sooner than later…
Edited 2013-03-12 13:24 UTC
I don’t use an ad blocker – if some site has irritating amount & style of ads, it’s a good reason to not visit that site.
And OSNews is not among such sites, it respects its readers (but you wouldn’t see that, running ad blocker everywhere)
Blocking ads has nothing to do with OSNews or obtrusiveness.
If you allow ads, you allow yourself to be willfully manipulated. We are manipulated enough anyway in this world.
Better to pay for the content upright rather than by ads.
PS my other post got stamped into the ground, but I did actually pay 5 euro and have countless subscriptions on Zinio.
No, not really. Subliminal messages and brainwashing with ads are in the same category as astrology, energetic bracelets, fairies and most “alternative” therapies. Starting with the fact that one of the pioneers in subliminal advertising manipulated his results, because his experiments didn’t really work the way he expected. Today, this ideas are very discredited. Yes, every now and then an article appears, that suggests that this messages may have some influence, but a very limited one. And of course, isolated studies don’t mean much.
So, no. At best this is all pseudoscience. If you want to buy into it, be my guess, but pretend it is a fact.
Sure, subliminal ads are highly dubious.For instance they tried to put a frame of a coke bottle into some frames of the movies. Too fast for the rational mind to spot but maybe it would subliminally be picked up.
I think that failed.
But we are not talking about subliminal advertising here, we are talking about ‘in your face’ advertising. There is no way the mind can ignore what it sees on the page.
That advertising works is clear: Google makes billions out of it and we haven’t stopped advertising since 1900.
If you’re so paranoid about the influence of advertising on you, you must not leave home much… (after all, ads everywhere); also, don’t watch any films (product placement).
Articles can also be manipulative (such as this one, suggesting that alternatives to WebOS are better). OTOH, ads can be informative (just the other day one brought a new mobile network to my attention, with good offer; earlier, a new band ad on last.fm)
TL; DR
Joke, didn’t read because it’s 5 dollars.
The online version is free, as always on OSNews.
I know, it’s just I rarely get to complain about this site.
OSnews sold out!
Dividing auditory in two – peasants get no picture version, while rich get premium content.
Edited 2013-03-11 15:55 UTC
I bought a copy, even though I don’t really care for dead tech companies all that much. I just like trolling this site, hence the show of support.
It would be nice if you offered a couple of full-colour preview pages, though. Especially useful since $4.99 would seem a bit much for people raised on $0.99/$1.99 mobile purchases.
I know Gumroad offers some sort of a preview feature for sellers, so maybe you should look into it.
Edited 2013-03-12 13:03 UTC
Just wanted to congratulate you, Thom, on completing this opus amoris magni. It’s inspiring to see tech histories like this that weave diligent historical research with a competent understanding of the technical side. And might I add more plainly that I really enjoyed the article. Bravo. (Looking forward to paying for the PDF!)
Yup, I haven’t had the time to read it yet, but want to thank you for the time it took to pound the monster out. I’m sure it will be interesting reading.
Thanks guys!
Thom, congrats!
If you add Maemo/Meego/Moblin to your OS lists, would be greater yet!
I just skimmed over it, but I’m surprised you didn’t mention psion
Psion and Symbian is all reserved for the next article! Collection of data has already begun – shopping for devices is the next phase.
So hops hops, buy the article
.
Regarding Symbian, I advise you to have a look into
http://www.developer.nokia.com/Develop/Featured_Technologies/Symbia…
for the technical stuff.
The site is probably the only information still available online about how Symbian works.
Couldn’t care less about Palm, cry me a river PalmSource. They bought a mermaid princess and locked her away in the basement, where she eventually died. They could’ve went all Red Hat Enterprise and stuff, like making OpenBeOS platform free software and selling specialized professional applications with it, but noooooo. They had goods on the hands and they screwed the pooch. We all know the rest of this story – Apple won, Jobs was ill, but proud daddy king and had a blast destroying everyone else with machinegun. Including Palm.
A great article that brings lots of memories to life, i really enjoyed reading it. Thank’s for the excellent work you made.
Ever thought about getting a Flattr account? There are already outstanding Flattrs on your Twitter feed, that you just need harvest. I think it’s a pretty neat system and the sum of small contribution surely adds up for a great site like OSNews!
Buying before I even read the online version, definitely want to support your work Thom. Hopefully the PDF doesn’t look too small on the Kindle (if the PDF was designed for A4); could I ask for an ePub version though?
I tried to create an EPUB version, but I came to the conclusion that the format has been designed by morons. It’s basically just an HTML container, but every reader renders it in its own special way. After days and days of headaches and completely broken formatting on every reader, I gave up
.
I’ve look at the format too, and it is indeed crap. In my ideal world All eBooks would be regular HTML5 and all eBook readers would use a WebKit or Gecko engine. The reason ePub breaks so much is because vendors keep munging into something custom other than good-ol-reliable-HTML5.
What tools were you using to write the article / convert it? For Word Documents, I’ve found Aspose.words to be by far the best at producing something sane and usable from MSWord.
Raw semantics are the way to do it. I’m thinking of extending ReMarkable to publish to ePub so that I can use a markdown syntax to write and ensure the simplest possible HTML output.
I used Pages. Works great for everything except EPUB, or so it would seem (I want to marry Pages – god I love that software).
Thanks for buying, by the way
.
Try saving as MSWord, then run it through Aspose.Words in Windows, that’s always worked on my Kindle fine (though you will need to set the correct title / toc bookmarks, but I can help with that)
Seriously?!
… Why?
Say what?!
You are not doing much web development I imagine.
In the world of ebook readers, having a plain web-browser engine to do the rendering is *incredibly* reliable compared to the neither-a-browser-nor-a-text-layout-engine renderers that most readers use. Use of CSS on these arcane static renderers is a complete dark art.
Faire enough in that context I imagine then.
In my ideal world, eTexts would also be available in pure ASCII text-only format & all eBook readers would be able to import text files. Then you could do whatever you want with it & read it using whatever software you want.
In fact Thom, is yours available in text format? I’d love to support this kind of article, but formats like PDF are pretty useless to me. I found it a facinating read & would love to see more of this kind of thing. It doesn’t even matter if I agree with everything that’s written. The important thing is, you got it out there & it can spark a whole load of interesting discussion.
Well done!
(I can’t wait for the Psion/Symbian one)
Well, you could download the HTML source and strip it
.
In all seriousness, I’ll be sure to add a .txt version to the next article’s .zip. Small effort.
What about .mobi? That’s the native file format for the Kindle anyway (except that Amazon ebooks are wrapped in DRM, but inside of this, there’s just mobi)
I tried doing direct-to-mobi conversion with MobiPocket / Calibre, but the process just didn’t function right.
I spent about five days working on a process to convert a Pages document to Kindle in a way that actually worked. Software out there is unbelievably broken. The format is broken, the converters are broken, the readers are broken.
The only process I found that actually worked was Pages (or any other format) > MSWord > Aspose.Words > ePub > KindleGen = Mobi file
FictionBook (fb2) is another option: https://en.wikipedia.org/wiki/FictionBook
This is why I’m reading OSnews.
I still have IIIxe and Centro and I used them until recently. My Centro in laying in shelf, 4th day on 0% battery and still working.
Wow. I can’t believe you claimed WebOS killed Palm. WebOS was the only BRIGHT SPOT of Palm. I owned Palm Treo’s and Pilots and I HATED THEM. When I got the first Pre and used WebOS I was in heaven. WebOS is literally the best mobile OS experience I’ve ever had and I think Steve Jobs was nervous at first. So much so they changed iOS to have kinda multitasking. They couldn’t copy the flow of WebOS because it was patented so they did their own bit that was okay but still wasn’t anything close to WebOS. Android the same issue. Why go to a dumb task manager box to select which program you go to. Having the Card minimized, but still running WAS BRILLIANT.
I wish we could see WebOS running on the newer 1gb of ram phones with dual core processors. The OS is amazing and for you to gloss over it and even claim it’s the reason Palm died is ludicrous and I hope NO ONE buys your PDF because WebOS wasn’t the problem. The hardware the OS was operating on was the problem. Sorry you were late to the game on WebOS, but if you really studied it and looked at Android and iOS. NO mobile operating system could compete with it. I would even say if you put WebOS out today on a beefier phone that didn’t crack when you dropped your bag at work it would definitely beat Windows phone and BB phone and give it time might compete with the big two.
HP didn’t know what it had. They bought it and then when they couldn’t understand what exactly to do with it they killed it. Except now it lives on LG TVs. So another reason your assumption of WebOS is CRAP is that if it was such crap then why is it still kicking around on HP Printers and now LG TVs?
Like, say, the TouchPad?
The TouchPad is no phone, but it gives a glimpse into what to expect in terms of performance. As a TouchPad owner I can assure that at least performance-wise Android 4.x is running circles around WebOS.
Sadly, I agree that Android (CM9) boots and runs great on my Touchpad, where WebOS was a bit slow and clunky.
I still have a soft spot for WebOS though, even if I don’t currently use it. The card UI paradigm was awesome and far easier to use for task switching and management IMO.
Thom didn’t claim that. Read again: “… it is my view that Palm was already long dead before webOS ever even arrived on the scene.”
For me webOS was a real gem, so I was a bit disappointed to read that it failed to impress Thom. But on the other hand we had a different mobile history and Thom’s view was invaluable on the history of mobile computing.
You are right on the spot. webOS had great potential, but had some delusional masters. In my point of view it was a victim of great mismanagement, which unfortunately doomed it forever. I hope I’m wrong, but I don’t see a bright future for the open source version of webOS.
You are right about PalmOS, but wrong that WP or iOS copy it. They don’t have the inter-app comm paths or the rest. I’m not sure about WP but iOS is on the left side of the sweet spot. Crippling is not simplicity. They still don’t get the Zen of Palm – you must allow anything which enhances the experience.
You didn’t mention the Kindle, but were it opened it would be at the sweet spot.
Yeah. PalmOS is “there you have it”, where iOS is “there you go”.
Palm OS 5 did support fat binaries, almost all applications with ARM support were. I think you had to get a special compiler from ARM themselves to make ARM-only applications. For CodeWarrior or GCC, you wrote a 68k application and linked in resources of ARM code (known as “ARMlets”). These had full access to the ARM CPU, but calling back to PalmOS was awkward and all the UI code was still done with 68k code.
Sorry to hear that webOS didn’t impress Thom. It can certainly be sluggish, the browser sucks (I could also lay those charges at my Nexus 7, which is oddly frustrating to use at times despite excellent hardware), and I have to carry around spare batteries etc, but I’m keeping my Pre 3 until I find something, anything, that comes close to offering me the same experience. I adore the thing. Never having owned a Palm OS anything, I can’t compare, but – after coming late to the webOS party – I have the same feeling of regret and grief you feel for BeOS. BB10 may come close to filling the void, but there’s something characterful about Palm’s flawed little OS that can’t be reduced down to whiz, or features, or specs, or even the card ui; using it just makes me happy.
Edited 2013-03-11 20:59 UTC
Here’s my ‘review’:
* For those reading via PDF, a _lot_ more images would have been appreciated as 1) hyperlinks were not working on my Kindle and 2) without tabbed-browsing using hyperlinks are painful on an e-reader
* For the PDF, an A5 format would have been better. Most e-readers are small form-factor and scaling from A4 to A5 just makes the text hard to read. I had to read in landscape mode
* An ePub / Mobi format would have been preferable to some. Whilst very difficult to do, it is kindest to embed the text of external content as footnotes in an eBook, so that offline reading is possible and the hyperlinked text in the main article can be followed and its context learnt
* Reading as a book, I actually felt as if the article was too short! I was enjoying it very much and felt it was all over a bit too soon. If you intend to do “offline” versions (i.e. PDFs) of articles in the future, please bear in mind the use-cases of such offline content and expand your writing to state what you are subtly inferring behind your choice of hyperlinks, which are easy to understand on a desktop device, but much harder to grok between-the-lines on a mobile or e-reader device
* The various model names brought back a lot of memories. I used to work at a consumer electronics superstore in 2003, a period when the hardware was getting pretty powerful (300+MHz ARMs) and WinMo was edging past Palm thanks to HPs range of devices. It was a time where it was just becoming obvious at the consumer end that the PDA and the phone were about crash into each other. Most PDAs had some kind of Bluetooth or WiFi option / expansion and though the cost of data plans limited such access to corporate users, I could see that all the complexity and fiddliness of owning and configuring PDA+Bluetooth Adapter+Nokia Phone was going to get blown away by something that put it all together. That’s why the XDA was such a big thing (I think it needs a brief article of its own). That’s what killed Palm as a viable platform IMO. The XDA+PocketIE was to Palm as much as iPhone+Safari was to WinMo
* I’m glad you didn’t go into WebOS; I don’t think it’s at all relevant to Palm OS and would have only detracted from the article
* Overall an excellent read, thanks
Edited 2013-03-11 23:58 UTC
Thom, I’d really love to buy it – but I normally don’t keep my credit/debit cards within reach. Is there any chance Paypal might be in the future? I have everything connected to that.
Either way though, been reading for years and I’ll support you with this when I figure out where I left my wallet!
MCK = Mike Chen Kernel. While discussions were going around what to license in the port from 68K to ARM, at some point everyone realized the home-grown kernel was just fine.
LETS DO THISSSSSSSSSSSSSSSSSS
http://www.palminfocenter.com/news/8493/pilot-1000-retrospective/
http://www.palminfocenter.com/graveyard.asp
and can’t wait to read it later on today. Making me seriously nostalgic for my Palm IIIc; pretty much took all my lecture notes on that with the fold out keyboard.
I started with a Palm Pilot Pro and had a couple of cradles. It fitted really nice in to one, creating one object. Too bad I never got it to synch with Linux, but it did with Windows. I carried it around in a leather case. My Psion 3a was a much superior computer, but the Palm was more fun to use due to it’s stylus input and size. It was also more sturdy. The Psion always gave me the feeling it would shatter if dropped.
Later I bought a Palm Vx (8 MB vs 2 MB of the V). It sleek looking device. I synched it with AvantGo, which was a bit like an RSS service, synching news sites in to a mobile version readable on the Palm. My train travels become more fun reading news and playing Hearts.
My last Palm was a Palm T|X. Now I had a color screen, which was very cool. It had Tomtom navigation and even a web browser. On holidays I roamed the streets with it looking for open WiFi so I could synch AvantGo.
I still have all 3 Palms, although the Palm Vx has an alternative launcher which, for unknown reasons, keeps forgetting its settings. Rather annoying.
I can hardly wait for Apple to implement Ted Neslon 50 years old ideas in their “walled garden” and than to read, all over internet, how Apple rip of Ted Neslon (as they rip GRID, GRAIL…)
btw
good article thom, especial that history part!
Tried to buy via IE and it failed – after pressing “Ik wil dit” nothing happens. Had to switch to Chrome to do the actual purchase. Will start reading now!
I think I’ve clicked at least 10 URLs (in the PDF) that failed to open, mostly because of typos. Bad!
It’s not typos – I *just* found out PDFs don’t accept # in links, for some reason. I’m currently checking every URL – again – and fixing them. I’ll push out an updated version ASAP (I can send out a quick email to everyone who bought the PDF).
My apologies!
The updated version – v1.0.9 – with fixed links has been pushed out. You should be getting an email about it.
Thanks for pointing it out to me, jal_, this was crazy! My heart was racing as soon as I found out a few of the links were mangled
.
At the end of those Thom could probably publish a (compilation of writings) book about phone OS history.
Should consider this.
It’s easy to self publish on Amazon and others.
Edited 2013-03-12 12:48 UTC
“That faithful day in the company boardroom, when they all agreed to spin off the Palm OS, Palm sealed its fate.”
Surely you meant “That fateful day”? But then you would be repeating “fate”…CONUNDRUM
I had an original palm pilot. It was not as quick as you describe. However, I was running it with a later version of palmos than it shipped with that might be the reason? Not sure really, but it could be slow & laggy at times.
The cpu on those was also just too slow to do things with the serial port. We ported our software to it, but it would take ~30 minutes to transfer a 2 mb file compared to the 5 minutes it took win ce. The arm based palms were too late for us to consider using. At the time it was trivial to take code for desktop windows and have it run on win ce/pocket pc regardless of the cpu.
I disagree with the conclusions about the palm pre’s. The software was ok, the hardware was not. I almost went with a pre2 instead of a samsung galax s as I wanted a hardware keyboard. But it turns out, not having a keyboard is better than a crappy one :/
Its okay, I want to but a motorola too, but they keep screwing me over with their hardware ( locked bootloader, no sd card, no removable battery, etc). I think the next phone will probably be a google-moto.
Damn, those 16 years went by fast…
Thom, I had a Pre 2 and did not experience the horrendous battery life you’re referring to. It must be related to your test device being old and the battery already being worn out.
As for slowness, I also couldn’t complain. At the time it came out it wasn’t cutting edge but it also wasn’t slower than similarly priced Android models (remember, the Pre 2 was priced budget/mid-range). Many operations were significantly faster than on Android (at the time) — Just Type vs. Google Search to search the contents of the phone, for instance, was a lot faster and had a much better UI. Task management was certainly a lot faster/better. Other than that, the only slowness I can recall related to issues with the mobile internet connection being flaky and maximum EDGE speed — this was due to being a U.S.-targeted tri-band phone being used in Europe (which admittedly was really annoying and ultimately the reason I moved on). But for pure UI interactions I don’t recall too many issues, at least not after the first couple of firmware versions… You just need to remember how old the Pre 2 is by modern standards. At the time it came out, for the price, it was perfectly capable.
Also, regarding quality of the hardware I never found it to be lacking. It didn’t have quite the polish of an iPhone, sure, but it felt great in the hand and the keyboard was above-average IMHO. The only issue I had was that I accidentally hit the Return key all the time while typing SMS’s, but a simple patch remedied that.
I guess you really need to have lived through it at that time, and to have believed in the future of the platform, to understand what was so great about the OS. It’s easy to forget how techy-targeted and obtuse the Android UI used to be in comparison, and how limiting iOS was without multi-tasking and notifications (it still is today, but to a lesser extent). In contrast to today’s fast and pretty Android phones it’s easy to write WebOS off as unimpressive, but at the time it came out there was nothing else like it.
Edited 2013-03-12 18:17 UTC
An entertaining article that rekindles fond memories.
There were a couple of omissions to Palm history that are important: 1) the Lifedrive and 2)NAND.
Palm introduced the $400 Lifedrive to much fanfare. It was meant to compete with Apple’s iPods of the day. I recall meeting a Palm rep who was showing it off at one of those electronic stores that has since closed. It relied on a 4GB hard drive as storage and memory, to my best recollection. This memory arrangement had bad effects. Many complaints surfaced about frequent freezes and lockups. Although it was a beautifully designed machine, but with a rather poor, blue-tinted screen (something Palm was notorious for) it was a failure.
After the Lifedrive Palm started to bring out their phone line they switched to NAND flash memory. Palm touted this “feature” by stating that users would no longer loose their data if the battery ran dead. Unfortunately, as the hard drive had done in the Lifedrive, the NAND introduced other problems such as instability and lack of instant speed so valued up until then. Software utilities soon sprang up which were needed to flush the cache.
The best Palm-made non-phone device has been acknowledged to be the T3, a device with a decent screen that I bought used. The second best was the Tapwave, which is another company with a sad story. The Tapwave had many digitizer screen problems and joystick controller issues. I had to return mine 3 times before I got one that function satisfactorily. Neither of these units use NAND and are still going strong. The Tapwave was to have been a new gaming platform. Unfortunately, it was released right before the PSP.
As far as Sony’s later offerings they were uniquely designed on the outside but woefully underpowered and way overpriced. I think the UX50 ($500 or $600?) and some others used Sony’s proprietary CPU which only reached a speed of something like 125khz. Sony never advertised the speed, of course.
I looked at the UX50 when they came out. Sony shrank the screen to fit the device so it was smaller than competing Palm screens and darker. The keyboard buttons were completely flush with the wavy designed base and made it hard to type. This is another case of form over function I am afraid.
Once Sony left the PDA business Palm was doomed partly because it had no competition to push it forward. By that time the cell phone revolution started.
Edited 2013-03-12 18:29 UTC
I had the choice between the LiveDrive and the T|X. I went for the T|X because it was cheaper and it was part of a bundle that included Tomtom navigation.
At the time I remember that the LifeDrive was a very nice and interesting device, at least in theory. Apparently it wasn’t so nice in real life use.
If the LifeDrive didn’t have its flaws it may have become successful enough to give Palm some extra hit points.
I’ve not read it yet and I’ve paid up. This is such a great idea Thom. I hope it gets the support it deserves.
Hey OSNews and Tom
I have been lurking on OSNews and reading your articles and comments ever since 2002. I registerred just to say that I purchased the PDF. Thanks a lot for your work and keep it up! I will support OSNews.com, it has given me a lot of insight over the years.
// DragonFlyBSD fan and Debian user
I know a complete Palm. WebOS part is too little, and where is Hwkins now?
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 http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.h… 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
Whoops, got truncted; here is the rest:
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 manufacturers and their relationship with software. In fact, the introduction of the iPhone I think was very good timing for Android since it finally burst a lot of bubbles about the (lack of) importance of the software platform, and here Android was basically already ready to provide a similar software platform for other companies to use.
As you hint, there were indeed actual PalmOS Cobalt devices that were under development, in conjunction with the software work on the platform. There was one major company that PalmSource worked with for quite a while and was close to shipping, and then that company canceled the project. (I heard later that standard practice for this company was to have a bunch of devices under development at the same time, and then towards the end kill all but a couple that they thought had the most potential. I don’t however have any idea what the actual circumstances were for this, just that it came as quite a shock to the engineers because we thought things were going well.)
I mentioned above about another UI design built from Cobalt, which I didn’t see mentioned in the article. This was actually shown publicly — http://www.mobileread.com/forums/showthread.php?t=4153 is a reference to it that I found with a quick search. This was much more than a concept; this was the new modern PalmOS that was built directly on top of the new frameworks that were hidden away in Cobalt, and had a significant amount of working implementation. A big point of it was to provide a UI that works *without* a touch screen, because the traditional PalmOS design requiring a stylus touch screen had actually been a big stumbling point for getting interest from phone manufacturers. And there actually was significant interest from at least one manufacturer, who ended up in a bidding war with ACCESS over PalmSource because they wanted to get the Rome platform. (That said, I think PalmSource would have many of the same troubles trying to license the software to other manufacturers, for many of the same reasons Cobalt had trouble.)
Finally, I would like to say the design of Android actually took a lot of inspiration from Palm. Many of the core engineers on Android came from PalmSource (most having arrived there from Be), and saw Android as an opportunity to do what PalmSource was trying to accomplish in an environment that was more likely to succeed. For example, Android’s Intent system is actually a greatly evolved version of PalmOS’s sublaunching, based on a lot of ideas in the Rome architecture. I find it amusing reading that linked article about examples we had shown of what Rome was doing, which have a direct lineage to things like Android’s sharing and other Intent-based features. Or another example is Android’s initial design to support different density displays (created long before Apple’s whole Retina thing), which came directly out of our experience with how PalmOS was dealing with different densities and how we could make that so much better if we baked that concept into the platform from the start. You can actually trace an evolution from Palm’s original attention manager, to the status bar slips in Cobalt, through the notification facility in Rome, to the notification system that has been part of Android since it first shipped. And Android’s application model based on a single foreground application that must be able to save and restore its state as you leave it and return has a strong lineage from work at PalmSource on how to add multitasking to Palm’s original single tasking model.
thanks for more details.
what does a “distributed view hierarchy” means? does it means that some views can run in different processes?
Can critical components (e.g. flash) run in a different process and render into a local view? Or was it that way that view and component are one unit running in a different process? thanks for the nice insight btw!
Yep, it allowed you to have process boundaries at any points in the hierarchy, and one of the significant motivations was indeed for dealing with things like flash content. Basically the entire UI was one single distributed view hierarchy, rooted at the display, with the window manager sitting at the top owning the display and the top-level children there. If you know about OpenBinder, a short description is that in the design every View was an IBinder object, so it had binder interfaces for accessing the view allowing these to go across processes. In particular there were three interfaces:
– IView: the main interface for a child in the view hierarchy.
– IViewParent: the interface for a view that will be the parent of other views.
– IViewManager: the interface for managing children of a view.
These interfaces also allowed for strong security between the different aspects of a view. For example, a child view would only get an IViewParent for its parent, giving it only a very limited set of APIs on it, only those needed to interact with it as a child.
You can look at the documentation on the binder storage model at http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.h… to get a real-life flavor for a similar way to deal with objects that have multiple distinct interfaces with security constraints between them. In fact… the view hierarchy was *also* part of the storage namespace, so if you had the capability to get to it you could traverse down through it and examine it, such as from the shell!
Many of the fundamentals of this design were carried over to Android. Android dropped the distributed nature of the view hierarchy (switching to Dalvik as our core programming abstraction with Binder relegated to only on dealing with IPC lead to some different design trade-offs), but still we have our version of IViewParent in http://developer.android.com/reference/android/view/ViewParent.html and the basic model for how operations flow down and up the hierarchy came from solving how to implement that behavior in the Cobalt distributed view hierarchy.
Find that pretty interesting stuff!
I don’t quite understand why switching to Dalvik made you drop the distributed nature of the view hierarchy though.
Looked into OpenBinder before. As one part of my PhD project I look into how the behaviour of an application can be changed at runtime (basically by rewiring components). For the prototype I used many ideas from OpenBinder and especially pidgen to generate the base object binder code. However, I mixed in a bit of qt’s thread safe signal/ slot semantic to make it easier to make stuff thread safe (http://qt-project.org/doc/qt-4.8/threads-qobject.html).
Is there actually something you miss from the Cobalt platform (binder related) that is not in Android?
Part of this is that a lot of those features in OpenBinder were based on creating a dynamic nature as part of the core binder design. When we went back and started on a new platform based on Dalvik, we already had a language with its own dynamic nature. Just taking what had been done for OpenBinder would leave us with these two conflicting dynamic environments. We even ended up dropping the basic ability to have multiple binder interfaces on an object because that didn’t map well to the Java language. (In theory you can still implement such a thing on Android based on the native binder framework, but not in Dalvik where most of the interesting stuff happens.)
There was also just a practical issue that we couldn’t take the OpenBinder code as-is for licensing reasons, so we needed to re-write it for what we shipped in Android. The development schedule for Android was pretty tight, so we needed to be really efficient in building the system, and reproducing all of OpenBinder and the sophisticated frameworks on top of it that weren’t open-sourced would have been a lot of work that was hard to justify vs. what we would get by going back and doing something slightly different that leveraged a lot more of Dalvik.
And ultimately it was a different team that built Android — yes some key people were from PalmSource with the experience with Cobalt, but there was a lot of influence as well from people coming from Danger, Microsoft, and other places. Ultimately ideas from all those places were mixed together by picking and choosing those that seemed best for the project.
I also think that from a development perspective building most of our system services on top of Dalvik has been a good thing for Android. The Dalvik environment is just a much more efficient development environment than C++; with all of our very core system services like the window manager and package manager written in it, we can move much more quickly in evolving our platform and more easily triage and fix bugs. (Given a crash report from someone’s device, you are very often going to be able to identify and fix the problem when it happens in Dalvik far more quickly issues than in native code.)
Oh if you have a decent understanding of the apk and process design of Android, it may be entertaining to read the process model documentation of OpenBinder: http://www.angryredplanet.com/~hackbod/openbinder/docs/html/BinderP…
A *lot* of the ideas there appear in Android, transmuted for the new environment they find themselves in. Keep in mind that this process documentation is describing a core foundation of the code that was running PalmOS Cobalt and then Rome. We hadn’t quite gotten the full security and process model in place that we wanted for third party applications, but you can see the comments at the bottom there leading to very similar concepts in Android — signing to determine where things can run, permissions, etc.
It seems there is little or no reason provided to explain why Palm failed on the market.
And no, i’m not talking about the “WebOS” part, which is there, but which is “no longer Palm as we know it” in my opinion, but “another kind of Palm”, Palm 2.0, or Palm ReBorn if you wish.
But the previous lines of PDA, the one which was dominant with 90%+ market share and insane margin, how come it finally died ? I would love to hear some explanations on this one.
Wow, this article took me a little week to read entirely, bit by bit, but it was certainly worth it. You took your research work quite far and did a good job at making it interesting !
I’d gladly buy it just for the sake of saying “I am ready to pay for such articles”. But for this, I’d need some other payment methods, since I can’t bring myself to trust banking cards. Could you please try a billing service which accepts Paypal payments on a future article?
Edited 2013-03-14 15:21 UTC
I still have my Palm 5000, and my Kyocera 7135 flip-phone. I also owned the Treo 650 and the 700p.
And last but not least, the Treo 755p, which was retired just 3 weeks ago for a generic LG L9 Android phone.
I avoided the Centro because of its tiny screen. Today there is no phone that matches the 1/4″ font size used in the address book of my Treos. Not one. They all use tiny fonts on megapixel screens that my tired eyes can’t read without glasses.
Most of all, I miss the terrific Treo keyboard that no other phone could rival (and I tried them all). When I got my 650 I gave up Graffiti instantly, and I never looked back.
Until today, when I installed Graffiti for Android, just to get away from that annoying touch keyboard. It all came back in a rush. Entering text without looking at the screen! Without a stylus! Yippee! I’m FREE!
Your article was so perfectly timed for me, letting me know for once and for all that it was time to let PalmOS go.
But not Graffiti.
Thanks.
Edited 2013-03-16 03:20 UTC