Rob Pike

The use of name spaces in Plan 9

Plan 9 is a distributed system built at the Computing Sciences Research Center of AT&T Bell Laboratories over the last few years. Its goal is to provide a production-quality system for software development and general computation using heterogeneous hardware and minimal software. A Plan 9 system comprises CPU and file servers in a central location connected together by fast networks. Slower networks fan out to workstation-class machines that serve as user terminals. Plan 9 argues that given a few carefully implemented abstractions it is possible to produce a small operating system that provides support for the largest systems on a variety of architectures and networks. The foundations of the system are built on two ideas: a per-process name space and a simple message-oriented file system protocol.

Squeak: a language for communicating with mice

Graphical user interfaces are difficult to implement because of the essential concurrency among multiple interaction devices, such as mice, buttons, and keyboards. Squeak is a user interface implementation language that exploits this concurrency rather than hiding it, helping the programmer to express interactions using multiple devices. We present the motivation, design and semantics of squeak. The language is based on concurrent programming constructs but can be compiled into a conventional sequential language; our implementation generates C code. We discuss how squeak programs can be integrated into a graphics system written in a conventional language to implement large but regular user interfaces, and close with a description of the formal semantics.

The text editor sam

Sam is an interactive multi‐file text editor intended for bitmap displays. A textual command language supplements the mouse‐driven, cut‐and‐paste interface to make complex or repetitive editing tasks easy to specify. The language is characterized by the composition of regular expressions to describe the structure of the text being modified. The treatment of files as a database, with changes logged as atomic transactions, guides the implementation and makes a general ‘undo’ mechanism straightforward.

Hardware/software trade-offs for bitmap graphics on the Blit

The Blit is an experimental bitmap graphics terminal built for research into interactive computer graphics on the UNIX time‐sharing system. The hardware is inexpensive and the graphics functions are implemented entirely in software. Nevertheless, the graphics performance of the Blit is comparable or superior to some displays with special‐purpose graphics hardware. This paper explains the paradox by referring to some principles of design: the hardware and software should be designed together to complement each other; carefully designed software can outperform infelicitous hardware; and simplicity of design leads to efficiency of execution. These principles are illustrated by examples from the Blit hardware and software and comparisons with other systems.

Protium, an infrastructure for partitioned applications

Remote access feels different from local access. The major issues are consistency (machines vary in GUIs, applications, and devices) and responsiveness (the user must wait for network and server delays), Protium attacks these by partitioning programs into local viewers that connect to remote services using application-specific protocols. Partitioning allows viewers to be customized to adapt to local features and limitations. Services are responsible for maintaining long-term state. Viewers manage the user interface and use state to reduce communication between viewer and service, reducing latency whenever possible. System infrastructure sits between the viewer and service, supporting replication, consistency, session management, and multiple simultaneous viewers. The prototype system includes an editor, a draw program, a PDF viewer, a map database, a music jukebox, and windowing system support. It runs on servers, workstations, PCs, and PDAs under Plan 9, Linux, and Windows; services and viewers have been written in C, Java, and Concurrent ML.

The implementation of newsqueak

The implementation of the concurrent applicative language Newsqueak has several unusual features. The interpreter, squint, uses a copy‐on‐write scheme to manage storage honouring Newsqueaks strictly applicative (by‐value) semantics for data. There is no explicit scheduler. Instead, the execution of processes is interleaved very finely, but randomly, by an efficient scheme that integrates process switching into the interpreters main loop. The implementation of select, the non‐deterministic, multi‐way communications operator, exploits details in the implementation of processes. This paper describes much of the interpreter but explains only small aspects of the language. Further detail about the language may be found in the References.

A library for incremental update of bitmap images

To achieve the maximum performance from bitrnap displays, the screen must be used not just as an output device, but as a data structure that may cache computed images. In an interactive text or picture editor, that may mean converting the internal representation of whats being edited into a set of rectangles that tile the screen. Incremental updates of the image may then be done by rearranging some subset of the filing using bitmap operations, independently of how the tiling was derived. We have taken t_he ideas used in the screen update algorithms for the sam text editor and generalized them so they may be applied to more structured documents than the simple character stream sam edits. The ideas have been tested by building a library and a simple interactive document editor that treat a document as a hierarchical structure that may include text, pictures, and variable spacing. The core of the library is operators to make incremental changes to the display while maintaining the hierarchical data structure that describes it.

Graphics in overlapping bitmap layers

One of the common uses of bitmap terminals is storing multiple programming contexts in multiple, possibly overlapping, areas of the screen called windows. Windows traditionally store the visible state of a programming environment, such as an editor or debugger, while the user works with some other program. This model of interaction is attractive for one-process systems, but to make full use of a multiprogramming environment, windows must be asynchronously updated, even when partially or wholly obscured by other windows. For example, a long compilation may run in one window, displaying messages as appropriate, while the user edits a file in another window. This paper describes a set of low-level graphics primitives to manipulate overlapping asynchronous windows, called layers, on a bitmap display terminal. Unlike previous window software, these primitives extend the domain of the general bitmap operator bitblt to include bitmaps that are partially or wholly obscured.