Software Preservation Group of the Computer History Museum
Paul McJones, editor
paul@mcjones.org
https://mcjones.org/dustydecks/
Last modified 30 November 2025
The goal of this project is to preserve and present source materials (including specifications, source code, manuals, and papers discussing design and implementation) for the Modula-2+ language designed at the Systems Research Center of Digital Equipment Corporation.
In 1984 Robert W. Taylor left his position at the Xerox Palo Alto Research Center, and founded the Systems Research Center (SRC) at Digital Equipment Corporation (DEC), with a charter to develop "software and hardware to provide a powerful base for work in programming systems, distributed systems and personal workstations." Many of the researchers who followed Taylor to SRC had worked on the Cedar system, which was written in the Cedar variant of the Mesa programming language and which ran on the Dorado personal workstation. (See Software Preservation > Mesa.)
At SRC, they needed to start over with a new programming environment. A VAX 780 running DEC's Ultrix operating system was acquired. Chuck Thacker led the design of a shared-memory multiprocessor using MicroVAX II CPU chips. [Thacker1987a, 1987b, 1988] The language Modula-2, designed by Niklaus Wirth, was identified as having many of the features they desired: Rovner1985, 1986] (Modula-2, in turn had been influenced by Wirth's experience with Mesa during a 1976n sabbatical at PARC. [Wirth1980])
However based on experience with Mesa and Cedar Mesa at PARC, it was felt necessary to extend Modula-2 in several areas:
The language was designed by Paul Rovner with large contributions by Andrew Birrell, Butler Lampson, and Roy Levin and suggestions by others at SRC.
"It may not be fast, but it has a lot of torque."
Mike Powell at the DEC Western Research Laboratory wrote a Modula-2 compiler for the VAX and later the MIPS R3000. [Powell1984], [McCormack1992]
Paul Rovner, with help from others at SRC, adapted Powell's compiler to handle the full Modula-2+ language. [vanLeunen1986], [Rovner1985, 1986], [ DeTreville1990a, b].
The Modula-2+ programming environment, with the compiler, a set of libraries, and a set of applications, was called Topaz. There were two versions of Topaz: one ran under the Ultrix operating system on DEC VAX computers, and the other ran on the Taos operating system on SRC's own Firefly multiprocessor workstations.
A second clean-slate Modula-2+ compiler was designed by John Ellis as part of the Vulcan project to provide fast turnaround for large systems. [Ellis1987], [Ayers1987], [Ellis1990a,b,c], [DeTreville1991]
Support for true concurrency in a programming language was not common in 1985. Cedar Mesa had provided preemptively-scheduled threads based on a design originally incorporated in Mesa. [Lampson1980] The Modula-2+ Threads interface had similar semantics, but supported true concurrency on the Firefly shared-memory multiprocessor workstation. [Birrell1987, 1989]
Although both trace-and-sweep and reference-counting garbage collection algorithms were used list-processing systems by 1960, [McCarthy1960], [Collins1960] designing efficient algorithms for a language with the combined features Modula-2+ was still a challenge in 1985. The initial Modula-2+ garbage collector used reference-counting and was based on the algorithm used in Cedar Mesa at Xerox PARC. John DeTreville conducted experiments with a series of algorithms, finally settling on a combination of reference-counting with an occasional mark-and-sweep to handle cyclic structures. [DeTreville1990b]
"A pickle is an external copy of a heap structure. Heap structures can be pickled into a bytestream and the bytestream can be unpickled back in to a copy of the original structure Pickles are fast to write and very fast to read. Pickles can therefore serve as a standard structure for longterm data storage. For example window system fonts are stored as pickles. A font is represented as a REF to the font information and the pickles are stored in files. On startup programs may read these pickles to define fonts." [DeTreville1990a]
- - -
"Our implementation makes use of a mechanism called 'pickles', which will convert between any strongly typed data structure and a representation of that structure suitable for storing in permanent disk files. The operation Pickle.Write takes a pointer to a strongly typed data structure and delivers buffers of bits for writing to the disk. Conversely Pickle.Read reads buffers of bits from the disk and delivers a copy of the original data structure.* This conversion involves identifying the occurrences of addresses in the structure, and arranging that when the structure is read back from disk the addresses are replaced with addresses valid in the current execution environment. The pickle mechanism is entirely automatic: it is driven by the run-time typing structures that are present for our garbage collection mechanism.
* Pickling is quite similar to the concept of marshalling in remote procedure calls. But in fact our pickling implementation works only by interpreting at run-time the structure of dynamically typed values, while our RPC implementation works only by generating code for the marshalling of statically typed values. Each facility would benefit from adding the mechanisms of the other, but that has not yet been done." [Birrell1987b]
The Loupe debugger was written for the original implementation of Modula-2+; it was later rewritten for the Vulcan version. [DeTreville1991]
Taos (named forTopAz Operating System) ran on Firefly multiprocessor workstations. It was microkernel-based. The microkernel was called the Nub, and provided address spaces, threads, and device drivers. The rest of the operating system—Unix emulation and file system—ran in a user address space. Unix emulation allowed programs compiled for DEC Ultrix (essentially BSD 4.2) to run normally. In addition, it supported multi-threaded Topaz programs, which used RPC to cross address space and machine boundaries. These Topaz programs obtained their system services via the Modula-2+ interface OS, which was implemented as a thin veneer over a set of RPC calls on the main operating system address space.
See [McJones1987, 1989a] for the OS interface. See [McJones1989b] for the principles used in designing this interface.
An older version appeared as part II of [McJones1987].
Slightly edited version of part I of [McJones1987].
"Echo is an ambitious distributed file system. It was designed around a truly global name space. It uses a coherent caching algorithm. It is fault tolerant. And it is real—it was the primary file system for a large group of researchers. Its novel aspects include an extensible 'junction' mechanism for global naming; extensive write-behind with ordering semantics that allow applications to maintain invariants without resorting to synchronous writes; and fault tolerance mechanisms that are highly configurable and that tolerate network partitions. It was designed with the intention that its performance could be as good as a local file system, while supporting large numbers of clients per server. Its reliability was designed to be higher than other distributed file systems, and higher than centralized systems. It was designed to work well in arbitrarily large networks." [Birrell1993]
For the later Modula-3 version, see [Manasse1991] and [Manasse1992] in Software Preservation > Modula-3.
The dialog editor was a direct-manipulation user interface editor. Client programs interacted with the user interface via abstract protocols, e.g., an event might be triggered by a button push or menu command. The system came with a large set of interactors, but was open-ended, allowing new interactors to be added.
"Tinylisp is a language intended for 'programming-in-the-small' in SRC's Modula-2+ environment. It is a lexically scoped Lisp implemented as a package that can be bound into any Modula-2+ application, providing that application with instant programmability. The Ivy text editor uses Tinylisp to implement its predefined commands and to allow users to write their own commands; future applications may include a shell based on 'vbtkit' dialogs.
The Tinylisp language itself is a small, modern Lisp that provides a fairly rich set of traditional control and data structures (including threads), with two-level naming based on modules. All the basic Modula-2+ packages are directly accessible from Tinylisp, including Text, List, Table, Thread, FileStream, Rd, Wr, OS, Time, Math, and RegExpr.
Tinylisp can directly manipulate integers, characters, booleans, longreals, and any opaque-ref types provided by the particular application, and Tinylisp can call procedures that traffic in these types. Using compile_tli a stub generator similar to RPC's flume, application implementers define which of the application's procedures and datatypes will be accessible from Tinylisp. It is the responsibility of the application implementer to define Modula-2+ interfaces that are suitable for programming-in-the-small."
[Ellis1989] in Software Preservation > LISP
The Siphon facilitates joint software development between groups working at distant sites connected by low bandwidth communication lines. It gives users the image of a single repository of individually manageable units, typically software or documentation components. Users can lock and modify each unit, the result being propagated automatically to all sites. The repository is replicated at each site, and possibly on multiple file servers for greater availability and reliability. It used RPC for communication. See Siphon in Software Preservation > Modula-3 for a later version.
Ivy was an extensible text editor written in Modula-2+ that allowed extensions to be written in Tinylisp. In addition to text windows, it supported terminal windows with unbounded persistent typescripts.
Vesta was a software configuration and release management system. It provided a novel
repository and system builder that emphasized complete yet manageable descriptions of software components.
The goals of this project were: [Ellis1987]
Vulcan was structured as a Vesta bridge. [Ellis1990b], [Brown1993]
The original version of Zeus was written in Modula-2+. For the similar Modula-3 version, see [Brown1992a, Brown1992b] in Software Preservation > Modula-3.
*** TO DO: Ask people for additional recollections, e.g., Marc H. Brown, Mark R. Brown, Mike Burrows, Luca Cardelli, John DeTreville, John Ellis, Roy Levin, Bill Kalsow, Mark Manasse, Paul Rovner, Mike Schroeder, Ted Wobber ...