From Pen Computing #8 February 1996

• 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.
  

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.
  

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.
  

• 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 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.
  

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.
  

• 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.
  

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 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.