Mesa was first implemented on the Alto [Thacker79] in 1976. The development environment was the Alto operating system [Lampson79] whose user interface was the Executive, a BCPL program that operated much like the time-sharing executives of the day. When one invoked a tool, such as the compiler, it ran in the entire machine (along with pieces of the operating system), and when it was finished, the Executive was reloaded to process the next command. There were provisions for chaining together commands by means of disk files with distinguished names.

The Mesa debugger was patterned after the BCPL debugger to the extent that it used the same world swap principle. When the debugger was invoked, the contents of memory were written to a disk file, the client outload file, and then memory was loaded from another file, the debugger outload file. The net result was that you were now running inside the debugger and could examine and modify the client world by reading and writing the client outload file. The debugger had the ability to set breakpoints and to display program data in a format determined by the type of the data. It had a crude ability to call procedures in the client code. The debugger had multiple windows patterned after those of Smalltalk [Kay76]. One, a typescript window, was used for interaction with the debugger executive for setting breakpoints, examining data, etc., and another was used to show the source context at breakpoints.

In 1977 (Mesa 3.0), we introduced strong intermodule type checking by means of interfaces and the Binder. The ability to check procedure parameters at compile or load time was a clear win. It often took a while to produce a consistent version of a large system, but once it could be loaded, it would usually run well enough that the programmer could start looking for logic errors. The early days of binding are described in some detail in a paper by Lauer and Satterthwaite [Lauer79].

In 1978 (Mesa 4.0), we added monitors and condition variables to the language to facilitate parallel com- putation. These features were of particular use in implementing the multi-level communications protocols in our internet environment.

By April 1979 (Mesa 5.0), the window package was much more integrated into the debugger. Breakpoints were set by pointing to the source, and text could be copied from one window into another to avoid unnecessary typing. The source window was readonly, however; there was no way to edit programs from within the debugger.

Version 6.0 of Mesa (October 1980) was the first that could reasonably be called an integrated environment. Programmers tended to do most of their development work inside the debugger. There were several advantages to this: the world swap discipline meant that the debugger world persisted across the running of applications; one could edit in several windows at once, and use a file transfer window to get needed files from remote servers. There were, however, still applications that required the programmer to exit from the debugger and talk to the Alto executive.

The major shortcoming of the Alto was the lack of virtual memory, so in the late 70's several machines were developed to replace the Alto and the Pilot operating system [Redell79] was written to replace the Alto operating system. The machines included the Dolphin (1978), the Dorado (1979), and the Dandelion (1980). The Dandelion is the machine on which the Xerox 8000 Series products are based (including Star and Network Services). It is also the machine on which the current Mesa development environment runs. For the sort of applications that it typically runs, a Dandelion has computational power somewhere between a VAX 750 and a VAX 780.

The first Pilot based debugger looked a lot like the Alto one, even sharing a lot of source code for the debugger proper. The major addition was a new Executive window. This window was the access to a program that was a transliteration of the Alto Executive. It allowed the user to run the more batch-like applications such as the compiler and binder, and included such niceties as command file expansion. Many of the Alto applications were rewritten to be run from this executive. The major difference was that the world was not reloaded after an application finished; an application had to be more careful about freeing up any resources it had acquired. There was still a one-thing-at-a-time mentality. For example, the compiler turned off the display when running in order to get more cycles.

Various experiments were made where tools would fork a (pseudo)parallel process to do their actual work. This met with limited success since some of the system resources, notably the file system, were not particularly reentrant. As a result, the file system was replaced [Reid83], and by April 1982 (Mesa 8.0), there was a truly integrated environment that allowed parallel execution of most of the tools. To the typical programmer using the environment, this was a quantum leap forward. I suspect that coffee consumption went down, since there was no longer the need to find something else to do while the compiler was running; you could read your mail, or edit the next program to be compiled.

In the next two years, the underpinnings of the system were largely rewritten (often with little visibility to the applications running on top). The display management was rewritten to improve performance and further work was done to make concurrent execution of applications more robust. The virtual memory and low level file management of Pilot were rewritten and the instruction set of the Dandelion (implemented by RAM based microcode) was reworked [Sweet82]. Of course, the collection of tools increased in number.

There were a number of goals and features of the language effort that had an impact on how the environment was structured. From the beginning, our goal was to allow development of large complex software projects with sufficient performance to be usable in a production environment.

Interaction with the user is through windows on the screen. A window is a rectangular area of the screen, and may be covered with subwindows, resulting in a window tree. Each window has a size and a position relative to its parent. Windows at the "top level" are children of a system supplied full-screen root window. The data structure used for representing this tree is a LISP-like scheme where each window points to its first child and to its next sibling. Windows can overlap in arbitrary ways, but the rules for visibility are easy to state in terms of the tree structure. Windows obscure their parents, but are clipped where they extend beyond the dimensions of their parent. If two overlapping windows are siblings, the one earlier in the sibling list is on top. Figure 1 shows several tool windows. The windows of the File Tool and the Executive are overlapping siblings, subwindows of the File Tool are non-overlapping siblings.

The system provides routines for adding scrollbars to subwindows. All of the subwindows in Figure 1 have vertical scrollbars. The scrollbar changes color when the cursor moves into it, giving feedback on that portion of the file currently visible. In the bottom subwindow of the File Window, the dark grey portion of the scrollbar indicates that the visible portion is about 40% into the file and is about 10% of the total file size. While the cursor is in the scrollbar region, the three mouse buttons are used for positioning. The left means "scroll up," the right means "scroll down," and the center means "thumb to this place in the file."

Each window is implemented by an associated window object, which in turn is accessed by a window handle, a pointer to this object. The object contains information about the tree structure, this window's location with respect to its parent, and several procedure variables, such as a repaint procedure that gets called whenever a portion of the window has invalid contents. The implementation makes use of Mesa's opaque type mechanism, so that client programs do not depend upon the actual representation of the window object. There is, however, a procedural interface whereby client programs can manipulate the information in the object.

Client programs can attach additional information to windows by means of named contexts, similar to property lists of LISP. Tools can be written to have multiple instances, obtaining their data from the context associated with the particular window that Tajo is notifying (passed as a parameter to the notify procedure). See §3.5 for further details.

The user has control of the placement, overlap, and size of top level windows; maintaining the remainder of the window tree is the responsibility of client programs. Consider, for example, a tool that divides its window into two equal sized subwindows. Whenever the user changes the size of the enclosing window, the sizes of both subwindows and the relative origin of the second one must change. Tajo allows the client program to register an adjust procedure that gets called before and after the window changes dimensions. Since adjustment strategies are often shared by multiple window instances, a classing scheme called window types is used. Every window has a type, and associated with every window type is a collection of procedures. In addition to the adjust procedure, there is a wakeup procedure that is called when a window first becomes visible and a sleep procedure that is called when it will no longer be visible until awakened.

To simplify the task of the tool writer, there are several system-provided subwindow types, each with its own runtime management routines. Some tools have only one subwindow, like the file subwindow for the log of the Executive in figure 1. Some tools have multiple subwindows of the same type, like the two form subwindows of the File Tool. The three most popular types for incorporating in tools are the following:

When a tool has its full-sized window open on the screen, it is said to be in an active state. This is like having a woodworking tool out on the workbench, ready for use. Tools that will not be needed for a while can be shrunk to an iconic form on the screen; these tools are in the tiny state (see figure 1). A tiny window typically retains all window state, such as parameters that the user has given the tool, options selected, or messages posted by the program. In the physical metaphor, think of tools that are placed in a tool belt, convenient for use, but not cluttering the bench. The third state for tools is inactive. When tools are deactivated, they disappear from the screen entirely. By convention, they free up any system resources that they are using, including the previously described window state. They are, however, added to a menu of inactive tools so that they can be subsequently re-activated. These tools correspond to those put back into the tool box.

The tool data contains a client supplied transition procedure that gets called whenever the tool changes state. System-defined subwindow types such as form subwindows have system supplied transition strategies that "do the right thing." For example, file subwindows close the backing file when the tool is deactivated.

The right mouse button, called Adjust, is used to extend or contract the selection. Pressing Adjust causes the closest end of the current selection to move to the cursor position, subject to selection mode constraints (e.g., to the end of the current word if in word mode). As with Point, the selection tracks the cursor and "commits" on the up transition. There is one subtle, but quite useful addition. If the down transition of Adjust occurs when the cursor is over the last (or first) character of the selection, the selection mode reverts to character for extension purposes.

Other selection schemes have been tried and discarded. They include draw-through selection and separate character and word select buttons. Other indications of selection were tried as well, including underlining the selection and drawing a box around it.

There is a single global selection in the environment. Client programs that wish to deal with the current selection do so by calling a system interface Selection. Such clients fall into two different classes. The most common are those that wish to obtain the value of the current selection. This is done by calling the procedure Convert. This procedure takes a parameter describing what the client wants to know about the selection, e.g., its value as a string, its position within a file, the window containing it, or its value parsed as a number. The most common target is a string. For very long selections, copying the text to a string would be inefficient. In this case, Convert will refuse to return a string, and the client can ask for a source, a stream-like data structure that allows sequential access to the characters of the selection.

The other class of clients that deal with the selection are those who want to manage the current selection. This is done by calling the procedure Set, giving it two procedures: one that gets called when the global function Convert is called, and the other that gets called for various actions like un-highlighting the text when the selection changes. For most text selection, the calls to Set are at a level of abstraction far below that seen by typical client programs. An example of a client program where the programmer explicitly calls Set is a graphics editor where the client wants to make selected text in its window available to another tools that read the current selection.

One more subtle point on selectionwhen a client program is the manager of the selection, its conversion procedure need not support all of the potential target types defined in the interface. The conversion procedure is welcome to return NIL for any (or all) types. In the graphics editor example, the "position in the file" would have to be a two dimensional quantity rather than the scalar quantity it is for text files, so the editor would return NIL.

There is the concept of a global input focus in Tajo. This focus is associated with a particular subwindow. The input focus typically goes with the current selection, but the user interface provides a means for setting it independently. Within the subwindow there is an insertion point which falls between two characters. When the selection is moved, the insertion moves to the end of the new selection (character, word, line, document) closest to the position of the mouse when the mouse button Point is released. For example, clicking 3 times in the first half of a line selects the line and moves the insertion to the beginning of the line. The user profile can specify options that change the tracking of the insertion point, e.g., to always place the insertion at the end of the selection (as opposed to the beginning).

If a client program thinks of the keyboard as an ASCII input device, it can call a system procedure to associate a string input procedure with any of its subwindows. Whenever a character key is typed and that subwindow has the input focus, the procedure will be called. There are three keys that bear further discussion. The Stuff key simulates type-in of all of the characters of the current selection. The Copy key works as follows: when Copy goes down, the current selection is cleared. The user now makes a new selectionthe tracking of the insertion point is disabled during the selection. When Copy goes up, this new selection is stuffed into the insertion point. The Move key works like Copy except it simulates a Delete after the copy has been done.

Being called with type-in is certainly consistent with the "Don't call us, we'll call you" philosophy described in §2.2, but some programs would rather ask for characters than be told about them. Such programs are usually transliterated from traditional timesharing environments where the program worked on the model that it owned the whole virtual machine (and the user as well). This style of interaction is supported by teletype subwindows, another system supplied subwindow type. These supply an abstraction similar to that of file subwindows, but with the requisite input/output model. The only subtlety is that when the client program is started, it must be careful not to read characters before it FORKs itself a process separate from the notifier.

Some client programs wish to give non-standard interpretations to the keyboard or mouse. The rest of this section describes the low level interfaces to user input. The keyboard of the Dandelion is non-encoded; there is a region of memory from which a program can read the current up/down state of each key. Very few applications deal with the keyboard at this level; they use a facility called TIP (for terminal interface package). At the heart of this package is a collection of TIP tables, descriptions of desired operations for specified user actions. These tables are associated with windows in a tree structure.

A high priority process watches the hardware for user actions. These actions are then enqueued along with their times of occurrence in a user action queue. A user level process, the notifier, removes these actions and matches them against the proper TIP tables.

If it finds the action, it passes the corresponding operations to that window's associated notify procedure. Some user events, such as most keystrokes, are for the window that currently has the input focus. Other events, such as most mouse button clicks, are directed to the window that contains the cursor.

A TIP table looks like a large SELECT statement with user actions as the selector arms. There are two classes of actions that can appear: TRIGGER actions refer to actions that are removed from the user action queue, such as a key going down or up, ENABLE actions interrogate the current state of the user interface, such as a shift key being down. If a left-side is matched, the notify procedure is called with the list of result items on the right-side. For example, the fragment

A more complicated example deals with the left mouse button going down. In this example, it could be part of a single or double click, or part of a chord simulating the middle button.

An item in the result list (right-side) for an action is a variant record whose variant has one of the following types:

From the programmer's standpoint, menus are easy to construct. There is a system procedure that is given a window handle and an array of <STRING, PROCEDURE> pairs. The strings become the menu items, and the corresponding procedure is called whenever the user selects that item. The system procedure returns a menu handle which can then be associated by other system procedures with one or more subwindows.

Menus can provide many commands without requiring the user to remember the exact command names. However, for frequently used operations, it is cumbersome to remember which menu contains the desired command, bring it to the front, and select the item. One solution to this problem is symbiote subwindows. They appear at the top of other windows and contain a list of identifiers. When the user clicks the mouse button on one of these identifiers, the symbiote handler searches through all the item names from the collection of menus on the other subwindows of their window. If it finds a match, it calls the corresponding procedure. The TIP example in §3.5 shows how, with the proper notify procedure, one could also turn keystrokes into menu activations.

The runtime loader is technically not a programming tool, but rather a part of the Pilot operating system kernel. Nevertheless, in order to understand the other programming tools, some knowledge of the runtime loader is needed.

A Mesa object program has, in addition to code, a header that specifies a list of interfaces that are imported or exported. These interfaces are the "glue" that holds modules together into larger programs. The binder specification language and operation are described in detail in the language manual [Mitchell79] and a paper by Lauer and Satterthwaite [Lauer79]. The runtime loader maintains a database of all interfaces imported and exported by programs now loaded (either part of the original boot file, or previously runtime-loaded). Loading a new module is a three step process:

Note that the loader is capable of many of the tasks typically associated with the linkage editor of a more batch oriented system. Indeed, small multi-module systems are sometimes tested by simply loading the various modules. Large or publicly distributed systems are almost always bound together by the Binder described in §4.3.

Object programs also contain a list of control modules. Many Mesa modules are simply collections of procedures, but some contain mainline code as well. When a program is run, its control modules have their mainline code executed in the order specified when the object program was created. In keeping with the Tajo design principles, most programs either create windows for interaction or register commands with the Executive (or both) and then simply return.

Once a program is loaded, it usually stays around forever (or until the next boot, which may be a week or two away). There is, however, an unloader that goes through the three steps in the reverse order. Thus it is possible to load two highly interconnected modules, decide that one is buggy, unload it, make repairs, load the new one, and have the interconnections now properly made to the new module.

The Mesa compiler is organized into multiple passes. This is partly to simplify dealing with a language that allows forward references, and partly because the initial implementation was on the Alto with a small memory. The first pass is a table driven LALR parser with semantic routines that construct an abstract syntax tree in virtual memory. Later passes decorate the tree, and eventually generate machine code as part of the object file. The code is for a stack architecture [Johnsson82] that is in turn implemented in microcode on the Dandelion. All jump instructions in this architecture are relative to the program counter, so the code requires no relocation by the loader. There is no separate assembler; all levels of the system are written in Mesa.

The unit of compilation is the Mesa MODULE. This is typically a collection of procedure declarations, together with global variable declarations, and sometimes a small amount of mainline code. At the beginning of the source program, there is a declaration of those interfaces that are imported or exported by this module. As mentioned in §4.1, the compiler must produce a header on the object file that provides this import/export information to the loader.

The code and the binding information are all that are really needed for execution of a module. However, additional information is needed to support source-level debugging. The Mesa compiler writes out most of the compile-time symbol table for use by the debugger and performance tools. Unlike some published symbol table structures [Graham79], the Mesa symbol tables are organized in such a way that no information useful to debugging is destroyed in the compilation process.

The compiler also provides a source-to-object mapping facility. The symbol table contains a body table, which contains an entry for each procedure body or BEGIN...END block containing declarations. These entries are linked together into a tree structure showing the nesting relationship of the source program. Each entry in turn is associated with a piece of the fine grain table, a table that tells the program counter value associated with the first instruction of each statement of the source program. The exact representation of this table underwent significant changes in 1981 when allowances were made for the Packager (see §4.5).

What about optimization? In a nutshell, the Mesa compiler doesn't do a lot of optimization that rearranges the order of execution; when it does destroy the ability to do source/object mapping, it tries to arrange things so that the debugger can give the user feedback that this has happened. This is an example of a "90% solution." Being able to set source breakpoints is such a powerful capability, and works such a high portion of the time, that the users are willing to say "darn" in the few cases where it doesn't work, as long as the debugger is capable of determining these cases. (They have been known to say stronger things in the few cases where the debugger can't determine what's going on). The compiler/ debugger collaboration does an admirable job, but new ideas [Zellweger84] would allow it to do an even better one.

The Mesa language contains two classes of modules: PROGRAM and DEFINITIONS. The later class is used for defining interfaces and for sharing type definitions among several PROGRAM modules. When a DEFINITIONS module is compiled, its object file contains no executable code, but contains a symbol table like that produced for debugging a PROGRAM module. These tables are used to implement the included symbol capability of the language. For example, suppose module A obtains type definitions from interface B. When compiling A, the compiler opens the object file for B and copies information from the symbol table therein.

The output of the compiler is an object file containing the code for a single module. For many reasons, interesting programs are made up of more than one module. While the runtime loader is capable of linking together separately loaded modules, most medium to large systems are distributed as a single object file put together by a separate program called the Binder. This is done for several reasons, some more obvious than others.

Our original design (and each subsequent implementation) of the Binder provides complete control of binding, with several ways for the programmer to deal with multiple implementors of interface items. In the intervening six years, we have had very few configuration descriptions other than lists of object file names, which means "bind them together in the only way possible." Almost all of the complicated descriptions could be replaced by suitably staged sequential executions of the Binder on simple configuration descriptions.

Mesa has a full-function source-level debugger that is used for debugging all levels of the system, including the operating system kernel. The debugger uses the symbol table and statement mapping information produced by the compiler. Its features include the following:

One solution to this problem is teledebugging. The debugger's path to the client world is through a rather narrow interface. The routines that read the memory from the world "swapped" on the disk can be replaced with ones that talk to other machines on the Ethernet. Coupled with a small teledebug nub in the client code, these routines give essentially instantaneous turnaround. The client computer need not be geographically nearby, either; an implementor in Palo Alto can debug a program running on a machine in London.

The Pilot operating system supports a demand paged virtual memory. It also allows the programmer to specify swap units so that when a particular page must be swapped in, the operating system makes an effort to bring in its entire swap unit.

When the compiler generates code for a module, it puts the code for the various procedures into a contiguous set of pages in the output file (interspersed with readonly constants). When the program is loaded by the runtime loader, these file pages are mapped into virtual memory. The default swap unit for code is to swap the code for the entire module as a unit.

Procedures are often collected in the same module because they work on the same abstraction, or because they share common private definitions and data. It is often the case that some of the procedures of the module are used only for initialization, or that some procedure in module A is tightly coupled with another procedure in module B. The Packager is a tool that allows the programmer to associate procedures of a collection of modules into explicit swap units. It corresponds very much to the Chinese restaurant stereotype of "one from column A, two from column B."

The packager takes two files as input, one is Binder output, the other a packaging description. A packaging description is a sequence of swap unit descriptions. Each swap unit contains a list of modules and procedures from those modules. This is a considerable simplification, since an explicit list is only one of about nine ways supported for specifying the procedures in a swap unit. For example, one could specify "all procedures of M not already placed in swap units named A and B."

Recall that the source level debugging relies on compiler output tables that give a source/object mapping. These tables, together with the symbol tables take up lots of room; they sometimes account for 80% of the bulk of a compiler output object file. We did not want for the Packager to have to rewrite that information. Considerable care went into the redesign of the source/object mapping tables produced by the compiler to make them independent of the eventual entry point location of the procedures once they have been packaged.

The packager discussed above is the easier half of an important problem, that of reducing working set size; the more difficult half is that of determining what the swap units should be. We have a number of tools in XDE to aid in answering this and other interesting questions. Indeed, a principal conclusion of Knuth's FORTRAN study [Knuth71] was that programmers should have and use more data about the runtime performance of their programs. The set of performance tools includes the following:

The Mesa compiler chooses to paint RECORD types with the 48 bit version stamp of the object file of the module in which they are defined, typically an interface module. Thus if procedures in program modules X and Y both reference a record type from interface A, then X and Y need to be recompiled whenever A is. This leads to compilation dependencies determined by the include relationships of a collection of programs. A tool called the IncludeChecker tries to deal with these problems. Its original goal was to take a collection of modules and determine whether they were consistent with respect to versions of the various interfaces holding them together. It has grown to where it can be pointed at the current version of a program and told to create the sequence of Compiler and Binder command lines necessary to make a new one. It is similar to the UNIXTM program Make [Feldman79], but differs in at least two ways: it only cares about compilation and binding dependencies, and it determines these dependencies automatically from information in the object file.

An earlier, more ambitious, tool worked on the following premise: if, in the example above, the changes to A were in areas unused by X and Y, then they need not be actually recompiled, but merely updated to refer to the new version of A. Such a tool requires some care on the part of the Compiler to leave behind a suitable "audit trail" so that the later tool can determine exactly what was used from a given included module. This tool was not a success, quite possibly because it also tried to deal with the problem of an inadequate disk on the Alto workstation, and had the unfortunate side effect of sometimes deleting the only copy of the software that it was trying to make consistent.

A system like XDE or Star involves a huge number of files, over 5000 for XDE alone. The version stamp system used for insuring consistency makes it critical that a programmer be able to find precisely the right version of each file used. A rather complete discussion of this problem can be found in Lewis's paper on software version control [Lewis83]. This section briefly describes two tools that aid in this process: DFTool and Fetch. It also describes two tools used for more general database applications: Access and Adobe.

Most programmer workstations have limited capacity local disks, typically 40 megabytes. For this reason, programmers spend a lot of time shipping files to and from file servers, where the "truth" resides. A program called DFTool is very helpful in minimizing the number of files that have to be actually transferred. The version for XDE is an outgrowth of Eric Schmidt's thesis work [Schmidt82] as modified by Brian Lewis [Lewis83]. This tool manipulates a collection of text files called DF files, which in turn describe collections of other files. It is best to think of a DF file as a snapshot of a given system or piece of a system. It lists the files that make up the system, complete with creation time and file server "home," and also lists those files that are needed from other DF files in order to recreate the system from the source. There are three major operations provided by DFTool. The operation Bringover retrieves the files from the server if they are not already on the local disk. The operation SModel stores any changed files onto the server and updates the DF file to reflect this. The operation VerifyDF analyzes the programs listed in the DF file and determines that they are consistent, and that all system files necessary for their recompilation are listed in the DF file.

In order to set source breakpoints and examine variables by name, the programmer must have the proper version of the symbolic information on his personal workstation. For the particular tool under development, this is easy, since the pieces were probably compiled there. For the files that are part of the released system, the problem is harder; the organization of the archive directory is designed to aid in the development process, not to simplify retrieval. For example, one might not necessarily think to look for the interface BcdDefs on the subdirectory <Apilot>11.0>Mesa>Friends>. There is a program called Fetch that greatly simplifies this process. As part of the release process, a text file is produced that gives the home of each file in the release, both its subdirectory and its DF file. A fetch service is run on a server machine with a slightly predigested version of this directory file. Individual programmers run Fetch which communicates over the network with the service. To obtain a copy of a file from the release, the programmer simply selects the name of the file and uses a menu to retrieve it (source, object, or both).

In a system with multiple implementors, it is important that no two persons be modifying the same file at once. To protect against this problem, XDE has a program librarian. The librarian runs as an Ethernet service that allows the programmer to check in and out tokens called libjects. One or more files can be associated with a given libject, typically either DF files or Mesa source and object files. The programmer checks out a libject by running a program called Access. A reason for the checkout must be supplied. It is recorded (and optionally logged) in the librarian database. The default operation of Access is to also retrieve the associated file from whatever file server holds it. If the file is already checked out, the programmer is told the current holder's name and reason for having the file. There is a corresponding check in procedure that stores the file back on the server. Some libjects with no associated files are used by other programs for mutual exclusion.

Reasonably early in the lifetime of Mesa it became clear that something had to be done to keep track of bug reports, wishes, tasks, etc. A program called Adobe is the outgrowth of this need. While it started life as a bug-tracking tool, it now is a fairly general database. It is, in fact, a whole family of databases, called Adobe systems, all managed by a collection of tools that together make up Adobe. For a given system, there is a collection of typed fields that make up records. There are provisions for inverting the database on various fields to allow query operations, and user definable templates for generating reports. The records can be individually checked out, or locked for writing. In the case of bug reports, a maintainer will check out the bug report, fix the bug, and then check it back in.

Although each programmer has a rather powerful workstation, XDE is very much a distributed environment. File servers are used for several good reasons: to share information, to gather together consistent snapshots, and to provide a backup in case (shudder) one's local disk crashes irretrievably. While the DFTool is useful for maintaining systems, casual access to remote file servers is done by a tool called the FileTool. Like many XDE tools, FileTool provides two user interfaces. One is a "two dimensional" one with forms to fill in and buttons to push (see Figure 1). The other is a "one dimensional" one that is accessed via the Executive window. This interface parses command lines into commands and parameters. The latter interface is the more useful with command files and batch processing (although most command files for building tools use the executive interface to DFTool instead).

A tool called Chat allows the user to create one or more windows on the screen that act as "glass teletypes" for interaction with other machine. There are options in Chat to emulate most of the popular smart terminals. A particularly useful application of Chat is in conjunction with a program called RemoteExec. This is a version of the Executive that replaces the input and output streams with ones that talk to a remotely connected computer. This allows a number of workstations, typically ones with more memory or larger disks, to be shared by several users. These compute servers can, for example, be used for large batch compilations without slowing down the programmer's personal workstation. Another use of RemoteExec is to allow the programmer to run programs on his personal workstation from any remote terminal, say one at home.

Electronic mail plays a major role in the development process at Xerox. Before programmers would give up their Alto workstations and move to XDE, it was necessary to provide access to mail, based on the Grapevine system [Birrell82]. The Alto based mail reading program was named Laurel, in keeping with PARC's affection for names from the Sunset Western Garden Book. The XDE version was whimsically named Hardy. Like its predecessor, Hardy provides multiple subwindows: a table of contents subwindow with the sender and subject of each message received, a command subwindow with buttons for the various operations, and a text subwindow where the messages are actually read. As the old 3 megabit research network is being phased out of operation, the PUP based Grapevine protocols are being replaced by more modern protocols on the 10 megabit network, and Hardy is being replaced by a similar program named MailTool.

Mesa programmers tend to use rather long identifiers in their programs. The compiler doesn't limit the length, and with proper capitalization, this can help to make programs somewhat self documenting (at least that's one of the excuses I get from programmers that don't use comments in their programs). Also, some of the keywords are long and must be capitalized properly as well. XDE has a built-in abbreviation definition and expansion capability where the programmer can type a unambiguous prefix and hit the Expand key. The recently typed text is scanned backward to pick up a token which, if found in the dictionary, is replaced by the expansion. Hitting Expand with Shift down causes a window to open up where the user can define a new abbreviation.