Introduction to PenPoint

John Brugge

There's a new operating system in town, and it aims to change the way people think about computers as much as the Macintosh has.

When GO Corporation's PenPoint was announced last year, it received as much attention from the business community as it did from the software community. The mouse was being joined, if not challenged, by the pen as the device for the masses. Those who remembered the introduction of the Macintosh proclaimed a new revolution was about to begin.

Undoubtedly it has. With a handful of players, including Microsoft, jockeying for position as king of the pen-based world, pen-based computing is not being regarded as a fad, but rather as the next logical step in the evolution of computers-making them more personal, more familiar, and less visible.

For the programming community, pen-based applications present a fascinating new frontier to explore, and no environment is as interesting to explore that frontier within as PenPoint. For application designers, it provides a whole new set of ground rules to define "application." For programmers new to the object-oriented world, it provides a learning arena where you have to be object-oriented. For MacApp programmers, it provides some lessons on what the future of software development may hold.

Feet on the ground

While the entire field of pen-based computing is fascinating to many for reasons ranging from the sociological to the metaphysical, I'll try to stay closer to earth in this article. Even there, the most that I can hope to do in these few pages is introduce you to some ideas that will make you question ideas that seemed basic, and perhaps make you curious to explore more on your own.

A number of good articles in the trade publications have covered the idea of pen-based computing and the major players involved. See Byte, Feb. '91, MacUser, Feb. '92, or MacUser, Mar. '91 for starters. For those interested in learning more about the full scope of PenPoint, I recommend the book "The Power of PenPoint" by Robert Carr, the architect of PenPoint, and Dan Shafer (Addison-Wesley, ISBN 0-201-57763-1). It covers the high points of the operating system and the important classes involved in far fewer pages than the voluminous technical documentation that comes with the software developer's kit.

I will not be talking about Microsoft Windows for Pen Computing. Windows for Pens will no doubt be an economic force in the market, but Microsoft is a follower in this field, and the vision of mobile, pen-based computing will be lead by companies like GO.

With that said, I will set some minimal PenPoint background.

PenPoint Application Characteristics

While parallels can be drawn between PenPoint and other windowing interfaces, it's best to approach the concept of "application" with a clear mind. GO chose the notebook as its metaphor for the user's workspace, giving the user a much different set of expectations when interacting with the machine. Key to the metaphor of the notebook interface is the user's feeling that they are working with a collection of documents, and not with files and applications. In a notebook, to work on a document, you simply turn to its page and begin working with it. When you turn to a different page and then later turn back, the document is just as you left it. When you want to add another page, you insert one from the set of stationery (different styles of documents) that is available.

So the task of the application developer is to create a style of stationery-a business form, a piece of writing paper, a spreadsheet of cells, or perhaps a piece of drawing paper. Each piece of stationery that you insert in the notebook is a separate page-and indeed, is a separate instance of that application. As a consequence there are no "New", "Open" or "Save As" options on the menus-to look at another document (file), the user simply turns to its page in the notebook, or creates it from the set of stationery (applications) installed. Also gone are the user's ideas of explicitly "starting an application" or "quitting an application." These are unnecessary with a metaphor that says that everything is there whenever you want it-just turn the page!

While certain business forms in your notebook could be fairly complex, developers are encouraged to create small applications. PenPoint was designed to be scalable, meaning it should be as usable on small, hand-held machines as on large desktop or wallboard devices. This places a premium on memory and makes modular applications more attractive. PenPoint supports this notion implicitly by its object-oriented nature, which facilitates communication between applications. It supports it explicitly by making it a standard feature of documents that other documents may be "embedded," live, within them, creating compound documents. A graph in a text document need not be pasted or linked from another application-it can be an actual instance of a running program within the text document. Again, with the metaphor of documents in a notebook, this capability fits right in.

Objects in the Operating System

Maintaining this metaphor is partly the responsibility of the application writer, but it's mostly the responsibility of PenPoint. As the trade magazines have told you, PenPoint is a 90's kind of operating system: it has 32-bit addressing, a flat memory model, and preemptive multitasking. It supports people on the move with detachable networking (meaning you can connect and disconnect from a network whenever you want), the ability to embed applications within one another without limitation, a gestural control language (commands given with the pen, such as drawing an "X" over a word to delete it), and handwriting recognition (a fascinating technology in itself, but currently limited to printed characters, not script).

It's also object-oriented. While MacApp provides an object-oriented interface to the more traditional Mac OS, with PenPoint you can never "get underneath" the class system. The only exception is for the task and memory management services of the PenPoint kernel, offered via a procedural interface. In all other cases, if you want a service, you send a message.

Figuring out where to send the message, though, can be challenging. PenPoint has over 200 classes and thousands of messages. Taking proper advantage of its capabilities could easily overwhelm both user and developer. The knight in shining armor for both groups is the Application Framework-it provides consistency for the user and a head start for the developer.

penpoint's Application Framework

Apple was one of the first to discover the value of an object-oriented framework for easing the task of application development and ensuring consistency in applications. At the same time, they were tied to the Toolbox, a more conventional library of routines designed without objects in mind.

GO, on the other hand, had the luxury of designing their low-level routines at the same time they were defining the characteristics of PenPoint applications. By starting out this way, they have made it a requirement-not a suggestion-that all applications follow the protocols of the Application Framework. While this still leaves plenty of latitude for individual applications to flaunt their uniqueness, it ensures a level of consistency for the users as high or higher than what the Macintosh has achieved.

PenPoint's Application Framework does not have as broad a scope as MacApp. It is the collection of classes and messages that defines the protocol of a PenPoint application. Classes for elements like the user interface and file system are outside its scope and are part of PenPoint proper. MacApp, by this definition, falls somewhere between PenPoint and its Application Framework-it deals with issues besides application life cycle, but it isn't an entire operating system.

Like MacApp, the Application Framework provides relief to the developer presented with the daunting task of developing a well-behaved pen-based application; it is also a generic PenPoint application that gets you off the ground and running with a number of behaviors that come for free: on-line help, gesture recognition, standard application menus, printing support, document embedding support, and search and replace, to name a few. But just as it's not trivial to write a Macintosh application using MacApp, it's not trivial to create a PenPoint application within the Application Framework.

Important classes

Knowing where to start is as important to understanding class libraries as procedural libraries. PenPoint has a small number of classes that are essential to understand. The descriptions here should at least point you in the right direction when you start digging deeper.

Every object in the system descends from the clsObject [1] class and from a clsClass metaclass. Every class in the system is represented by a clsClass object that holds class variables and method definitions. The richness of PenPoint objects is reflected in the fact that clsObject defines over 50 messages. Fortunately for the rest of us, most are handled by clsObject.

Applications are classes, and every application is a subclass of clsApp. The messages for clsApp define how a running instance of the application (a document) behaves at the different points of its life cycle (explained below). Although documents are different things in the MacApp world, clsApp could be said to combine the responsibilities that TApplication and TDocument carry in MacApp. Since there can be any number of instances of an application class around at any time, there is also a metaclass, clsAppMgr, to handle the global issues. An instance of clsAppMgr represents an installed application and holds information common to all instances of the application (such as the application name, its icon, and its default size).

The user interface toolkit and windowing classes make up the largest subsystem of PenPoint. All the standard widgets are implemented (buttons, menus, scrolling windows, etc.), but in a different class hierarchy than MacApp. For instance, everything in the user interface toolkit descends from the window class, clsWin, which descends directly from clsObject. So your application window is typically a recursive structure of parent windows enclosing child windows. You arrange them on the screen at runtime by telling each parent window to lay itself out, with PenPoint handling the recursion for you.

Application life cycle

The life of a PenPoint application is quite different from that of an application in a traditional operating system. For one, there may be many instances of your application running at any one time (remember, each document is an application instance). Since the notebook metaphor also says that you can turn to any document in the notebook at any time, each document (application instance) must be running at all times, at some level of readiness. In the world of the Mac desktop, there is typically only one instance of each application running at any time, and the set of system-described states that it might be in is more limited. A MacApp application must respond to system messages to open itself (HandleFinderRequest), redraw itself (HandleUpdateEvent), and move between the foreground and the background (HandleActivateEvent). A PenPoint application must respond to these events as well, but must also live in some intermediate states.

The first state is instance creation, when a user creates a new instance of your application, such as by copying a piece of its stationery to the Notebook Contents. Your application class should create an instance of your application and let PenPoint know about it. From this point on, the application instance, and not the class, will receive most of the messages.

When the user turns to that instance's page in the notebook, PenPoint tells it to activate itself and open itself. Activation refers to creating a process in the operating system and either initializing the document data or restoring it from the file system. Opening refers to drawing the interface on the page. Note that a document can be active but not open; for instance, when doing background processing.

When the user turns away from the application's page to another page in the notebook, PenPoint tells it to close itself and then terminate itself. Closing usually involves saving any essential information about the document's state so that it can be reconstructed when the user turns back to that page, and then destroying the user-interface. Termination destroys the application process that was created at activation time. When the user turns back to that page, the application framework creates a new application instance with the stored information.

When the user deletes the document, usually by drawing an "X" over its name in the Notebook Contents page, PenPoint destroys that instance of the application. But the application class continues to exist, so that it can create other documents.

OOP in C

While PenPoint is fully object-oriented, it's not written in an object-oriented programming language. Instead, GO rolled their own object-oriented system in ANSI C when they realized that existing languages wouldn't easily support everything they wanted to do. PenPoint provides multiple inheritance, asynchronous message passing, inter-task message passing, and versioning support, features absent from or difficult to use in a language like C++.

The PenPoint object system is defined by the subsystem called the Class Manager. The Class Manager consists of the clsObject and clsClass definitions and the functions that implement message passing. You send a message by calling ObjectCall(), ObjectSend(), or ObjectPost(). ObjectCall() is for messages to other objects in your task, and is used most often. ObjectSend() and ObjectPost() are for messages to objects outside your task, sent either synchronously or asynchronously.

PenPoint keeps track of classes, objects, and messages by 32-bit unique identifiers, also known as UIDs. GO administers these to ensure uniqueness of the classes and objects that make up your application. You assign them in your code through #defines and macros.

While the language choice means that C programmers don't need to learn a new language syntax, they do need to learn a new set of programming conventions. Code written in PenPoint style is distinct from, and usually more verbose than, ordinary C or C++ code. But what isn't? Here's a MacApp class definition in C++ that describes class TFoo, a descendent of class TBar:

//---- Foo.h ----
typedef struct aStruct {
    int aField;
    int anotherField;
};

class TFoo : public TBar {
    private:
        short fSomeData;
    public:
        void SomeMethod(aStruct *anArg);
};

The equivalent PenPoint class definition might look like:

//---- Foo.h ----
// clsFoo is a subclass of clsBar
// (the actual inheritance is defined in the implementation
// file, and isn't set until a call to clsClass at runtime)

// The MakeWKN macro builds a well-known (global) UID
#define clsFoo      MakeWKN(2143, 1, wknGlobal)

// Objects themselves are all of type OBJECT
typedef OBJECT FOO, FAR *P_FOO;

// -- Message descriptions for clsFoo --
// (the methods they invoke are defined in a separate file)
/*****************************************************
 msgSomeMessage: takes a P_ASTRUCT, returns STATUS
*/
// (MakeMsg creates a unique ID similar to what MakeWKN 
// creates for classes)
#define msgSomeMessage  MakeMsg(clsFoo, 1) 

typedef struct ASTRUCT {
// PenPoint code avoids types like int or char which are
// compiler-specific, and instead makes sizes more
// visible, such as "U16" for "unsigned 16-bit". 
    U16 aField;
    U16 anotherField;
} ASTRUCT, FAR *P_ASTRUCT; 

For object-oriented purists, one of the attractions of PenPoint's classes is that they clearly separate the idea of message and method. The interface available to a class' clients is the set of messages it accepts; the methods that implement them are hidden in the class' implementation code. Also hidden from view are any private data members of the class.

Since both operating system and applications are object-oriented, the large majority of one's source code is message passing. As mentioned above, the syntax of message passing is that of a function call. All messages accept a 32-bit argument, which can either be a single value, or a pointer to a larger structure. For example, the following C++ messaging line:

   Foo         *foo;
    aStruct     anArg;
    foo->SomeMethod(&anArg);

would look like this in PenPoint:

  FOO         *foo;
    ASTRUCT     anArg;
    STATUS      s;
    if ((s = ObjectCall(msgSomeMessage, foo, &anArg)) 
                    != stsOK)
        return s;

Note that ObjectCall() always returns a status value. While you should always check the status of a message send, PenPoint provides macros that handle standard situations. For example, the above line would usually be written as:

ObjCallRet(msgSomeMessage, foo, &anArg, s);

Development Tools-or lack THEREof

With the rich development environments available on the Macintosh today, it's only the grizzled veterans who remember doing development on the Lisa using MacsBug. I'm guessing that few would want to return to those days. Perhaps the early PenPoint developers will have the same fortunes in the future, but today it's mostly the realm of Real Programmers.

Application development for PenPoint is done on a DOS-based machine with a VGA monitor, using an ANSI C compiler and the editor of your choice. You can run your application in a simulated PenPoint environment on the PC, using a mouse or a Wacom pen and tablet to simulate the real pen. While you can download your application to the pen-based machine at any time, the turnaround time is much faster when running the environment on the PC. A symbolic debugger from GO is provided with the SDK, and a second (monochrome) monitor is suggested to allow you to view debugging information while your application runs. The debugger knows about PenPoint objects, but it is based upon Microsoft's CodeView command-line debugger. The difficulty of mastering it leads most application developers to liberally sprinkle "printfs" throughout their code.

The landscape is not nearly as bleak as it was in 1984 for the Macintosh, since there is already an application builder for forms applications from Slate Corporation, a third-party developer of pen-based applications. The tool, called PenApps, is itself a pen-based application, and lets you use the pen to layout your form right on the pen-based computer. Given the experience people now have with development tools for graphical environments, it shouldn't take as long for these to appear for PenPoint.

A point about hardware...

One minor point remains to allow PenPoint to display its true spirit of a new computing age, and that is equally compelling hardware on which to run it. So far, manufacturers such as NCR, GRiD, and Samsung have paraded out wares that are being grudgingly accepted by customers, but this seems to be one area where software is ahead of the hardware: all of the machines suffer from short battery life, poor screen readability, or are overweight. It may be a couple of years before pen-based hardware is as well suited for its use as desktops and laptops have become.

Onward

This article won't let you start building your killer pen-based application tomorrow, but it should give you an inkling of what is involved. A background in MacApp gives you a head start in understanding the mechanics of what GO's PenPoint is all about, as well as an appreciation for the power of a completely object-oriented operating system. PenPoint introduces a whole new idea of "application," though, which offers exciting challenges to those who are beginning to think that all the interesting applications for the Mac have already been written. Coupled with the pen as a new input mechanism, and a platform that is meant to be used on the go, the applications that could change the way we work with computers are just waiting to be written.