Current Cover

Message Board

An Introduction to the GEOS Operating System

From Pen Computing #8 February 1996

GEOS is that legendary, mythical beast - an object-oriented operating system. It is designed to run on what Geoworks calls Consumer Computing Devices (CCDs). These sound suspiciously like PDAs at first reading, but Geoworks has a broader definition than most other companies. CCDs include not only mobile computing devices, but smart telephones, office products like stand-alone word processors, and interactive television set cable boxes. There are three factors that differentiate CCDs from other computing devices:

• they are built using single-chip computers,
• they have broad consumer appeal,
• they need a compact, high-performance operating system that can be adapted to a variety of configurations.

That last item eliminates many GEOS competitors.
The first version of the current GEOS product was the basis for Geoworks Ensemble, an integrated end-user application for IBM -compatible PCs that was released in 1990. Since 1992, version 2.0 of GEOS (and in some cases the base application set as well) has been incorporated into at least five different consumer devices - the Casio/Tandy Zoomer PDA, the Sharp PT-9000 PDA, the Canon StarWriter Pro 5000 personal publishing system, IBM's Eduquest educational computer platform, and now the Hewlett Packard OmniGo 100.

GEOS is written predominantly in object-oriented assembly language for X86 CPUs. That helps satisfy Geoworks' criteria for a compact, high-performance system. The basic OS, including the kernel, user interface, drivers and standard class libraries, can fit in less than 2 MB. The Zoomer, which includes 18 applications, the GEOS system software and a handwriting recognition engine fits into 4 MB ROM and 1 MB RAM, with 350K set aside for user data. On the OmniGo 100, GEOS and all the built-in applications fit into 3 MB ROM.

The GEOS System Architecture
GEOS was designed from scratch as an object-oriented operating system. All OS entities are created as unique objects that interact by sending messages back and forth. Instance data is usually encapsulated within each object, although two objects may also create a shared memory block.

GEOS is based on a single-inheritance class hierarchy. This helps keep the overall runtime footprint small. Messages that cannot be handled at the current focus of the class hierarchy are passed up the superclass tree for handling. The system also has a special type of class called a variant. Variants, which are an essential part of the GEOS user interface architecture, do not know their superclass until runtime, when the class is displayed on the screen. Their superclass may also change during program execution, providing some of the same functionality as multiple inheritance. Note that classes, not objects, can be variant.

GEOS is a pure multitasking, multithreaded operating system. Multitasking means that multiple applications can run simultaneously. For instance, you can fax and print at the same time. Multithreading means that each application can have multiple points of execution, called threads, that share the processor. For instance, a spreadsheet can have a background calculation thread and a foreground user-interface thread that intercepts taps and other forms of input. Each thread has a base priority, set by the application, and a current priority, set by the kernel.

There are two default thread models:

• A single-threaded model for programs with fast, simple operations.
• Dual-threaded applications have the user-interface objects running in a higher-priority thread. This mode is useful for programs that have lengthy operations - the interface remain active while the background tasks are computing.

Additionally, an application developer can add more threads to a program. All extra threads are categorized as either event-driven, responding to messages places in that thread's event queue, or procedural.

Memory Management
GEOS basic memory management scheme is similar to the handle-based mechanism used in the Macintosh, but there are a few additional twists (which I won't try to describe) to accommodate the X86 memory management hardware. Memory is allocated from a global heap space in blocks which can be moved as needed. Block sizes range from 16 to 64K bytes. You can also declare fixed blocks and reference them using pointers.

GEOS provides Virtual Memory (VM) files, allowing you to treat large disk-based data stores as if they are in memory. The system automatically manages loading and unloading VM segments, writing changed segments to disk and the appropriate locking and unlocking. Like real memory, VM files can be allocated in blocks of 16 to 64K bytes.

There is a third type of memory store called local memory. Conceptually, local memory is like a mini-heap within a memory block. Local memory blocks, also called chunks, are allocated and managed just like memory in the primary heap; the difference is that using local memory is generally more efficient than using heap space. It's best suited for managing large numbers of small objects. Local memory is usually used for storing and managing the instance data for the objects in a program.

Finally, there is also a Database Item Manager for managing an arbitrary numbers of small objects. The system works with the other memory managers to make all access and storage transparent by providing a layer of abstraction above the memory managers. It relies heavily on the local memory manager and is responsible for managing the small objects in a VM file.

The Graphics System
The GEOS graphics system is based on a single device-independent, imaging model that assumes a base resolution of 72 dpi. Like Postscript, all graphics actions are automatically translated to the highest possible resolution of the target device. There is a single 16-bit coordinate space (and an optional 32-bit coordinate space called the large document model). The graphics model supports both 256-color palettes and 24-bit RGB values.

The graphics system includes a full set of primitive objects like lines, arcs, Bezier curves, splines, outline text, polygons, and bitmaps. Each graphics object has the primitives required to draw, reposition and rotate itself. Underlying this architecture is the notion of a path, a continuous trail that defines the outline of an object. Path operations like filling, clipping and scaling are available.

One interesting concept in the GEOS graphics system is the graphics string. It is a collection of graphics commands that can be stored and executed later. They can be defined as data resources in source code and include comments and parameters. The GEOS clipboard supports the graphics string data format so that graphics commands can be shared between tasks.

Other System Services
GEOS has a variety of other useful system services, including:

• A system-wide input manager that tracks all mouse and keyboard events and passes them to the proper recipients;
• A system-wide clipboard with Cut, Copy, and Paste commands, plus a quick-transfer mechanism that bypasses the clipboard;
• Interapplication communication between threads and applications;
• Extensive device driver support for more than 600 printers, installable file systems, several video models, sound, fax, font rasterizers, and import and export drivers.
• A low-level text object that is appropriate for most text management operations. It includes text wrapping, text election and editing, character and paragraph-level formatting, full keyboard editing, embedded graphics, clipboard support, and more.
• A print spooler with support for multiple queues (one per printer), various paper sizes and customizable dialog boxes.
• International support, using a resource-based model, to simplify localization. There are alternate formats for numbers, currency, dates and time and other objects.
• A mathematical library with functions ranging from simple floating-point operations to matrix and linear algebra calculations;
• Various timers, including one-shots, sleep timers and continual timers.

Higher-Level Libraries
In addition to the basic system services, GEOS offers several higher-level libraries that help simplify creating applications. They include:

• A parse library, which provides a generalized parser for mathematical expressions;
• A cell library to manage data that is row-and-column based, including operations on cells, rows and columns;
• A spreadsheet library based on the cell library;
• A chart library for creating and displaying charts;
• A sound library that plays single notes or sequences;
• A configuration library that allows users to manage their preferences.
• A screen saver library.

In addition, Geoworks has added some new higher-level objects to the OmniGo version of GEOS: dynamic scrolling tables, notes that accept both text and ink input, and a database engine that uses the same database structure found in the Hewlett Packard LX-series handheld devices.

Generic User Interface Objects
The layers above the high-level libraries start to exhibit GEOS' object-oriented nature. GEOS incorporates a patented user interface (UI) model that is based on the concept of generic user interface objects. At runtime, these generic objects are superclassed by a platform-specific device-dependent interface library that adds the proper appearance and behavior to each object. This approach lets a programmer create one application that not only works on multiple platforms, but adapts its behavior on each of those platforms.

In order for this approach to work, a programmer doesn't specify the exact location or behavior of any of the UI objects. Instead, they must specify two types of object characteristics:

• attributes, which define object functionality, such as scrolling, which does not change from platform to platform (although the visual implementation might change); and
• hints about characteristics like orientation and justification, specifying your visual preferences.

Attributes are always allocated in an object's instance data. Hints, which are only used to display objects, are added dynamically at display time if they are specified.

Using this information, the UI library decides how to implement the visual functionality and actual placement of each UI object. In addition to simplifying multiplatform support, this approach also simplifies program localization-if you translate a program's strings, the UI library automatically changes their location at runtime to compensate for modified lengths.

Windows and User Input
Although you need to define your application windows, you don't really need to do much work to maintain them. The GEOS window manager and the graphics system handle size, shape, clipping, visibility, scrolling, drawing and other window behavior (you can override the standard behaviors). All you need to manage is the window content.

The GEOS input manager handles input events using three different active objects:

• the focus, the active object that should receive all keyboard input;
• the target, the currently selected object with which a user can interact; and
• the model, an invisible selection that can be maintained by the application.

These three objects can be accessed directly by other objects. In addition, any object can grab incoming events for a period of time.

User Interface Widgets
GEOS includes a broad range of generic user interface widgets for building applications. Here are some of the more important ones:

• Menus - Nested, pinup, and checkbox menu commands with shortcuts and navigation key-strokes. Menu commands can easily be set to display dialog boxes.
• Dialog boxes - modal and non-modal dialogs with standard responses (like "OK" and "Cancel") and several default dialogs like errors and warnings.
• Scrolling views with automatic clipping, updating, scrolling, scaling and sizing, plus input management and customizable background coloring.
• Lists - dynamic, scrolling, exclusive (only one choice at a time) and non-exclusive.
• Text Display and Edit, with full-featured word processing and all the features of the Text Library;
• Triggers (push buttons), controllers (standard menu commands like Cut, Copy, and Paste), tool boxes and file selectors;
• Spinners and sliders.

In addition to these basic interface widgets, GEOS makes it easy to add application support for multiple documents, standard file commands, the system clipboard, and a standardized help system through the use of controller objects provided by system objects.

Summary
GEOS' sophisticated object-oriented architecture, coupled with its rich predefined object libraries, are both good and bad news for programmers. The good news is that Geoworks has done a lot of the work required for creating useful PDA applications. The bad news is that it does take some time to learn the GEOS architecture. Even good programmers will require a few months to get productive. Now that GEOS is available on the OmniGo, which should sell quite well, more programmers should have an incentive to learn GEOS.

Geoworks is one of the few software companies focusing exclusively on consumer-style computing electronics that sell for under $500. They've clearly staked out their territory and have a good understanding of that segment of the market. They have good technology, which is in it's third generation, and a knowledgeable set of development partners, including Sharp, Hewlett Packard and Casio.

Although Geoworks doesn't garner as much press coverage as companies like Apple and General Magic, they seem to have a long-haul attitude that could ultimately make them more successful than their splashier competitors. If I were looking for a PDA technology that will be around in five years, they would be on my list of candidates.
- Steve Mann

Steve Mann is publisher and editor of PDA Developers, a bimonthly technical journal for programmers creating software for handheld devices. For a sample copy of PDA Developers, contact Creative Digital Inc. at 415.621.4252, 415.621.4922 (fax), or cdi@cdigital.com.