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 position relative to its parent and a size. Windows at the "top level" are subwindows of a system supplied full-screen root window. Windows can overlap arbitrarily; the rules for visibility of windows are determined by the tree structure.

Each window has an associated window object which is accessed by a pointer called a window handle. The object contains information about the tree structure, this window's relative location, and procedure variables, such as a repaint procedure that is called whenever a portion of the window has invalid contents. Mesa's opaque type mechanism is used so client programs need not know the actual representation of a window 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.4 for further details.

To simplify the task of the tool writer, there are several system-provided subwindow types, each with its own runtime management routines. 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. Tools that will not be needed for a while can be shrunk to an iconic form on the screen; such tiny window typically retain all window state, such as parameters that the user has given the tool, options selected, or messages posted by the program. The third state for tools is inactive. When tools are inactive, they disappear from the screen entirely. By convention, they free up any system resources that they are using.

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

Two mouse buttons are used for selection. The left button, called point, is used to begin the selection. When point is depressed, the closest character is selected (video inverted), and the selection tracks the mouse until the button is released. Units larger than a single character are selected by multiple clicking. If the left button is pressed twice in rapid succession, the selection mode becomes word-selection. Three clicks get lines, and four clicks selects the entire document. Multiple clicks cycle through the selection modes, so a 5-click is equivalent to a single click.

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.

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 underline and box-around.

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, user editable descriptions of desired operations for specified user actions. These tables are associated with windows in a tree structure. Every time a user action (key transition, button transition, or mouse movement) occurs, the TIP software determines which window that event "is for" and looks up the event in the chain of tables associated with that window. If it finds the event, it passes the corresponding operations to that window's associated notify procedure.

Another means for user interaction is via menus. Rather than have a single large menu, there are several menus available at any time, determined by the subwindow that contains the cursor. System supplied subwindow types have their own sets of menus, such as a text operations menu for a typescript subwindow. The set of available menus is obtained by depressing the middle mouse button. Menus are stacked in such a way that the user can either invoke a menu item from the top menu or cause another menu to come on top.

From the programmer's standpoint, menus are easy to construct. A system procedure 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.

Menus can provide many commands without requiring the user to remember the exact command names. 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, typically command names. When the user clicks the mouse button on one of these identifiers, the symbiote's notify procedure 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 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, as described in detail elsewhere [12] [10]. 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.

When run, 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 is it 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 generates code for a stack architecture [4] that is emulated in microcode on the Dandelion. There is no separate assembler; all portions of the system, down to the 512 byte bootstrap loader, 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 compiler writes out most of the compile-time symbol table for use by the debugger and performance tools. Unlike some symbol table structures [3], 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 used by the debugger and various performance measuring tools.

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

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:

The input to the binder is a configuration description that contains a list of object file names, a list of interfaces to be imported and exported, and optional information directing how the internal bindings are to be done. Experience has shown that elaborate schemes for programmer directed binding are almost never used.

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:

The Mesa debugger evolved from the Alto implementation and still uses the world swap principle [8] for insulating the debugger from the client code. As the size of physical memory has grown, the time necessary for the disk transfer has become annoyingly long; one solution to this problem is teledebugging. 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. The debugee 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, an effort is made 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 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 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 discussed above is the easier half of an important problem, that of reducing working set size; the more difficult half is to determine what the swap units should be. We have a number of tools in XDE to aid in answering this and other interesting questions. Indeed, the principal conclusion of Knuth's FORTRAN study [7] was that programmers should have and use more data about the runtime performance of their programs. The set of performance tools includes the following:

These tools use the source-level debugging information produced by the compiler to present their results in the most usable format. The Spy is an interesting example. One can first see in which modules a program is spending its time. Then for a set of modules, one can get statistics about the most time-consuming procedures. Finally, statistics can be collected at the statement level. Since the Spy works on a sampling principle, it is sometimes useful to switch to the PerfPackage to obtain exact statistics at the statement level.

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 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 [1], 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.

Other tools have been built to approach this problem, with varying degrees of success.