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