Earlier this year, the Palm Computing Division of U.S. Robotics introduced the Pilot, a small, lightweight, handheld computer. The Pilot has been selling briskly for several reasons:

The first two characteristics are due to clever hardware engineering. The latter three are possible because of some of the choices the Pilot software engineers made.

Lean and mean applications
The Palm engineering group had several basic design goals for the Pilot Operating System (OS). One was to make the OS as small and fast as possible, by eliminating all superfluous services, features, and capabilities. A second goal, to do all heavy-duty processing on the desktop, was based on the assumption that a typical Pilot user has a desktop computer. Move as much critical functionality as possible from the Pilot to the desktop.
These result of these two goals is that the Pilot operating system has modest memory requirements. Written in C++, the entire system and the built-in applications fit into less than 500K ROM. Out of that 500K of ROM space, about 300K is for the operating system, display and serial drivers, the user interface tool box, and all the system services. There are no printer drivers, no communications applications, minimal help, only a handful of user-interface resources (more about that later), and simple serial communications drivers.
Unlike the Newton OS or Magic Cap, which both try to do everything for everyone right out of the box, the Pilot OS has a modest set of features. The Personal Information Management (PIM) programs that come with the Pilot: the Date Book, Address List, the Memo Pad, and To Do List, are not best-of-breed applications. They have a minimal, but very functional set of features that are more than adequate for many people, but may leave power users dissatisfied, at least initially.
When I first got my Pilot, I lamented the lack of linking between applications; being able to, for instance, have an appointment point right to a person's name in the Address Book. Lately, I find that feature less important. The Pilot's universal Find button, and the device's speed are an adequate substitution for data linking.
All the built-in Pilot applications are Execute in Place (XIP), meaning they run directly out of ROM. The system uses only 32K of RAM (additional memory is used for data storage and third-party applications). Also, the built-in applications are small, letting Palm keep the ROM small. Just to give you an idea of a typical program size, here are the ROM sizes of the four largest built-in programs: Date Book - 54K; Memo Pad - 14K; To Do program - 26K; and Address List - 36K. Typical shareware and game programs use between six and 15K of RAM. Expect serious application programs to use as much as 30-40K of RAM.

Memory, price, and popularity
The small memory requirements of both the Pilot OS and the built-in applications means that Pilots cost less than comparable devices. Memory is the most expensive component of a handheld computer. A MessagePad 130 has 4 MB of ROM and 2 MB of RAM. Sony's PIC-2000 Magic Cap device has similar memory requirements. A Pilot 5000, on the other hand, has 512K of ROM and 512K of RAM, or almost 85% less memory.
Even with today's plunging memory prices, that still translates into a significant cost difference, and a more-than 50% retail price difference. A Pilot sells for less than half the price of a Newton. Consequently, more people buy them. Over time, that means that more developers will create products for the Pilot, more third-party companies will make add-on peripherals, and a strong infrastructure will develop around the Pilot, making life easier for consumers of Pilot products.
I don't mean to imply that people aren't buying Newtons or PIC-2000s. Simply stated; all other things being equal, a lower price usually means a longer life in the marketplace and better consumer acceptance.

Event driven, not object oriented
The Pilot's speed is determined to a certain extent by the choice of processor, the speed at which that processor runs, and other hardware factors. To speed things up even more, Palm chose to make the Pilot's OS simpler than the Newton and Magic Cap operating systems. Simpler means less overhead for any single function. When you add up thousands of functions per second, a simpler operating system translates into faster programs.
Newton and Magic Cap were created by software engineers practicing at the edge of the envelope in operating system design. That edge is called object-oriented (OO) programming. OO programming advocates claim that OO programming has quite a few benefits: Most notably, it makes it easier to build complex, yet more robust applications than with other programming techniques. From a programmer's perspective, that's usually true. Unfortunately, OO programs tend to run slower that non OO programs, because the system has to do a lot more work per function, and OO programs tend to need more memory.
Palm chose to stick with a programming methodology, called event-driven programming, that has been around a bit longer. Both Windows and the Macintosh Operating System are based on an event-driven programming model. Event-driven programming requires programmers to do more work, and makes it tougher for them to create good software, but it's generally faster and less memory intensive than OO programming. For example, the original Macintosh had only 128K of RAM, and Windows used to run on a 640K IBM PC.
Palm's choice of system design was market driven. A faster architecture that fits into less memory translates into faster devices and lower prices, both good for consumers. The Newton and Magic Cap systems development efforts were much more engineering driven. Leading-edge engineers want to work with leading edge technologies, market consequences be damned. (Actually, most engineers are quite good at rationalizing their desires to fit some fairly vague market need that probably doesn't exist). I don't mean to minimize the efforts of the Newton and Magic Cap teams. They did some remarkable work that will have an impact on handheld systems for years. They just didn't emphasize size or speed.
One definite disadvantage of the lean-and-mean OS approach is that the built-in applications object structures and executable code are not available. This makes it impossible to tweak the internal programs by overriding some of their behaviors. Unlike on the Newton, you can't patch the existing applications, only replace them. If you want a different type of Pilot address book, for example, a good programmer has to create one from scratch. The good news is that the architecture is straightforward, the libraries have a modest number of functions and procedures, and the development tools are reasonable, so it's relatively easy to build Pilot applications.

A typical Pilot application
A Pilot program is relatively straightforward. First, it consists of a set of GUI (graphical-user-interface) components, called resources. These include such things as menu bars, menus, pictures, buttons, and check boxes all the things that a user interacts with when running a Pilot program. When creating a program, the programmer has to first decide what resources comprise the user interface.
In addition to basic GUI components, the Pilot has some remarkably sophisticated types of resources, making life easier for programmers. For instance, there is a list resource, which is used in the list views for all the built-in applications. All a programmer has to do is tell the Pilot OS what items are in the list, and the Pilot takes care of scrolling up and down as you press the scroll buttons and arrows.
In an event-driven architecture, a program basically sits there doing nothing until a user initiates an event by, say, tapping on a resource like a button on the Pilot's screen or scribbling in the Graffiti input area. Once an event happens, the operating system first looks at that event and decides if it is supposed to do something about it. If not, it passes it on to the currently running program, giving it a chance to do something. For instance, if you enter a character using Graffiti, the system first determines what the character is and then passes its value on to the active program. The program may decide it's an appropriate character, and place it in the currently active input field on the screen. If the program can't do anything legitimate with the event, it ignores it.
Here's a specific example. When you tap the Pilot's menu button, the operating system gets a pen tap event from the hardware. It figures out the screen location of the pen tap and recognizes it as taking place on the menu button. It knows to search the currently running program for a menu. If it finds one, it displays it. If not, it ignores the event.
If a menu appears, you most likely tap on one of the commands in the menu. Again, the operating system receives the pen tap event and realizes that you just tapped on the menu. It makes the menu disappear, but then creates a menu event and passes it on to the program.
The program, which has been sitting there waiting for an event, receives it, and identifies it as a menu event. It has to figure out from the event's data which menu command you selected, and do whatever that command requires. In the course of executing the command, the program may initiate other events. For instance, if you tap an "About" command, the program (indirectly) generates an event to display the "About" window for the current program and waits for you to tap on the OK button. When you tap the OK button, the window is erased, and everyone goes back to waiting for you to do something.

Advanced power management
The Pilot operating system has some fairly advanced features designed specifically for low-powered, handheld devices. For instance, there are sophisticated power management features. The Pilot has three power modes: sleep, doze, and running. Whenever the Pilot appears to be turned off, it is actually sleeping, but still running. The system puts as many peripherals and other parts of the hardware to sleep as possible, to minimize power consumption, and then monitors the hardware keys and the real-time clock for any activity. If a key such as the on-off key is pressed, the CPU wakes everything back up again, ready to run. A Pilot can sit for months in sleep mode.
Sleep mode isn't remarkable. Most handheld computers have an equivalent operating mode. Doze mode, on the other hand, is quite clever. The Pilot processor actually stops running, but peripherals like the screen stay awake, so that the system can respond quickly, in a fraction of a second, to an event like a pen tap. Whenever the Pilot appears to be running, but nothing is happening, it's probably in doze mode. The Pilot actually dozes in between your pen actions, even when you are entering characters on the Graffiti pad or using the on-screen keyboard. It just looks asleep, and wakes up very fast, so fast, you don't even know it's sleeping.
This is the most efficient way to consume as little power as possible. It's the reason a Pilot can go for weeks on a single set of batteries.

Conclusion
There are many other hardware and operating system features that make the Pilot one of the most popular handheld computers to debut in a long time. While designing the Pilot operating system, Jeff Hawkins and his engineers had to make some serious decisions about the nature of the OS architecture, the amount of RAM they wanted to include in the device, the power management, and hundreds of smaller details. They made a lot of good decisions, leaving the Pilot with some significant advantages over its competitors. I hope they keep up the good work.

- Steve Mann

Steve Mann is publisher and editor of PDA Developers magazine, author of The handheld System Integrator Directory, and producer of the PDA Developers series of technical conferences.