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.
I’ve been using a Treo 600 for about 2 months now, and it seems PalmSource is addressing essentially all of the problems I’ve been having with OS 5. Real multi-tasking and multimedia would be a huge improvement, and the BeOS roots are always fun.
I just hope they can get some hardware out soon.
Hey, they are running “State of the Art” demo by Spaceballs (The Party 91, first place, IIRC) as promo! Cool. 😉
“first version of Palm OS to support native ARM applications”
Does that mean that earlier Palms with ARMs emulated 68k applications? (I always wondered how they did the transition from 68k to ARM)
Hrm. Interesting interview. I’m glad that under-the-hood architectural improvements *are* coming. On the other hand, it seems that major UI changes are getting pushed farther and farther back. While I like PalmOS’ simplicity and elegance, it is starting to look dated from a graphical / GUI perspective IMHO.
Not that I want what PocketPC currently offers. I had one for a year or so and sold it because the OS was crash-prone and needlesly complicated. An attempt to shoehorn the windows metaphor onto a much smaller device with a completely different form factor IMHO.
I can imagine it does support filesystems now, isn’t? or does it still suffer the limitations of the previous palmOS versions regarding to files?
I mean, does Cobalt handle the internal device memory as a disk with a proper filesystem? does it allow the user to create subdirectories? Does allow applications to open files in memory cards, behaving like any other civilized operating system or it is still using that ugly VFS patch?
Info! we need info!
Yes, I did noticy it too! The good old Amiga demo!
I feel nostalgic…
where is the shell ?
(yes even BeOS had it :p)
Very good article. Congrats Eugenia! Lots of good insight on
Cobalt …
I just bought a Tungsten T3 last week, and as an ex-user of
Newton I have to said that I’m quiet impress by the modern
PalmOS … I’m looking forward Cobalt.
Cheers,
Jean-Louis
“where is the shell ?”
1. Download the simulator.
2. Run it.
3. While holding down CONTROL, press RMB to bring up settings menu with “advanced options”.
4. Select 640×480 resolution.
5. Watch system reboot with terminal view on right half of display.
6. Type “help” in the shell to get some basic documentation.
Note that this is about half done. It is our own implementation of the POSIX shells standard, with a number of extensions for interacting with our system component model. One big thing missing right now is a better defintion of the directory structure interfaces, so we can mount file systems and other traditional persistent data in the namespace. But you can expect to see these areas addressed in the future…
(There is also a terminal application that give you the same thing in a normal PalmOS app, but I don’t know if that got included with the final release of Cobalt.)
BeOS lives once more!!.
Hey Palm, since Billy The Borg has invaded your market, how about Palm fighting back and releasing BeOS 6?
I don’t care for Zeta, but I wish them the best. But I want the real BeOS 6.
If you read between the lines in the article, it certainly appears that they are positioning themsleves to be able to do just that – if they want to…
On Page 3 : “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.”
This could lead to some very interesting devices appearing in the next few years.
> “first version of Palm OS to support native ARM
> applications”
> Does that mean that earlier Palms with ARMs emulated 68k
> applications? (I always wondered how they did the transition > from 68k to ARM)
Yes, Palm OS 5.x used PACE (Palm Application Compatibility Environment, iirc) to emulate the 68k cpu. It does support “armlets”, or small bits of ARM code, but it’s not a native environment for the apps. OS6 is much better in this regard.
And on a moderately ontopic news, I just optimized the mobile version of OSNews’ frontpage to render well on NetFront’s spinoffs at PalmOS (“Web Browser” and “Blazer” browsers). I just tried them on my PalmOS 5.3 simulator. Screenshots of “Web Browser”:
http://www.osnews.com/img/6146/web1.png
http://www.osnews.com/img/6146/web2.png
AvantGO now renders it even better too.
http://www.osnews.com/img/6146/avantgo1.gif
http://www.osnews.com/img/6146/avantgo2.gif
Looks like they’re not running the demo itself, but rather a movie of the demo.
Definitely a testament to the creativity of demo writers in the late 80’s and early 90’s.
One of the most exciting hardware developments I’ve seen in a long time … http://www.synosphere.com … looks like a perfect platform almost all my computing.
Looks like they’re not running the demo itself, but rather a movie of the demo.
It’d be darned impressive if it was the real demo. I can’t get it to run smoothly in WinUAE on my 2.6 GHz Celeron. That’s mighty impressive for a 15 year old machine. It was also pretty groundbreaking when it came out. 🙂
I love Palm.
When everybody pulls out their laptop. And I pull out my palm with its foldable keyboard, you got to see the look on peoples’ faces.
Palm is one product I really get excited about. And reading this interview further makes me glad.
What did Georg do at Be? I know the name but memory seems
a bit rusty…
I’m in the market for a PDA, so I’m curious, if a buy a Palm device now, will Palm offer the new OS as an upgrade or I’ll have to buy another Palm?
I believe you will be able to update your Palm to PalmOS 6.0.
At least I do hope so ….
jl
Can someone enlighten me about Palm and File Systems? Why would we want traditional file systems features or architectures in a Palm? Like Mac OS being traded for Unix, I wonder if this is a step forward or a step sideways. One of the things that makes a Palm OS device so easy for people to use is that there is no hierarchy of storage. Each app “stores” its own documents. The user needs never consider applications and file types. I like it this way. In fact, if you’ve seen the latest article from Michael Phipps of OpenBeOS, you’ll see that the Glass Elevator folks are discussing the use of BFS and the UI of the OS in a more Palm-like way (which, I at first was weary of but after talking with Michael, I think the ideas are right on target).
Hey, while on this topic… what file system would be used if Palm OS started to have that? Would it be exposed to users or only developers and hackers?
And, one last thing… A COMMAND LINE in a Palm OS?? EW!
😉 😉
Hey, way to go George! I had no idea you were at PalmSource.
When last I talked with him (many moons ago) George was responsible for the OpenGL port on BeOS. Back in the day, as it were.
-Seth
Palm’s don’t have Filesystems. They have databases to store all types of data.
You have your PRC which is the main program and PDB’s (Palm Databases) to store your extra information and user data.
The new PalmOS Cobalt also supports Schema databases.
When last I talked with him (many moons ago) George was responsible for the OpenGL port on BeOS. Back in the day, as it were.
O yeah I do remember now, I did see some amazing rotating teapots when the hardware acceleration worked, only to be broken by the next bone update.
Still running palm 4.1 on my clie it hardly understands the hires screen…
to eugenia: uses for your palm: palmreader or mobipocket and some e-books… it’s easier to read the palm in the bathtub then hardcover books.
George was not directly working on OpenGL at Be. That was primarly R. Jason Sams’ job (who now works at nVidia).
George worked in the new/updated app_server (the one appeared on R3 and later), the BeIA Wagner architecture etc.
Is it that long ago? geez, I’m getting old. I was quite surprised to see it there though. After a quick look I though “oh, that looks just like” and then I got to the second screenshot “wait a minute it is that demo!”
I am still amazed by old (and new) amiga and c64 demos. I haven’t seen todays computers used in those ways. We were so creative back then.
>> Palm’s don’t have Filesystems. They have databases to
>> store all types of data.
Yes, and that’s a pain in the ass in case you want to store files on the internal memory, or want a program running from the internal memory to access a file on another device, let’s say the memory expansion slot.
To achieve all of these task you need to use special software, or propietary solutions like the one palm finaly adopted from sony (VFS) to be able to do “something” with the memory card.
>> You have your PRC which is the main program and PDB’s
>> (Palm Databases) to store your extra information and user
>> data.
Yes and while it is very good for basic apps it is rubbis when it comes to user flexibility, if you want to store let’s say a GIF or JPG file on the internal memory, the file has to be converted somewhere else than the PDA into a palm database holding the file or a group of files…
On those limited palm machines of the past those limits are ok, there’s not much to do with “alien” files anyway (any kind of filewhich is not .pdb or .prc” is alien)
But when we are talking about modern palm os machines, the lack of proper filesystem makes palms look really lame.
Beware! I’m a palm user, and an old one, I do not rant from ignorance. I’m affraid that I won’t buy any more “advanced” palm device limited by the lack of filesystem.
The actual “filesystem” on palmos 4.x or 5.x maybe apropiate for a smartphone, but not for something which aims to run in as many mobile devices as posible.
> I just bought a Tungsten T3 last week, and as an ex-user of
> Newton I have to said that I’m quiet impress by the modern
> PalmOS … I’m looking forward Cobalt.
Based on an earlier article, I understand this OS is not going to replace OS5, but become the high-end os. Naturally, I wouldnt expect to see upgrades for the zire21 for example.
But what about the current “high end” palms, like the T3. Are there any plans to have an upgrade option for this device? It already has the dynamic input area, as well as using a 400MHz XScale processor. Is there anything that would technically prevent this?
I also realize any answers would be speculative, expecially since OS6 is likely too far from release, but I figured it would be an interesting discussion.
O yeah I do remember now, I did see some amazing rotating teapots when the hardware acceleration worked, only to be broken by the next bone update.
Actually in DANO it still works, it was the “player” that broke.
Get an older player and run it on DANO, works fine.
I am still amazed by old (and new) amiga and c64 demos. I haven’t seen todays computers used in those ways. We were so creative back then.
Some are still doing old style demos…
Some are still doing old style demos…
I know, that why I said “(and new)”. The C64 demo scene is still alive, and makes some cool stuff with that little box still. But I have to say that something is missing these days. I miss the demo-parties back in the days, they were a lot nicer than the ones I’ve been to recently.
Jace wrote:
“Can someone enlighten me about Palm and File Systems? Why would we want traditional file systems features or architectures in a Palm?”
Because files are a sensible way to deal with data. My BIGGEST complaint about PalmOS is that it has no idea what a .Jpg is. If I move a picture onto my device, I want every single program that can comprehend what a picture is to be able to use that picture. As it stands, I have paint programs that can’t see my photos. Text files that can’t be seen by other all my text editors, and no way to get any of this stuff to any desktop computer even though I can copy the information to a SD-Card, becuase my Desktop can only see the things as Palm Databases.
“One of the things that makes a Palm OS device so easy for people to use is that there is no hierarchy of storage. Each app “stores” its own documents.”
Which makes the Palm a “Pocket of Bable”.
“The user needs never consider applications and file types.”
Sure they do. It’s the internat age. Even the simplest web page is an .HTM file. I should be able to Save that to my device and load into Quickword so I can make changes, then save it back and upload it back to my web space. My Tungsten C has built in WiFi. I should be able to grab pictures off the net and edit them, post them back via FTP too.
“I like it this way.”
That’s fine for you. So let Palm OS scan a directory and make you a database of the files types your apps can see.
I so NO benefit to having data in a propriotery format that only one application can see when there are simple standards that would let that data work in any application.
“Hey, while on this topic… what file system would be used if Palm OS started to have that? Would it be exposed to users or only developers and hackers?”
A VFS card is already a Fat formated device, and practically every OS on Earth understand it. I guess the best solution would be to let people choose how they see their information.
As for me, If OS6 doesn’t make some sence out file navigation, I’m looking into porting the Xscale version of Linux to this device.
Ratteler Wrote:
“Because files are a sensible way to deal with data. My BIGGEST complaint about PalmOS is that it has no idea what a .Jpg is. If I move a picture onto my device, I want every single program that can comprehend what a picture is to be able to use that picture. As it stands, I have paint programs that can’t see my photos. Text files that can’t be seen by other all my text editors, and no way to get any of this stuff to any desktop computer even though I can copy the information to a SD-Card, becuase my Desktop can only see the things as Palm Databases.”
In some cases storing data in files does make sense but not always, and therefore people use databases. Photos, as an example, are probably best managed individually as files and on newer Palms you can do this. My T3 will take JPG files just fine and display them in the Photos application. I can easily copy JPGs to an SD card on my PC and display them on my Palm.
Other file types like MP3 and Doc files can be easily moved to the Palm on an SD card. Likewise you can send files like Word documents or Excel spreadsheets from the Palm to a Desktop PC.
On the other hand I don’t think I would want to manage Calendar Appointments as individual files. Can you imagine trying to search hundreds of individual files to find a specific appointment?
Ratteler Also Wrote:
“I so NO benefit to having data in a propriotery format that only one application can see when there are simple standards that would let that data work in any application.”
To my knowledge there are no standards for Calendar or Contact data and most of these types of applications cannot use each others data without some sort of conversion. The benefits to using databases to store this type of information is that you can easily cross-reference multiple pieces of data and you can quickly search and sort that data into something meaningful.
File systems have their uses but, IMHO, they are not the best solution for all data types.
Cheers
TC – aka Cowboy Shootist
I read elsewhere that the UI was not going to change until version 2. The current screenshots show some change, but I’m still not sold on OS 6. It looks to be more of the same but with an upgrade to hardware specs and a new OS with future capabilities.
It’s a good start for Palm but consumers can get more currently from Sony. As we know, Sony has a stake in PalmSource and no wonder the Clie’s look so different than other palm os devices. How does this help other manufacturers compete with Sony?
PalmSource has no intention of helping other manufacturers compete with Sony (nor helping Sony compete with anyone else). We provide the platform, and allow each licensee to customize it and differentiate it as they see fit. (And that goes for palmOne, as well.)
I agree it is unfortunate that the improvements to the UI in this release are very small in comparison to how much has changed underneath. However, there is a tremendous amount of exciting technology in the system and available to developers; I think this will become apparent as we see the kinds of applications our developers are able to do on Cobalt that you just won’t get on Garnet. A small little example: the system now reports pen pressure information; in conjunction with the new drawing model, it should be easy for a developers to create vastly better sketch and drawing apps.
There are also a lot of really significant user-level improvements in the base operating system, especially in areas such as communications, and many smaller but very welcome improvements all over such as the addition of many more fields to the Address Book and the ability for users (and third party developers) to extend it with their own fields using schema databases.
I also think the new status bar and slip mechanism is very slick… and keep in mind that this is now a multithreaded protected memory system, so you can hit stuff on the status bar and bring up slips regardless of what the current app is doing, without disrupting it. Not to mention little things such as if the current application crashes or gets stuck, the system will gracefully just kill it and let you continue. Though it may look familiar at first glance, after using Cobalt a bit I think it will become very apparent that you are holding in your hand a much more sophisticated OS.
I still haven’t seen any clear indication that OS 6 will run on my T3? Does *anybody* know?
Thanks Diane. Did I hear POSIX ? That’s starting to look interesting :p
Now that the Palm finally can multitask as well as my ti92 ( http://clapcrest.free.fr/revol/ti68k/prosit/shots.html
… Btw, the Ti92 did have a real in-ram fs (8 char names, 1 level folders IIRC).
Still the procedure to get to the shell is a bit odd.
Yeah, I recall I once saw an app for PalmOS that looked like a shell (actually more like a C:>, shrug).
Still I feel a bit odd about PalmOS. Starting to look nice, and I’m happy it got inspired from BeOS, but at the same time I’m very ashamed BeOS itself lies in a cupboard getting dust.
But I still like the Zaurus much… Now, make me change my prefs before I go get a PDA !
btw, I didn’t follow the Palm news much, is POSE still opensource ? I used to use it when it was still called Copilot (with µCLinux
ie. can I port that to BeOS along with the dev chain ?
Just in case I want to buy a PDA, certainly don’t want to have to boot windoze (Linux might be ok, but why reboot if you can avoid that).
The tool chain has been ported to BeOS previously. I think it was the old 040 or 050 pre Palm gcc toolchain though. It would have been 68k anyway.
For the record, POSE is 68k only iirc. I would still love to see a port. Please feel free to use SDL and then we can all benefit from it 😉 I’d like to port it to PowerPC personally.
Simulator (ARM PalmOS 5 Simulator) was closed source last time I looked.
As no one mentions anything conclusive about the filesystem, I asume there is not proper filesystem support yet.
The lack of proper filesystem support along with the odd memory handling in pre Cobalt machines were the biggest quirks in the platform.
If the Pocket PC had a decent UI and fair resource usage, the Palm platform would have died long ago because of its own demise.
Which is something I will really hate if it finaly happens.
So please, add a decent filesystem!
> So please, add a decent filesystem!
Did you read the comments from Dianne (Hackborne) or Palm (and former Be employee)? Did you read the interview with George?
There will be a VFS layer. This is how most OS of a UNIX/POSIX nature work. The FS is abstracted, and the driver for the FS implements specific calls and ioctl calls. Therefore, *yes*, reading between the lines, external FS will be supported in the future.
As for why you need a FS in the memory PalmOS uses to store data, why? Please tell us more. I’ve been a Palm user since the late 90’s (PalmPilot Pro/PalmOS2) and the lack of a FS has never stopped the device from functioning… A database is like a folder, it can contain one of more files (a lot of apps do it this way under PalmOS), so why the big problem? There’s a perfectly good APi to gather all files for a specific type/creator id, and this is, after all, more or less what you need to get at a specific file list. All PalmOS does, if you want a comparison to other FS, is flatten the entire FS into a single Directory that lets you query for specific files of a type/creator that you want to access. This then get’s you a list to parse. I’m still not clear why this is a problem? It’s just like a query under BeOS (though has been in PalmOS since 1.0 obviously.)
From what I gathered at palmsource, you wont need special conduits for files like mp3, doc, xls. You can now install them directly to a palm and the default app on your palm will store them to the internal format. The other important thing to remember with os6 is the 64k record size limit in pdb files is gone so files can be stored without needing to be broken up.
Personally, im glad palm doesnt use the traditional FAT type file system. I like the way an app and all of its related files are linked by a creator code. Why do I care what the physical filename is on the palm as long as my app can locate it easily? Even m$ has ceded that it sucks and is moving to winFS.
Oh i forgot one other feature. You can send a document to “hotsync” on your palm and the next time you sync, it will be somewhere in your documents folder on your desktop. Hotsync is now an exchange manager client.
Awesome that a PalmSource (and apparantly former BeOS) employee posted here!
I’ve used Palm since the Palm III was released, and the reason for a filesystem is incredibly simple:
I have a jpeg on my computer. I wish to view that jpeg on my Palm. So I get a picture viewer and use it’s converter app to convert it and download it to the Palm to view.
Great.
Now I just figured out that I want to insert that jpeg into a presentation I have on my Palm. So, now I then need to get back to my computer and re-convert it for the new program, and download it again… and I now have doubles of that same picture.
Bother.
Then I see that it doesn’t fit the presentation. I need to edit it. So again, I go back to my computer, get a picture editor and convert the picture for the third time… but this time, I also have to re-upload the picture to the PC, and re-convert it for the presentation software…
AAARGH!
Can’t you see, yet?
Applications shouldn’t rule. Filetypes should!
BeOS even took this further by having translators, which any application could use. Think of it as a converter, only that it resides on the Palm device itself, and it application independant.
Damnit, BeOS and bfs did everything right. That PalmSource doesn’t use it sounds just stupid to me. A Palm today is more powerful than the computers BeOS originally ran on.
“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… anti-aliased rasterization… TrueType font rendering is standard…”
Ahh… reading this is almost orgasmic.
Then, reading about media kit similarities, mapping movies to a cube, font demos…
Mmmmmmmm, oooooooooh!
Seeing State of the Art didn’t make things worse either. But I wonder if it had sound… and if it played the original song… “Condom Corruption”
The icons look a bit old. What happened to the icons which are on the Palm Os 5 devices (not the emulator, as far as I know) which are 3d style isometric like the Beos icons?
They are much much better….
Thay can be seen here:
http://www.zdnet.co.uk/i/z/rv/2003/05/palm-tungstenc-i1.jpg
PS: does anyone know which campany designed these icons (as in the above picture) or were they designed in-house (if so by who?)
Thanks.
Yes, they look nice, but they also seem smaller due to their isometric design. I find them harder to focus on than the icons in the article. Of course the different image size tricks a bit, but I get more out of the icons in the article.
I would think that information on a small display should be as clear and simple as possible.
>> Did you read the comments from Dianne (Hackborne) or Palm
>> (and former Be employee)? Did you read the interview with
>> George?
Yes, and they talk about screens, multimedia and… POSIX compliance. They do not talk about what’s going on with the internal memory or the way the apps see files on it.
>> There will be a VFS layer. This is how most OS of a
>> UNIX/POSIX nature work. The FS is abstracted, and the
>> driver for the FS implements specific calls and ioctl
>> calls. Therefore, *yes*, reading between the lines,
>> external FS will be supported in the future.
VFS have been around since Sony introduced the PEG-S300 to provide support for its memory sticks.
The problem is that it is an add-on, which behaves like an add-on even in version 5.x! That is; applications do not use it unless you specifically do so.
For example you need to use third party software to do a backup to the memory stick, you can not open the notepad and tell it to save the .pdc file which contain the notes on the memory stick, same with the contact database or anything else.
Basically PalmOS behaves like an electronic agenda regarding the FS, which is annoying considering the aims of Cobalt and that we are in the year 2004
>> As for why you need a FS in the memory PalmOS uses to
>> store data, why? Please tell us more. I’ve been a Palm
>> user since the late 90’s (PalmPilot Pro/PalmOS2) and the
>> lack of a FS has never stopped the device from
>> functioning… A database is like a folder, it can
>> contain one of more files (a lot of apps do it this way
>> under PalmOS), so why the big problem?
The problem is fairly simple, for example you cannot just copy a jpg file to the internal memory, you need always third party software to create a .pdb, which will contain it.
The real issue here is the need for a palm-desktop type of application, you always have dependency of such software which by definition runs only on full size computers, (and remember that MACOS now is excluded). And this is only if you are using non third-party software like documents to go or similar.
That problem render the PalmOS a platform that cannot run standalone, it always have dependence of another OS.
If there was a regular filesystem (or at least if the applications could use FS functionality) on the internal memory (and external devices) you could edit text files, rtf files, or any sort of file like any other computer platform does, making the PalmOS a true mini portable computer.
My Palm device never failed to me either, I’m quite happy with it, its battery last weeks, and it does what it is supposed to do, but I need to have the F***** palm desktop software everywhere to use the device, along with all third party transform-to-pdb-conduit software to transform regular files into palm .pdb. A good example is the PDF reader? you can?t copy a PDF to a palm device because there are no means to convert it to a .pdb, so you depend on having a memory card device to copy the file to the memory stick, and read it from there. Depending on which version of the operating system, vendor and so on you have to place the files on a particular directory or another on the memory stick in order for the reader software to recognize it (disadvantages of add-ons, no one agrees on a standard way to use it because the underlying os doesn?t provide a standard way)?
The solution is as always to find a third party app to transform the pdf to a palm doc, to do that you need to have the converting tool and acrobat? and all just to have a stupid pdf on your device!
One of the Palm OS Cobalt features not mentioned is HotSync Exchange. This lets you sync any file to the device. On the device, it is received through Exchange Manager by the application that uses it, just as if it were beamed to the device. This means apps that handle native types can accept those files without needing a desktop converter.
oh yes! why of course I remember George Hoffman and Dianne Hackborn from be! oh my I have waited for some kind of reincarnation of the spirit of beOS for some time (openBeoS…even beIA would be OK if it was successful). But now we see the same spirit-just in a very small package. And this time nobody has to worry about “dual-booting with Windows” or lack of hardware/software support. OK so it doesn’t have yellow tabs, a shell, workspaces and it won’t run Gobe productive…but it now has the same principles that drew people to beOS in the first place. And you can take it anywhere you go.
Thanks for the interesting responses to my questions. It sounds like what Palm OS needs is BFS. I don’t see why so many devices use such a primitive FS like FAT. I know… it’s easy to impliment and support. But it’s so primitive.
I wanted to add one more thing… Why are we changing all of the smartly designed specialized systems and devices to support old and clunky “standard” conventions such as file extention filetyping? Wouldn’t it make more sense to start updating the old and entrenched stuff to use more intelligent systems such as MacOS/BeOS-style file typing (metadata) and free people from the need to think about file extensions for real? We certainly have enough modern file systems to move everything over to them all and abandon all the old archaic ways.
I expect much flaming/argument from the developers and hackers and technogeeks, but I had to say it. There have been smarter systems for ages yet here we are dumbing everything else down to the “Unix Internet” standard. Internet servers support MIME typing, so why not use it? Why not make all servers operate from a file system like BFS, Reiser, etc? Only Windows will be left behind and it seems that even Windows is painfully moving up towards metadata in the FS.
Oh, we will update. When Microsoft releases WinFS to the world, and proclaim that they invented the concept!
no not BFS, CFS from BeIA!!! I compressed 41MB of data to 17MB on a cfs partiton recently (okay apps were crushed too…)
Spaceball… Amiga rulez !
AMIGA. The computer that never died just changed names.
What I (as a developer) don’t like about having both VFS and an internal database representation, is that the internal databases can not be referenced via the VFS calls.
I’d love for there to be specially understood place holders like /dev/ram/ or /dev/MyID/databasename.pdb mapping to internal databases, then I could just use a single API calls for finding, creating, opening, reading, writing, closing, databases that could be located either in ram, or on a card.
It’s not a bad idea– the TapWave OS 5 device already has an internal heap-based VFS volume that lets apps store data in the storage heap as if it were on an external card. This works well for game apps, making it simple to install them to a card or leave them in main memory.
I think the potential of VFS has really gone unused. Most devices with it only have one volume, but using it to expose other services, including in-RAM databases, seems pretty good.
The big issue with exposing the internal DBs through VFS is detecting changes. Somehow, VFS would have to be able to easily detect when a database has changed in RAM to be able to update its internal pointers, something that’s difficult to do in the current OS architecture.