Michael is editor-at-large for DDJ and can be contacted at 501 Galveston, Drive, Redwood City, CA 94063.
As GO Corporation scrambled toward initial release of PenPoint, its 32-bit, object-oriented, multitasking operating system, I stole some time from Robert Carr, the cofounder and head of development of GO. Pen-based computing looks like a potentially huge market with many technical challenges and product opportunities, but the operating system is interesting independently of its pen support. (The accompanying text box entitled "A Technical Overview of PenPoint" examines the OS.)
The conversation naturally revolved around pen-based computing and the operating system, but throughout the discussion, the speakers found themselves returning again and again to another topic: the proper locus of integration in software. As the author of Framework, Carr is an expert on integrated software, and the industry as a whole has held differing views over the years on the proper locus and degree of integration, and this has affected the range of opportunities for developers. PenPoint's approach to integration, Carr argues, is good news for the smaller, independent developers.
In the first installment of this two-part interview, Carr focuses on the PenPoint operating system itself; next month, he discusses the PenPoint notebook user interface.
DDJ: Maybe we can start from a moment in history that was probably memorable for you and back up from there. The moment in history that I have in mind is in early 1984 when you had just made an interesting deal with Ashton-Tate, a pretty hot company at that time, that would result in your product becoming their hot product of the year. It must have been an exciting time. How did you get to that point?
RC: I guess the key step in getting to that point was starting to work on Framework.
DDJ: You hadn't developed a single piece of application software on your own before. What led you to take on something like Framework?
RC: What led me to do that? Hmm. I had studied computer science at Stanford and worked at Xerox PARC, doing a small piece of applications programming on the Alto. Then I got somewhat disenchanted with software and took a year off and ended up in Los Angeles doing contract programming on Context MBA. That was in stark contrast to Xerox, where I had been a small fish in a big pond.
In L.A. I found myself working with a very small startup, just six or seven people. In spite of the fact that I was quite young, I found that I was able to make a lot of contributions and play a strong leadership role. So that, plus my break, it turned out, really energized me and got me very excited about creating software again. After about a year of working there largely implementing their vision, and as their vision became apparent, I started having a lot of my own ideas about how to do integrated software in quite a different fashion.
In working on Framework, what I was trying to do was to define all these elements that were in common across applications and abstract them out, and by doing so both to make it easier to implement the applications, but also to provide a highly integrated environment where the user would get many benefits, where they could mix and match, say, spreadsheets and word processing in a live compound document, or they could have tremendous consistency. I was always hobbled in my efforts because I was working at the application level and everything that I was abstracting out really needed to be put down in the operating system if it was going to work across applications that could be provided by third-party vendors. And of course up at the application level I couldn't do that, so it was all part of one larger application, a so-called "integrated software package."
DDJ: But that's the nature of integrated packages.
RC: That is the Achilles heel of integrated software, that it is a closed world. The end user can't go out and buy another piece and install it and extend it or mix and match their favorite applications. Hence integrated software, evolutionarily speaking, will never be a high-end product, even though in the '80s that's how it was positioned. Its long-term role is just more entry-level products for users who want a general-purpose, low-end, more cost-efficient solution. So with integrated software I had always been stuck with this problem. And that was one of the things that particularly attracted me to the opportunity to cofound GO. I felt that it was a rare opportunity where a major new market was opening up, with significant new technical needs, such that a new operating system really was needed, and therefore a golden opportunity for me to try to do an operating system (from my viewpoint) correctly, such that it could provide a high degree of integration across applications and yet be open-ended.
DDJ: Norm Meyerowitz, of Brown University, once wrote an article titled, "Why We Are All Doing Hypertext Wrong." His point was that hypertext needs to exist at the operating system level. It seems to me that his argument generalizes to pretty much anything that involves that degree of integration.
RC: Mm-hmm. In fact, I don't know if you know it, but Norm is working here now.
DDJ: I didn't know that.
RC: Yeah, that was a very good article. Many of the concepts of hypertext and object orientation he had been talking about he felt that we've done here at GO in PenPoint. He wants to get on beyond those. He joined us a few months ago.
DDJ: Let's talk about PenPoint; the characteristics of the operating system, why they're there, what you wanted to achieve with this operating system.
RC: Well, what attracted me to GO and to pursuing the pen market was the notion that here was a new market that needed a new operating system, and that was a rare opportunity because the world generally does not need twenty-seven hundred operating systems.
DDJ: How many does it need?
RC: I think it typically needs a slowly shifting constellation of five or seven or eight. In fact, I think that that's what we've always had historically, and MS-DOS's dominance for a period in the '80s I think was a historical anomaly.
DDJ: So what was the design vision behind your OS?
RC: What we've tried to do, since we did have a fresh start, was to build a very solid foundation that would last for many, many years to come. That was one going-in mission. And of course we wanted to code in a high-level language, and we also wanted to make sure that we could have as robust and as extensible an architecture as possible. That led us to the notion of object orientation and also to coding it in C. We wanted it, at a detail level, to work very well with a pen. At a more gestalt level, I've always thought that one of the impediments to ease of learning and use that other operating systems have is the file-system model. And of course we wanted to have a GUI so we could deliver the benefits that those can deliver. But I felt that beyond the GUI -- the other systems all seemed to me to be stuck in a dead end. Everybody has a desktop, the desktops all look like the other desktop metaphors, and the GUIs are all the same, and it's all vintage 1978 technology. And the evidence is very strong that it just isn't good enough for most people in terms of learnability and usability.
DDJ: One of your steps in increasing learnability and usability was to scuttle the file-system model?
RC: I think one of the major conceptual stumbling blocks is the presence of a file system, where the user has got to deal with developing a conceptual metaphor where they store things in these tiny hidden places that are represented by little character strings or maybe little icons plus a character string, and then they have to shuttle it from its invisible place into the desktop and can only have a few things present. So we really ought to come up with a conceptual metaphor that would be much richer than the desktop metaphor and also just do away with the dichotomy between your workplace and your filing place, and just have, in essence, your workplace.
DDJ: Increasing learnability and usability would seem to be necessary if one wants to open up the market for computers to people who don't, or can't, or won't use them today. Pen-based computing seems to be, in large part, intended for just that market-expanding purpose. It opens computer use up to people who can't or won't type, who don't sit at a desk. Didn't you also have the idea, in developing PenPoint, that what you were going to be doing would address a considerably larger audience than personal computers today?
RC: Absolutely. In fact, that was one of the major motivations for a new operating system. We felt that the vast majority of our market that we would be going after would be a market of new users who would be oftentimes using new applications and would be using it on new hardware that would be fairly different from existing PC hardware configurations. So when you have a new market and new users and new applications and new hardware, a new OS was the only missing part of the puzzle, and that was the business opportunity we wanted to go after. And to go after new users, we saw we'd have to have an easier to learn and use system. Another goal was to make application development easier and also have it provide many of the benefits of integrated software to end users across all applications on the system. Hence my own roots in doing integrated software and being an application developer.
DDJ: So we're back to integrated software.
RC: Basically, what we wanted to do was find as many elements that had traditionally been done at the application level and done again and again and again and again at the application level, reinvented by every application team, and take those out and implement them once in the OS, so that you speed application development and give them a more consistent user interface. The way we knit it all together is with something called the Application Framework.
DDJ: Interesting name.
RC: Hm. And of course we draw on such things as MacApp from the Apple world, and there's also been some university research in application frameworks, and we were able to draw on those sources in putting these application building blocks, if you will, right into the OS and letting all applications inherit them.
DDJ: Object orientation is a vogue term, and as such is often used pretty loosely. My understanding is that your approach to PenPoint was object oriented from the start. What did -- what do -- you mean by object orientation?
RC: What we mean when we say that PenPoint is object-oriented is that the programming interfaces are implemented as a sequence of objects that you can send messages to, and that these objects are instances of classes, and classes can be subclassed, thereby modifying their behavior, and of course the objects tend to encapsulate information and behavior and hide the actual data representation from the folks that want to communicate with them. So I think anybody who has studied what I'd call "true object orientation" in the Smalltalk sense will find that when we talk about object orientation, that's what we mean. Almost all the programming interfaces are objects to send messages to. It is not a lot of function calls.
What we've done that no one else has done yet, because no one else has done an entire operating system in an object-oriented fashion, is we've extended the usual object orientation notions in several areas that are necessary to do a true modern OS in an object-oriented fashion. For instance, our object model allows objects in multiple processes to communicate with each other, and we allow objects to be global and to be shared between application instances, which is a good example of a technical requisite. If you're going to have a high degree of integration in an environment, you want to be able to share objects between different application instances. And yet languages such as C++ don't address the notion of sharing objects or even classes between applications. They're just designed to structure the guts of a single application in an object-oriented fashion. They're not a whole lot of applications sharing a lot of code and behavior between them in an operating system where applications and classes can be installed and deinstalled. When a new application is installed, what actually happens is we have to graft a lot of their classes onto the class hierarchy.
Well, what happens when a class comes in that is just another version of an existing class? You have versioning issues, all of which are important in the real world, where an end user is not necessarily going to want to install new copies of all their programs any time they get any kind of an update of any piece of an application.
Another issue is the persistence of objects: the notion that you can file objects and then later on unfile them and they need to get coupled up with the code that represents their behavior. Those are all notions that we've built right into PenPoint's object model that underlies the language implementation of the object-oriented paradigm.
DDJ: Tell me about how PenPoint deals with documents and files.
RC: What we've done is, we've hidden the file system from the user. In PenPoint, you just turn pages in the notebook, and the operating system will automatically create an application instance and a process for the new page that you're turning to. Then that application will get its data out of a file system, but that file system is completely hidden from the user.
DDJ: So you do have a file system. It almost sounded earlier as though you had dumped the notion completely.
RC: It turns out that the file system is a very sound concept to have in an operating system. It's the place where the application can store its data in what I'll call a passive form, which is a form in which you're not using actual memory addresses. The active form typically cannot survive across a crash or a restart or an application reload, so to store the data in a robust fashion so that it can be used again even if the OS restarts or even if you load the data into a different machine that has a different memory layout, you need to store it in this passive kind of memory-location neutral format. We wanted to be sure that PenPoint was a very robust system such that even if the OS itself crashed we could do an on-the-fly restart and have the user right back with all the data. So we have applications, behind the scenes, store their data in a fairly traditional and robust protected file system.
DDJ: So what does the file system look like to a developer?
RC: To the developer, the APIs to the file system are object oriented, so there are some classes that you talk to, a class directory handle, for instance. The kinds of functions you can perform on the file system are very traditional: You can have stream-oriented I/O, you open files, you close files.
The actual feature set of the file system is that it's a blend of the OS/2 HPFS and the Macintosh system. You can have long filenames of 31 characters; the files can have attributes attached to them; files have what you might think of as a resource fork as well as a data fork. It's a good, modern, sophisticated file system. What we do is we map this file system onto the local [device]. If you store these files, say, on an MS-DOS floppy or on an IBM PC or on a Macintosh, we'll preserve all these semantics when we store the files even on these foreign file systems.
DDJ: And what does the user see?
RC: What the user sees is just a document that they turn to. That document is a page in the notebook, and one of PenPoint's major innovations is that inside that document or application instance -- the two are synonymous -- the user can actually place other applications or documents and create a hierarchy of applications. This is a common theme again from Framework, where you could create a hierarchy of objects. The benefit to the user is that they can create a live compound document just as easily as they can create a single document that's of a single data type.
DDJ: Compound documents are certainly a hot topic right now.
RC: I don't pretend that all users all of the time need to create compound documents; in fact, I'm leery that many users very often need to do that in the traditional ways that our marketing people in this industry show. Of course, everybody likes to show a spreadsheet and a graph inside a letter, right?
DDJ: Makes a good demo.
RC: I'm skeptical that that actually gets done very often. There are times when users mix spreadsheets and graphics into their word processing, but there are many other kinds of more subtle examples that can be achieved by the same architecture, and that will be more important as time goes by. Mixing in-line Post-It notes and signatures into the body of a word processing document, or a logo or voice annotation Post-It note or building applications that you might think of as custom or vertical applications, but where you are reusing other applications as your building blocks.
DDJ: Dave Winer has talked in our pages about achieving that through interapplication communication on the Macintosh. How do you support it in PenPoint?
RC: Technically, what you need to do there is to put the building blocks under the control of your new meta-application. Maybe what you're creating is an interactive report viewer that's going to show some data on the screen to your executive. If the operating system supports you sticking a spreadsheet or a database application right into the middle of your new meta- or vertical application, that can make your job very easy. But the OS has got to support the other application running right inside yours or else you're going to be stuck with having to start from scratch.
DDJ: Tell me what your multitasking is like.
RC: Our multitasking is most similar to OS/2. We provide a model in which processes are the basic unit of ownership for resources such as memory, and within a process you can have child threads, so you can get multitasking even inside of a process if you want. The basic rule is that every application instance is a separate process. So, if an application crashes, what the operating system will do is shut that process down, but the rest of the operating system and other applications will keep going. We have a decent array of interapplication primitives, semaphores, and the like.
One of the interesting notions about PenPoint from a process viewpoint is that the application framework defines what you might think of as a life cycle of an application. The life cycle starts with the notion of an application instance being created, and in each stage of the life cycle there are explicit messages that will tell an application object to move from one level of the cycle to another. So there's a message to create an instance of an application; there's a message to activate, which means be awake, so that you've got all your data open and ready to work on and you're ready to communicate with other application objects but you're not yet displayed on a screen; and the highest level of nirvana is to actually display yourself. And then there are backing-off stages for that: You're no longer on the screen but you're still active; then there's closing you down such that you're completely filed and you don't have an active process; and lastly there's deleting the instance.
An application basically needs to respond to these messages, and somebody outside of the application tells the application when to wake up, when to be creative, when to shut down, when to display itself. So you can imagine that when you turn a page, the notebook is sending these messages to an application. But if an application is embedded inside of another application, then it is the parent that can be sending these messages to the child or embedded application, thereby controlling its fate.
DDJ: You did the original work on PenPoint on the 286, but you've been moving it over to the 386, which looks like the assumed machine today. Wasn't that early work painful?
RC: If we were doing things over today, we would pick the 386, to be honest. I guess we called that one wrong. But in '87 when we chose the 286, from both a hardware and from a software viewpoint it seemed like a conservative choice to make.
As a startup back then with just five or six people, we felt we were taking on enough risk points so that pushing the envelope in the processor choice area was something we chose not to do. We did not know of a low-power version of the 386 back in '87; in fact, Intel probably didn't know about it, because they probably didn't have their SL chipset even underway back then. And back then I felt that the tools for the 286 were there and were fairly reliable because OS/2 was driving the 286 protect mode. There were a couple of 386 compilers -- I wasn't familiar with them, so I don't want to denigrate them, but I was fearful that the tool support for the 386 native mode would be weak. What happened was that by 1990 we were successful enough, and we learned about the 386SL chipset that was due to come from Intel, so that it became clear that we had an opportunity to switch over to the 386 before we ever really reached the market, and thereby avoided getting trapped in the Intel segmentation world with an installed base.
DDJ: Was it a difficult port?
RC: We had always designed and programmed PenPoint to be a 32-bit operating system, so even on the 286 all the programming interfaces were 32 bits wide. Of course that compiled down sometimes to some costly instruction sets, because you've got to load the segmentation register and the offset register. Because we had done that, moving to the 386 was a pretty straightforward thing to do, and were just about done doing that. We had to rewrite portions of the multitasking kernel, because the 386 native mode is different from the 286 mode, and we have added virtual memory support to the kernel. But above that kernel level, for all the rest of PenPoint, it's been pretty much a recompilation. And that's all it's going to be for application developers who've been coding on the developer's release.
DDJ: Other platforms?
RC: We designed PenPoint for portability. You'll see us exploit that to the greatest degree we can in the next couple of years. First of all, now that we are a flat-memory model operating system written in C, and a 32-bit one, we are just as portable as UNIX. Arguably a bit more portable. So you may very well see us move to other processors, including RISC processors.
To further aid portability we've isolated as many machine dependencies as possible in a layer we call the MIL, the Machine Interface Layer. It's somewhat similar to a BIOS layer, but it's a more modern version; it's an extensible and reentrant form of the BIOS. Our hardware companies are responsible for implementing the MIL layer. If they want to have some unique features in their hardware, they can write some new MIL code to provide a low-level interface, and then PenPoint applications will support that. The last aspect of portability that's really important to mention is scalability to different configurations.
DDJ: Meaning different display sizes and aspect ratios?
RC: Well, there are two dimensions to it. One dimension is the memory configuration. We will run on a machine that has no disk, and therefore is just what I will call a "single-tier" memory configuration. But we will also run on a machine that has a disk or backing store of some kind. Of course, when we do that, we hide the fact that there's a two-tier from the use . We hide the fact that there's a disk drive there, because we also hide the notion of a file system. Hence the virtual memory implementation which makes it transparent to the user. So that's one way we scale: We'll run on diskless machines as well as on disk machines.
The other way we scale is that the user interface will adjust to fit different screen sizes and aspect ratios. So we can run on much less than 640 x 480 pixels. And that's very important because devices the size of your [reporter's 4 x 8-inch] notepad will be very popular I think in just about a year or two.
DDJ: You said "arguably more portable than UNIX." Were you giving me that argument when you talked about the MIL layer?
RC: Yes, and also, portable while retaining binary compatibility. Because when we license [PenPoint] to hardware companies, we will not give them source code access to it. They will be responsible for implementing a MIL, and then the PenPoint binary will run directly on top of that MIL and what they will get from us is a copy of PenPoint binary. And our license requires them to provide for not only API but also full binary compatibility. So the applications market should grow fairly rapidly with PenPoint, since there is one application binary that will run on all these PenPoint machines. But the hardware companies, all of a sudden, can begin designing hardware that's different from other hardware, whereas in the PC world they've had to clone the hardware even down to the trace level so that they could be assured of running the software.
DDJ: You mentioned RISC. Anything in the works?
RC: We're actively evaluating various opportunities to move PenPoint to RISC processors. That's all I can say now. But we think RISC processors offer some real benefits to users in terms of their performance, and also low-cost and low-power consumption. And if we do move PenPoint to any of these RISC processors, we'll be ensuring that the same data files work -- that it's one single data file format for all applications across the different processor families. But while I praise the RISC opportunities, we're also very pleased by what we've seen from Intel in terms of their interest and cooperation in the pen market. They have told us that they are very committed to providing competitive processors there, and we believe them.
DDJ: GO and Phoenix Technologies have announced an agreement that provides Phoenix with GO's hardware design -- its electrical and mechanical specifications. What does the Phoenix deal mean to GO?
RC: I view Phoenix as icing on the cake for GO. Our main business is providing an operating system to the hardware companies, and there are a couple dozen we are working with right now. What Phoenix offers us -- and we're very pleased to be working with them -- is the opportunity to reach many hardware companies that we could not get to right now. They're both selling a pen-based hardware design to these companies, and also offering both BIOS and also MIL implementations. So I think what they'll basically do is speed the development of the clone market in pen computers. Whereas in the '80s that took many years to develop, we may well see some clone companies shipping good pen offerings next year.
DDJ: You say that pen computing offers a lot of significant opportunities for software developers. One area in which the technology is certainly still in development is handwriting recognition. Are we going to see in our lifetimes a machine that can read this? [Swaine's notes]
RC: I think it's unlikely that we'll see computers recognizing handwriting that humans can't recognize. Unfortunately today, however, computers can't recognize handwriting that humans can. So there's definitely room for improvement. I think we'll see rapid improvement. First of all, we believe it's a software problem, not a hardware problem, and that the algorithms should stay in software for quite a few more years. Sometimes people wonder if there's some sort of special hardware that can help handwriting recognition. We think that that's not the case. The technology is still very young. Not that many man-years have been invested in handwriting recognition over the last ten thousand years. There have been only a few noticeable products, projects that have gone on during the '70s and '80s.
DDJ: And that's going to change?
RC: Now that Microsoft and GO are offering operating systems in which the handwriting module can be replaced by a third party, for the first time ever there's a market for handwriting recognition engines. We think that that'll unleash a lot of entrepreneurial and technical innovation and that we'll see rapid progress, both because more and talented teams are working on the problem, but also because the teams in place are continuing to work on it, and perhaps getting more real-world feedback on their approaches. And then lastly, much of the handwriting recognition is CPU-bound, and since CPUs are tending to double their performance every 18 months, time will help solve this problem.
Carr continues his conversation in December's "Programming Paradigms," covering the PenPoint Notebook User Interface (NUI), imaging model, and more.
Ray Valdes
GO's PenPoint environment, in development for four years now, represents perhaps a hundred person-years of software development effort. What was accomplished over that time?
After taking the week-long developer course last November, and doing a little work on my own on the system, I've found that the results of GO's effort are indeed impressive:
The dry list above does not hint at the impact of using a PenPoint machine for the first time -- an exhilarating rush similar to my first experience of using a Mac, eight years ago.
Given such results, a hundred person-years is a scant amount of time. GO has been able to reach its ambitious goals by front-loading the team with high-powered talent. Many, if not most, developers there have earned their spurs on some significant past project in the PC industry.
Lest you think I've been snowed by GO's technical evangelists, I do have some criticisms of the system, presented further on. First, a brief tour of rich and complex environment.
Unlike other platforms' system components, many of which were designed independently of each other and now suffer through an uneasy coexistence, PenPoint can take advantage of the "clean slate" approach. There are no quirky DOS misfeatures to circumvent or tolerate.
At the higher layers, the object orientation of the system is paramount. Designing a PenPoint application is similar to creating one for the Smalltalk environment, in that you instantiate and/or subclass the components of your app from existing classes in the application framework (in this case, three classes: clsApp, clsView, and clsObject).
Mobile stylus computers have memory constraints much stricter than those of desktop machines, so code reuse is essential. PenPoint maximizes code reuse through its object orientation and via a much higher level of application integration than that in Windows or Presentation Manager.
Both Microsoft and Apple have now been fostering increased integration among applications -- through protocols such as Object Linking and Embedding (OLE) or System 7 AppleEvents. But PenPoint has the advantage here because the layer is not added on after the fact, but inherent in the design.
A key concept in PenPoint is "scalability," which means, among other things, that all visual components resize and scale themselves at runtime to fit the desired display format. This concept is woven into the system at a meticulous level of detail, from the system font, to the system menus, to other objects; all these resize and reposition themselves automatically according to user-defined constraints.
Another concept thoroughly blended into all system behavior is the notion of a core set of gestures that work in all contexts and modes.
Viewing the layers of PenPoint's software architecture from bottom to top, the lowest level is the PenPoint Kernel. This component uses a traditional function-call programming interface, as opposed to an object-oriented protocol. The Kernel offers the standard features of a modern OS, such as priority-based preemption, multitasking, multithreading, interprocess, communication and synchronization (through semaphores), and memory protection of code and data.
To support mobile computing, the OS powers down the CPU when all tasks are idle, and wakes it up for pen events and timer alarms. To accommodate diskless, memory-constrained systems, execution of programs does not imply two copies of an application's code (one loaded into RAM and another stored on the file system). Rather, a single relocated image is shared across all clients. Hardware memory protection helps preserve the integrity of code and data in case of a system crash.
The current developer release of PenPoint supports memory-management functions specific to Intel's segmented 286 architecture. The commercial version will include changes to support a 386-style architecture (32-bit flat model).
Sitting next to the Kernel at the lowest levels of the operating system is the Class Manager. This supports the objects used by higher-level components such as the UI Toolkit and the File System. The Class Manager provides message-passing capability for PenPoint objects, as well enabling object creation, behavior inheritance, and runtime definition of classes. Although class definitions are built dynamically at runtime, the specifications are usually written at compile time.
How is this done without using an object-oriented language? GO has established a set of C programming conventions, including preprocessor macros and #defines, and a special utility (the method-table compiler) that together enable a form of OOP, despite the use of object-resistant language.
Applications are written in C on DOS machines, compiled with the Microsoft C 6.0, and then linked by the OS/2 segmented executable linker with PenPoint runtime libraries. They are then either downloaded to a PenPoint tablet or tested on a developer version of Penpoint that boots up on your DOS desktop machine.
GO documents say that as much as 80 percent of the line-by-line structure of an application program's code consists of statements that send messages to objects via Class Manager calls. This, for me, is the most irritating aspect of writing PenPoint apps. Although the system design is beautiful, the mundane details of coding are cumbersome and ugly. Briefly, sending a message in PenPoint involves declaring a struct to hold the message parameters, filling in the struct members with parameter values, and then making a function call to the Class Manager. It's possible that GO may offer a true object-oriented language (C++?) at some point in the future. Why didn't GO choose C++ at the outset? Four years ago, when the development effort began, there were no C++ compilers available for the 80x86 platform. Another obstacle is that C++ doesn't allow for runtime definition of classes.
PenPoint's file system is strictly hierarchical rather than graph-structured (that is, like DOS or the Mac, not UNIX). The File System consists of volumes, directories, and files. One feature addressing mobile computing is the ability to mount and dismount volumes easily. Files can have user-defined attributes. A nice feature is the ability to subclass files. This facilities implementing application-specific structured files, such as Mac-style resource files.
Interestingly, the File System is a higher-level abstraction the can be implemented on top of lower-level existing file systems such as DOS or the Mac. In fact, the version of PenPoint that boots from DOS machines implements a single PenPoint file with a DOS subdirectory containing multiple DOS files.
Continuing up the layers of the system, there is ImagePoint -- a set of graphics primitives that go beyond those in Windows' GDI, Presentation Manager's GPI, or Apple's QuickDraw, to approach Display Postscript's functionality.
A single imaging model is used for both screen display and printer output. All objects can be arbitrarily scaled, rotated, and translated. Display objects include Bezier curves (no Postscript-style paths, however), as well as sampled images in a variety of types and formats.
Further up, there is the Windowing layer, which supports operations on window objects, such as moving, sizing, repainting, clipping, filing, enumerating, and so on. As in Microsoft Windows, you can have a bunch of parent and child windows instantiated in a tree structure. Unlike other systems, windows in PenPoint can reposition and resize themselves (and their children) automatically. This is a key feature that enables system scalability. It is backed up by some sophisticated algorithms to minimize CPU cycles.
The UI Toolkit implements the middle layer of PenPoint's user interface. The UI Toolkit calls on the Windowing and Graphics subsystems to draw user interface components and graphics primitives. In turn, the Application Framework and the classes implementing the GO's Notebook metaphor (NUI) use UI Toolkit objects extensively.
The UI Toolkit contains user interface "widgets" such as buttons, labels, borders, tables, menus, pop-ups, scrollbars, list boxes, option sheets (dialog boxes), editing fields, and icons. Many of these objects can recognize pen-based commands and capture handwritten text. Nearly every window which has a label or responds to the pen is a UI component of some sort. Their behavior appearance is modified through subclassing.
The Application Framework, the highest level in the PenPoint software architecture, allows for relationships among application-level entities. Compound documents can be built by embedding one application within another. Thus, developers of PenPoint apps need not build all aspects of an application in order to provide a full-featured solution to their customers. Rather, they can concentrate on the critical pieces of software that they know best, such as implementing an efficient scientific algorithm or a complete set of actuarial rules. With this unprecedented collaboration among application-level components, GO hopes that the whole will be much more than the sum of its parts.
Experiencing PenPoint as a user is thoroughly enchanting. As a programmer, however, there are some thorns in the side. Already stated: the coding of message sends. Also, it takes about a minute to reboot the system from a DOS desktop machine, never mind the compile and link cycle. Developing for PenPoint is similar to Mac development in its infancy, when you needed a Lisa and had to sit through compile-and-download cycles.
The people at GO, of course, are well aware of these and other criticisms, and are addressing them. Third-party vendors are also busy here.
From a distance, the design appears well-conceived. Closer up, there are blemishes now being touched up. I've not worked with the system enough to discover those irritations and obstacles that only surface over time. When these appear, I don't think they'll diminish the compelling beauty of the system's design and implementation.
--R.V.
Copyright © 1991, Dr. Dobb's Journal