P. 1
8½.pdf

8½.pdf

|Views: 1|Likes:
Published by florian59

More info:

Published by: florian59 on Mar 05, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/14/2014

pdf

text

original

8Z, the Plan 9 Window System

Rob F¡ke
rob@pInn9.beII-Inbs.con
Aß5TRACT
The PIan 9 wIndow system, 8l, Is a modest-sIzed program oI noveI
desIgn. Ìt provIdes textuaI Ì]O and bItmap graphIc servIces to both IocaI
and remote cIIent programs by oIIerIng a muItIpIexed IIIe servIce to those
cIIents. Ìt serves tradItIonaI UNÌX IIIes IIke /de\/11y as weII as more
unusuaI ones that provIde access to the mouse and the raw screen. 8It·
map graphIcs operatIons are provIded by servIng a IIIe caIIed
/de\/Ia1IJ1 that Interprets cIIent messages to perIorm raster opera·
tIons. The IIIe servIce that 8l oIIers Its cIIents Is IdentIcaI to that It uses
Ior Its own ImpIementatIon, so It Is IundamentaIIy no more than a muItI·
pIexer. ThIs archItecture has some rewardIng symmetrIes and can be
ImpIemented compactIy.
lntroduction
Ìn 1989 Ì constructed a toy wIndow system Irom onIy a Iew hundred IInes oI source
code usIng a custom Ianguage and an unusuaI archItecture InvoIvIng concurrent pro·
cesses [PIke89]. AIthough that system was rudImentary at best, It demonstrated that
wIndow systems are not InherentIy compIIcated. The IoIIowIng year, Ior the new PIan 9
dIstrIbuted system [PIke92], Ì appIIed some oI the Iessons Irom that toy project to wrIte,
In C, a productIon-quaIIty wIndow system caIIed 8l. 8l provIdes, on bIack-and-whIte,
grey-scaIe, or coIor dIspIays, the servIces requIred oI a modern wIndow system, IncIud·
Ing programmabIIIty and support Ior remote graphIcs. The entIre system, IncIudIng the
deIauIt program that runs In the wIndow ߞ the equIvaIent oI x1eim [Far89] wIth ߢcut·
tIng and pastIngߣ between wIndows ߞ Is weII under 90 kIIobytes oI text on a MotoroIa
68020 processor, about haII the sIze oI the operatIng system kerneI that supports It and
a tenth the sIze oI the X server [Sche86] w¡IhouI x1eim.
What makes 8l so compactZ Much oI the savIng comes Irom overaII sImpIIcIty: 8l
has IIttIe graphIcaI IancIness, a concIse programmIng InterIace, and a sImpIe, IIxed user
InterIace. 8l aIso makes some decIsIons by IIat ߞ three-button mouse, overIappIng
wIndows, buIIt-In termInaI program and wIndow manager, etc. ߞ rather than tryIng to
appeaI to aII tastes. AIthough compact, 8l Is not ascetIc. Ìt provIdes the IundamentaIs
and enough extras to make them comIortabIe to use. The most Important contrIbutor
to Its smaII sIze, though, Is Its overaII desIgn as a IIIe server. ThIs structure may be
appIIcabIe to wIndow systems on tradItIonaI UNÌX-IIke operatIng systems.
The smaII sIze oI 8l does not reIIect reduced IunctIonaIIty: 8l provIdes servIce
roughIy equIvaIent to the X wIndow system. 8lߣs cIIents may oI course be as compIex
as they choose, aIthough the tendency to mImIc 8lߣs desIgn and the cIean programmIng
InterIace means they are not nearIy as bIoated as X appIIcatIons.
__________________
OrIgInaIIy appeared, In a sIIghtIy dIIIerent Iorm, In Froc. oj Ihe 5unner 1991 U5£NIX Conj., pp.
2S7-26S, NashvIIIe. Note that S½ has been repIaced by iaO (see r¡o(1)).
· 2 ·
User's Model
8l turns the sIngIe screen, mouse, and keyboard oI the termInaI (In PIan 9 termI·
noIogy) or workstatIon (In commercIaI termInoIogy) Into an array oI Independent vIrtuaI
termInaIs that may be textuaI termInaIs supportIng a sheII and the usuaI suIte oI tooIs or
graphIcaI appIIcatIons usIng the IuII power oI the bItmap screen and mouse. Text Is
represented In UTF, an encodIng oI the UnIcode Standard [PIke93]. The entIre program·
mIng InterIace Is provIded through readIng and wrItIng IIIes In /de\.
PrImarIIy Ior reasons oI hIstory and IamIIIarIty, the generaI modeI and appearance
oI 8l are sImIIar to those oI mux [PIke88]. The rIght button has a short menu Ior con·
troIIIng wIndow creatIon, destructIon, and pIacement. When a wIndow Is created, It runs
the deIauIt sheII, ic [DuII90], wIth standard Input and output dIrected to the wIndow
and accessIbIe through the IIIe /de\/cOnS (ߢconsoIeߣ), anaIogous to the /de\/11y
oI UNÌX. The name change represents a break wIth the past: PIan 9 does not provIde a
TeIetype-styIe modeI oI termInaIs. 8l provIdes the onIy way most users ever access
PIan 9.
CraphIcaI appIIcatIons, IIke ordInary programs, may be run by typIng theIr names
to the sheII runnIng In a wIndow. ThIs runs the appIIcatIon In the same wIndow; to run
the appIIcatIon In a new wIndow one may use an externaI program, wandOw, descrIbed
beIow. For graphIcaI appIIcatIons, the vIrtuaI termInaI modeI Is extended somewhat to
aIIow programs to perIorm graphIcaI operatIons, access the mouse, and perIorm reIated
IunctIons by readIng and wrItIng IIIes wIth suggestIve names such as /de\/mOuSe and
/de\/wandOw muItIpIexed per-wIndow much IIke /de\/cOnS. The ImpIementatIon
and semantIcs oI these IIIes, descrIbed beIow, Is centraI to the structure oI 8l.
The deIauIt program that runs In a wIndow Is IamIIIar to users oI 8IIt termInaIs
[PIke83]. Ìt Is very sImIIar to that oI mux [PIke88], provIdIng mouse-based edItIng oI
Input and output text, the abIIIty to scroII back to see earIIer output, and so on. Ìt aIso
has a new Ieature, toggIed by typIng ESC, that enabIes the user to controI when typed
characters may be read by the sheII or appIIcatIon, Instead oI (Ior exampIe) aIter each
newIIne. ThIs Ieature makes the wIndow program dIrectIy useIuI Ior many text-edItIng
tasks such as composIng maII messages beIore sendIng them.
Plan 9 and 8Z
PIan 9 Is a dIstrIbuted system that provIdes support Ior UNÌX-IIke appIIcatIons In an
envIronment buIIt Irom dIstInct CPU servers, IIIe servers, and termInaIs connected by a
varIety oI networks [PIke90]. The termInaIs are comparabIe to modest workstatIons
that, once connected to a IIIe server over a medIum-bandwIdth network such as Ether·
net, are seII-suIIIcIent computers runnIng a IuII operatIng system. UnIIke workstatIons,
however, theIr roIe Is just to provIde an aIIordabIe muItIpIexed user InterIace to the rest
oI the system: they run the wIndow system and support sImpIe InteractIve tasks such as
text edItIng. Thus they IIe somewhere between workstatIons and X termInaIs In desIgn,
cost, perIormance, and IunctIon. (The termInaIs can be used Ior generaI computIng, but
In practIce PIan 9 users do theIr computIng on the CPU servers.) The PIan 9 termInaI
soItware, IncIudIng 8l, was deveIoped on a 68020-based machIne caIIed a Cnot and
has been ported to the NeXTstatIon, the MÌPS Magnum 3000, SCÌ ÌndIgos, and Sun
SPARCstatIonsߞaII smaII workstatIons that we use as termInaIsߞas weII as PCs.
Heavy computatIons such as compIIatIon, text processIng, or scIentIIIc caIcuIatIon
are done on the CPU servers, whIch are connected to the IIIe servers by hIgh-bandwIdth
networks. For InteractIve work, these computatIons can access the termInaI that Instan·
tIated them. The termInaI and CPU server beIng used by a partIcuIar user are connected
to the same IIIe server, aIthough over dIIIerent networks; PIan 9 provIdes a vIew oI the
IIIe server that Is Independent oI IocatIon In the network.
The components oI PIan 9 are connected by a common protocoI based on the
· 3 ·
sharIng oI IIIes. AII resources In the network are ImpIemented as IIIe servers; programs
that wIsh to access them connect to them over the network and communIcate usIng
ordInary IIIe operatIons. An unusuaI aspect oI PIan 9 Is that the nnne spnce oI a
process, the set oI IIIes that can be accessed by name (Ior exampIe by an Open system
caII) Is not gIobaI to aII processes on a machIne; dIstInct processes may have dIstInct
name spaces. The system provIdes methods by whIch processes may change theIr name
spaces, such as the abIIIty to nounI a servIce upon an exIstIng dIrectory, makIng the
IIIes oI the servIce vIsIbIe In the dIrectory. (ThIs Is a dIIIerent operatIon Irom Its UNÌX
namesake.) MuItIpIe servIces may be mounted upon the same dIrectory, aIIowIng the
IIIes Irom muItIpIe servIces to be accessed In the same dIrectory. OptIons to the mOun1
system caII controI the order oI searchIng Ior IIIes In such a un¡on d¡recIory.
The most obvIous exampIe oI a network resource Is a IIIe server, where permanent
IIIes resIde. There are a number oI unusuaI servIces, however, whose desIgn In a dIIIer·
ent envIronment wouId IIkeIy not be IIIe-based. Many are descrIbed eIsewhere [PIke92];
some exampIes are the representatIon oI processes Ior debuggIng, much IIke KIIIIanߣs
process IIIes Ior the 8th edItIon [KIII84], and the ImpIementatIon oI the name]vaIue
paIrs oI the UNÌX exec envIronment as IIIes. User processes may aIso ImpIement a IIIe
servIce and make It avaIIabIe to cIIents In the network, much IIke the ߢmounted streamsߣ
In the 9th EdItIon [Pres90]. A typIcaI exampIe Is a program that Interprets an
externaIIy-deIIned IIIe system such as that on a CD-ROM or a standard UNÌX system and
makes the contents avaIIabIe to PIan 9 programs. ThIs desIgn Is used by aII dIstrIbuted
appIIcatIons In PIan 9, IncIudIng 8l.
8l serves a set oI IIIes In the conventIonaI dIrectory /de\ wIth names IIke cOnS,
mOuSe, and Scieen. CIIents oI 8l communIcate wIth the wIndow system by readIng
and wrItIng these IIIes. For exampIe, a cIIent program, such as a sheII, can prInt text by
wrItIng Its standard output, whIch Is automatIcaIIy connected to /de\/cOnS, or It may
open and wrIte that IIIe expIIcItIy. UnIIke IIIes served by a tradItIonaI IIIe server, how·
ever, the Instance oI /de\/cOnS served In each wIndow by 8l Is a dIstInct IIIe; the
per-process name spaces oI PIan 9 aIIow 8l to provIde a unIque /de\/cOnS to each
cIIent. ThIs mechanIsm Is best IIIustrated by the creatIon oI a new 8l cIIent.
When 8l starts, It creates a IuII-dupIex pIpe to be the communIcatIon medIum Ior
the messages that ImpIement the IIIe servIce It wIII provIde. One end wIII be shared by
aII the cIIents; the other end Is heId by 8l to accept requests Ior Ì]O. When a user
makes a new wIndow usIng the mouse, 8l aIIocates the wIndow data structures and
Iorks a chIId process. The chIIdߣs name space, InItIaIIy shared wIth the parent, Is then
dupIIcated so that changes the chIId makes to Its name space wIII not aIIect the parent.
The chIId then attaches Its end oI the communIcatIon pIpe, c1d, to the dIrectory /de\
by doIng a mOun1 system caII:
mOun1{c1d, '/de\', NI£IΧR£, Iu1¸
ThIs caII attaches the servIce assocIated wIth the IIIe descrIptor c1d ߞ the cIIent end oI
the pIpe ߞ to the begInnIng oI /de\ so that the IIIes In the new servIce take prIorIty
over exIstIng IIIes In the dIrectory. ThIs makes the new IIIes cOnS, mOuSe, and so on,
avaIIabIe In /de\ In a way that hIdes any IIIes wIth the same names aIready In pIace.
The argument Iu1 Is a character strIng (nuII In thIs case), descrIbed beIow.
The cIIent process then cIoses IIIe descrIptors 0, 1, and 2 and opens /de\/cOnS
repeatedIy to connect the standard Input, output, and error IIIes to the wIndowߣs
/de\/cOnS. Ìt then does an exec system caII to begIn executIng the sheII In the wIn·
dow. ThIs entIre sequence, compIete wIth error handIIng, Is 33 IInes oI C.
The vIew oI these events Irom 8lߣs end oI the pIpe Is a sequence oI IIIe protocoI
messages Irom the new cIIent generated by the IntervenIng operatIng system In
response to the mOun1 and Open system caIIs executed by the cIIent. The message
generated by the mOun1 InIorms 8l that a new cIIent has attached to the IIIe servIce It
· 4 ·
provIdes; 8lߣs response Is a unIque IdentIIIer kept by the operatIng system and passed
In aII messages generated by Ì]O on the IIIes derIved Irom that mOun1. ThIs IdentIIIer
Is used by 8l to dIstInguIsh the varIous cIIents so each sees a unIque /de\/cOnS;
most servers do not need to make thIs dIstInctIon.
A process unreIated to 8l may create wIndows by a varIant oI thIs mechanIsm.
When 8l begIns, It uses a PIan 9 servIce to ߢpostߣ the cIIent end oI the communIcatIon
pIpe In a pubIIc pIace. A process may open that pIpe and mOun1 It to attach to the wIn·
dow system, much In the way an X cIIent may connect to a UNÌX domaIn socket to the
server bound to the IIIe system. The IInaI argument to mOun1 Is passed through unIn·
terpreted by the operatIng system. Ìt provIdes a way Ior the cIIent and server to
exchange InIormatIon at the tIme oI the mOun1. 8l Interprets It as the dImensIons oI
the wIndow to be created Ior the new cIIent. (Ìn the case above, the wIndow has been
created by the tIme the mount occurs, and Iu1 carrIes no InIormatIon.) When the
mOun1 returns, the process can open the IIIes oI the new wIndow and begIn Ì]O to use
It.
8ecause 8lߣs InterIace Is based on IIIes, standard system utIIItIes can be used to
controI Its servIces. For exampIe, Its method oI creatIng wIndows externaIIy Is packaged
In a 16-IIne sheII scrIpt, caIIed wandOw, the core oI whIch Is just a mOun1 operatIon
that preIIxes 8lߣs dIrectory to /de\ and runs a command passed on the argument IIne:
mOun1 -I S`S½Sei\` /de\
S* < /de\/cOnS > /de\/cOnS >j2¸ /de\/cOnS &
The wandOw program Is typIcaIIy empIoyed by users to create theIr InItIaI workIng envI·
ronment when they boot the system, aIthough It has more generaI possIbIIItIes.
Other basIc Ieatures oI the system IaII out naturaIIy Irom the IIIe-based modeI.
When the user deIetes a wIndow, 8l sends the equIvaIent oI a UNÌX sIgnaI to the pro·
cess group ߞ the cIIents ߞ In the wIndow, removes the wIndow Irom the screen, and
poIsons the IncomIng connectIons to the IIIes that drIve It. ÌI a cIIent Ignores the sIgnaI
and contInues to wrIte to the wIndow, It wIII get Ì]O errors. ÌI, on the other hand, aII the
processes In a wIndow exIt spontaneousIy, they wIII automatIcaIIy cIose aII connectIons
to the wIndow. 8l counts reIerences to the wIndowߣs IIIes; when none are IeIt, It shuts
down the wIndow and removes It Irom the screen. As a dIIIerent exampIe, when the
user hIts the DEL key to generate an Interrupt, 8l wrItes a message to a specIaI IIIe, pro·
vIded by PIan 9ߣs process controI InterIace, that Interrupts aII the processes In the wIn·
dow. Ìn aII these exampIes, the ImpIementatIon works seamIessIy across a network.
There are two vaIuabIe sIde eIIects oI ImpIementIng a wIndow system by muItIpIex·
Ing /de\/cOnS and other such IIIes. FIrst, the probIem oI gIvIng a meanIngIuI Inter·
pretatIon to the IIIe /de\/cOnS (/de\/11y) In each wIndow Is soIved automatIcaIIy.
To provIde /de\/cOnS Is the IundamentaI job oI the wIndow system, rather than just
an awkward burden; other systems must oIten make specIaI and otherwIse IrreIevant
arrangements Ior /de\/11y to behave as expected In a wIndow. Second, any program
that can access the server, IncIudIng a process on a remote machIne, can access the IIIes
usIng standard read and wrIte system caIIs to communIcate wIth the wIndow system,
and standard open and cIose caIIs to connect to It. AgaIn, no specIaI arrangements need
to be made Ior remote processes to use aII the graphIcs IacIIItIes oI 8l.
Craphical input
OI course 8l oIIers more than ASCÌÌ Ì]O to Its cIIents. The state oI the mouse may
be dIscovered by readIng the IIIe /de\/mOuSe, whIch returns a ten-byte message
encodIng the state oI the buttons and the posItIon oI the cursor. ÌI the mouse has not
moved sInce the Iast read oI /de\/mOuSe, or II the wIndow assocIated wIth the
Instance oI /de\/mOuSe Is not the ߢInput Iocusߣ, the read bIocks.
The Iormat oI the message Is:
· S ·
`m`
1 byte oI button state
4 bytes oI x, Iow byte IIrst
4 bytes oI y, Iow byte IIrst
As In aII shared data structures In PIan 9, the order oI every byte In the message Is
deIIned so aII cIIents can execute the same code to unpack the message Into a IocaI data
structure.
For keyboard Input, cIIents can read /de\/cOnS or, II they need character-at-a-
tIme Input, /de\/icOnS (ߢraw consoIeߣ). There Is no expIIcIt event mechanIsm to heIp
cIIents that need to read Irom muItIpIe sources. Ìnstead, a smaII (36S IIne) externaI sup·
port IIbrary can be used. Ìt attaches a process to the varIous bIockIng Input sources ߞ
mouse, keyboard, and perhaps a thIrd user-provIded IIIe descrIptor ߞ and IunneIs theIr
Input Into a sIngIe pIpe Irom whIch may be read the varIous types oI events In the tradI·
tIonaI styIe. ThIs package Is a compromIse. As dIscussed In a prevIous paper [PIke89] Ì
preIer to Iree appIIcatIons Irom event-based programmIng. UnIortunateIy, though, Ì see
no easy way to achIeve thIs In sIngIe-threaded C programs, and am unwIIIIng to requIre
aII programmers to master concurrent programmIng. Ìt shouId be noted, though, that
even thIs compromIse resuIts In a smaII and easIIy understood InterIace. An exampIe
program that uses It Is gIven near the end oI the paper.
Craphical output
The IIIe /de\/Scieen may be read by any cIIent to recover the contents oI the
entIre screen, such as Ior prIntIng (see FIgure 1). SImIIarIy, /de\/wandOw hoIds the
contents oI the current wIndow. These are read-onIy IIIes.
To perIorm graphIcs operatIons In theIr wIndows, cIIent programs access
/de\/Ia1IJ1. Ìt ImpIements a protocoI that encodes bItmap graphIcs operatIons.
Most oI the messages In the protocoI (there are 23 messages In aII, about haII to man·
age the muItI-IeveI Ionts necessary Ior eIIIcIent handIIng oI UnIcode characters) are
transmIssIons (vIa a wrIte) Irom the cIIent to the wIndow system to perIorm a graphIcaI
operatIon such as a Ia1IJ1 [PLR8S] or character-drawIng operatIon; a Iew IncIude
return InIormatIon (recovered vIa a read) to the cIIent. As wIth /de\/mOuSe, the
/de\/Ia1IJ1 protocoI Is In a deIIned byte order. Here, Ior exampIe, Is the Iayout oI
the Ia1IJ1 message:
`I`
2 bytes oI destInatIon Id
2x4 bytes oI destInatIon poInt
2 bytes oI source Id
4x4 bytes oI source rectangIe
2 bytes oI booIean IunctIon code
The message Is trIvIaIIy constructed Irom the Ia1IJ1 subroutIne In the IIbrary,
deIIned as
\Oad Ia1IJ1{Ia1map *dS1, IOan1 dp,
Ia1map *Sic, Rec1an_Je Si, IcOde c¸.
The ߢIdߣ IIeIds In the message IndIcate another property oI 8l: the cIIents do not
store the actuaI data Ior any oI theIr bItmaps IocaIIy. Ìnstead, the protocoI provIdes a
message to aIIocate a bItmap, to be stored In the server, and returns to the cIIent an
Integer IdentIIIer, much IIke a UNÌX IIIe descrIptor, to be used In operatIons on that bIt·
map. 8Itmap number 0 Is conventIonaIIy the cIIentߣs wIndow, anaIogous to standard
Input Ior IIIe Ì]O. Ìn Iact, no bItmap graphIcs operatIons are executed In the cIIent at aII;
they are aII perIormed on Its behaII by the server. AgaIn, usIng the standard remote IIIe
· 6 ·
FIgure 1. A representatIve 8l screen, runnIng on a NeXTstatIon under PIan 9 (wIth
no NeXT soItware). Ìn the upper rIght, a program announces the arrIvaI oI maII. Ìn
the top and IeIt are a broswer Ior astronomIcaI databases and an Image oI a gaIaxy
produced by the browser. Ìn the Iower IeIt there Is a screen edItor, Sam [PIke87],
edItIng ]apanese text encoded In UTF, and In the Iower rIght an 8l runnIng recur·
sIveIy and, InsIde that InstantIatIon, a prevIewer Ior 1iO11 output. Underneath
the Iaces Is a smaII wIndow runnIng the command that prInts the screen by passIng
/de\/Scieen to the bItmap prIntIng utIIIty.
operatIons In PIan 9, thIs permIts remote machInes havIng no graphIcs capabIIIty, such
as the CPU server, to run graphIcs appIIcatIons. AnaIogous Ieatures oI the orIgInaI
Andrew wIndow system [Cos86] and oI X [Sche86] requIre more compIex mechanIsms.
Nor does 8l ItseII operate dIrectIy on bItmaps. Ìnstead, It caIIs another server to
do Its graphIcs operatIons Ior It, usIng an IdentIcaI protocoI. The operatIng system Ior
the PIan 9 termInaIs contaIns an InternaI server that ImpIements that protocoI, exactIy as
does 8l, but Ior a sIngIe cIIent. That server stores the actuaI bytes Ior the bItmaps and
ImpIements the IundamentaI bItmap graphIcs operatIons. Thus the envIronment In
whIch 8l runs has exactIy the structure It provIdes Ior Its cIIents; 8l reproduces the
envIronment Ior Its cIIents, muItIpIexIng the InterIace to keep the cIIents separate.
ThIs Idea oI muItIpIexIng by sImuIatIon Is appIIcabIe to more than wIndow systems,
oI course, and has some sIde eIIects. SInce 8l sImuIates Its own envIronment Ior Its
cIIents, It may run In one oI Its own wIndows (see FIgure 1). A useIuI and common
appIIcatIon oI thIs technIque Is to connect a wIndow to a remote machIne, such as a CPU
server, and run the wIndow system there so that each subwIndow Is automatIcaIIy on the
remote machIne. Ìt Is aIso a handy way to debug a new versIon oI the wIndow system or
to create an envIronment wIth, Ior exampIe, a dIIIerent deIauIt Iont.
· 7 ·
lmplementation
To provIde graphIcs to Its cIIents, 8l mostIy just muItIpIexes and passes through
to Its own server the cIIentsߣ requests, occasIonaIIy rearrangIng the messages to maIn·
taIn the IIctIon that the cIIents have unIque screens (wIndows). To manage the overIap·
pIng wIndows It uses the Iayers modeI, whIch Is handIed by a separate IIbrary [PIke83a].
Thus It has IIttIe work to do and Is a IaIrIy sImpIe program; It Is domInated by a coupIe
oI swItch statements to Interpret the bItmap and IIIe server protocoIs. The buIIt-In wIn·
dow program and Its assocIated menus and text-management support are responsIbIe
Ior most oI the code.
The operatIng systemߣs server Is aIso compact: the versIon Ior the 68020 proces·
sor, excIudIng the ImpIementatIon oI a haII dozen bItmap graphIcs operatIons, Is 229S
IInes oI C (agaIn, about haII deaIIng wIth Ionts); the graphIcs operatIons are another
2214 IInes.
8l Is structured as a set oI communIcatIng coroutInes, much as dIscussed In a
1989 paper [PIke89]. One coroutIne manages the mouse, another the keyboard, and
another Is InstantIated to manage the state oI each wIndow and assocIated cIIent. When
no coroutIne wIshes to run, 8l reads the next IIIe Ì]O request Irom Its cIIents, whIch
arrIve serIaIIy on the IuII-dupIex communIcatIon pIpe. Thus 8l Is entIreIy synchronous.
The program source Is smaII and compIIes In about 10 seconds In our PIan 9 envI·
ronment. There are ten source IIIes and one make1aJe totaIIng S100 IInes. ThIs
IncIudes the source Ior the wIndow management process, the cut-and-paste termInaI
program, the wIndow]IIIe server ItseII, and a smaII coroutIne IIbrary (piOc.c). Ìt does
not IncIude the Iayer IIbrary (another 1031 IInes) or the IIbrary to handIe the cuttIng and
pastIng oI text dIspIayed In a wIndow (960 IInes), or the generaI graphIcs support IIbrary
that manages aII the non-drawIng aspects oI graphIcs ߞ arIthmetIc on poInts and rect·
angIes, memory management, error handIIng, cIIppIng, ߞ pIus Ionts, events, and non-
prImItIve drawIng operatIons such as cIrcIes and eIIIpses (a IInaI 30S1 IInes). Not aII the
pIeces oI these IIbrarIes are used by 8l ItseII; a Iarge part oI the graphIcs IIbrary In par·
tIcuIar Is used onIy by cIIents. Thus It Is somewhat unIaIr to 8l just to sum these num·
bers, IncIudIng the 4S09 IInes oI support In the kerneI, and arrIve at a totaI ImpIementa·
tIon sIze oI 146S1 IInes oI source to ImpIement aII oI 8l Irom the Iowest IeveIs to the
hIghest. 8ut that number gIves a IaIr measure oI the compIexIty oI the overaII system.
The ImpIementatIon Is aIso eIIIcIent. 8lߣs perIormance Is competItIve to X wIn·
dowsߣ. Compared usIng Dunwoodyߣs and LIntonߣs _Iench benchmarks on the 68020,
dIstrIbuted wIth the ߢߢX Test SuIteߣߣ, cIrcIes and arcs are drawn about haII as Iast In 8l
as In X11 reIease 4 compIIed wIth _cc Ior equIvaIent hardware, probabIy because they
are currentIy ImpIemented In a user IIbrary by caIIs to the pOan1 prImItIve. LIne draw·
Ing speed Is about equaI between the two systems. UnIcode text Is drawn about the
same speed by 8l as ASCÌÌ text by X, and the Ia1IJ1 test Is runs Iour tImes Iaster Ior
8l. These numbers vary enough to cautIon agaInst drawIng sweepIng concIusIons, but
they suggest that 8lߣs archItecture does not penaIIze Its perIormance. FInaIIy, 8l boots
In under a second and creates a new wIndow apparentIy InstantaneousIy.
An example
Here Is a compIete program that runs under 8l. Ìt prInts the strIng
'heJJO wOiJd' wherever the IeIt mouse button Is depressed, and exIts when the
rIght mouse button Is depressed. Ìt aIso prInts the strIng In the center oI Its wIndow,
and maIntaIns that strIng when the wIndow Is resIzed.
· 8 ·
=ancJude <u.h>
=ancJude <JaIc.h>
=ancJude <JaI_.h>
\Oad
eieShaped{Rec1an_Je i¸
(
IOan1 p,
Scieen.i = i,
Ia1IJ1{&Scieen, Scieen.i.man, &Scieen, i, ZeiO¸, /* cJeai */
p.x = Scieen.i.man.x + Dx{Scieen.i¸/2,
p.y = Scieen.i.man.y + Dy{Scieen.i¸/2,
p = SuI{p, da\{S1iSaze{1On1, 'heJJO wOiJd'¸, 2¸¸,
S1ian_{&Scieen, p, 1On1, 'heJJO wOiJd', S¸,
}
maan{\Oad¸
(
NOuSe m,
Iana1{U, U, U¸, /* ana1aaJaze _iaphacS JaIiaiy */
eana1{£mOuSe¸, /* ana1aaJaze e\en1 JaIiaiy */
eieShaped{Scieen.i¸,
1Oi{,,¸(
m = emOuSe{¸,
a1{m.Iu11OnS & RJCHJI¸
Iieak,
a1{m.Iu11OnS & I£IJI¸(
S1ian_{&Scieen, m.xy, 1On1, 'heJJO wOiJd', S¸,
/* waa1 1Oi ieJeaSe O1 Iu11On */
dO, whaJe{emOuSe{¸.Iu11OnS & I£IJI¸,
}
}
}
The compIete Ioaded bInary Is a IIttIe over 26K bytes on a 68020. ThIs program shouId
be compared to the sImIIar ones In the exceIIent paper by RosenthaI [Rose88]. (The cur·
rent program does more: It aIso empIoys the mouse.) The cIumsIest part Is
eieShaped, a IunctIon wIth a known name that Is caIIed Irom the event IIbrary when·
ever the wIndow Is reshaped or moved, as Is dIscovered IneIegantIy but adequateIy by a
specIaI case oI a mouse message. (SImpIe so-caIIed expose events are not events at aII
In 8l; the Iayer IIbrary takes care oI them transparentIy.) The Iesson oI thIs program,
wIth deIerence to RosenthaI, Is that II the wIndow system Is cIeanIy desIgned a tooIkIt
shouId be unnecessary Ior sImpIe tasks.
Status
As oI 1992, 8l Is In reguIar daIIy use by aImost aII the 60 peopIe In our research
center. Some oI those peopIe use It to access PIan 9 ItseII; others use It as a Iront end
to remote UNÌX systems, much as one wouId use an X termInaI.
Some thIngs about 8l may change. Ìt wouId be nIce II Its capabIIItIes were more
easIIy accessIbIe Irom the sheII. A companIon to thIs paper [PIke91] proposes one way
to do thIs, but that does not IncIude any graphIcs IunctIonaIIty. Perhaps a textuaI ver·
sIon oI the /de\/Ia1IJ1 IIIe Is a way to proceed; that wouId aIIow, Ior exampIe, awk
programs to draw graphs dIrectIy.
Can thIs styIe oI wIndow system be buIIt on other operatIng systemsZ A major part
oI the desIgn oI 8l depends on Its structure as a IIIe server. Ìn prIncIpIe thIs couId be
· 9 ·
done Ior any system that supports user processes that serve IIIes, such as any system
runnIng NFS or AFS [Sun89, Kaza87]. One requIrement, however, Is 8lߣs need to
respond to Its cIIentsߣ requests out oI order: II one cIIent reads /de\/cOnS In a wIn·
dow wIth no characters to be read, other cIIents shouId be abIe to perIorm Ì]O In theIr
wIndows, or even the same wIndow. Another constraInt Is that the 8l IIIes are IIke
devIces, and must not be cached by the cIIent. NFS cannot honor these requIrements;
AFS may be abIe to. OI course, other Interprocess communIcatIon mechanIsms such as
sockets couId be used as a basIs Ior a wIndow system. One may even argue that Xߣs
modeI IIts Into thIs overaII scheme. Ìt may prove easy and worthwhIIe to wrIte a smaII
8l-IIke system Ior commercIaI UNÌX systems to demonstrate that Its merIts can be won
In systems other than PIan 9.
Conclusion
Ìn concIusIon, 8l uses an unusuaI archItecture In concert wIth the IIIe-orIented
Interprocess communIcatIon oI PIan 9 to provIde network-based InteractIve graphIcs to
cIIent programs. Ìt demonstrates that even productIon-quaIIty wIndow systems are not
InherentIy Iarge or compIIcated and may be sImpIe to use and to program.
Acknowledgements
HeIpIuI comments on earIy draIts oI thIs paper were made by Doug 8Iewett, Stu
FeIdman, ChrIs Fraser, 8rIan KernIghan, DennIs RItchIe, and PhII WInterbottom. 8lߣs
support Ior coIor was added by Howard TrIckey. Many oI the Ideas IeadIng to 8l were
trIed out In earIIer, sometImes Iess successIuI, programs. Ì wouId IIke to thank those
users who suIIered through some oI my prevIous 7l wIndow systems.
References
[DuII90] Tom DuII, ߢߢRc - A SheII Ior PIan 9 and UNÌX systemsߣߣ, Proc. oI the Summer
1990 UKUUC ConI., London, ]uIy, 1990, pp. 21-33, reprInted, In a dIIIerent Iorm, In thIs
voIume.
[Far89] Far too many peopIe, XTERM(1), Massachusetts ÌnstItute oI TechnoIogy, 1989.
[Cos86] ]ames CosIIng and DavId RosenthaI, ߢߢA wIndow manager Ior bItmapped dIs·
pIays and UNÌXߣߣ, In MethodoIogy oI WIndow Management, edIted by F.R.A. Hopgood et
aI., SprInger, 1986.
[Kaza87] MIke Kazar, ߢߢSynchronIzatIon and CachIng Issues In the Andrew FIIe Systemߣߣ,
Tech. Rept. CMU-ÌTC-0S8, ÌnIormatIon TechnoIogy Center, CarnegIe MeIIon UnIversIty,
]une, 1987.
[KIII84] Tom KIIIIan, ߢߢProcesses as FIIesߣߣ, USENÌX Summer ConI. Proc., SaIt Lake CIty
]une, 1984.
[PIke83] Rob PIke, ߢߢThe 8IIt: A MuItIpIexed CraphIcs TermInaIߣߣ, 8eII Labs Tech. ]., V63,
#8, part 2, pp. 1607-1631.
[PIke83a] Rob PIke, ߢߢCraphIcs In OverIappIng 8Itmap Layersߣߣ, Trans. on Craph., VoI 2,
#2, 13S-160, reprInted In Proc. SÌCCRAPH ߣ83, pp. 331-3S6.
[PIke87] Rob PIke, ߢߢThe Text EdItor Samߣߣ, SoItw. - Prac. and Exp., Nov 1987, VoI 17
#11, pp. 813-84S, reprInted In thIs voIume.
[PIke88] Rob PIke, ߢߢWIndow Systems ShouId 8e Transparentߣߣ, Comp. Sys., Summer
1988, VoI 1 #3, pp. 279-296.
[PIke89] Rob PIke, ߢߢA Concurrent WIndow Systemߣߣ, Comp. Sys., SprIng 1989, VoI 2 #2,
pp. 133-1S3.
[PIke91] Rob PIke, ߢߢA MInImaIIst CIobaI User ÌnterIaceߣߣ, USENÌX Summer ConI. Proc.,
NashvIIIe, ]une, 1991.
· 10 ·
[PIke92] Rob PIke, Dave Presotto, Ken Thompson, Howard TrIckey, and PhII WInterbot·
tom, OperatIng Systems RevIew VoI 27, #2, Apr 1993, pp. 72-76 (reprInted Irom Pro·
ceedIngs oI the Sth ACM SÌCOPS European Workshop, Mont SaInt-MIcheI, 1992, Paper n"
34, and reprInted In thIs voIume).
[PIke94] Rob PIke and Ken Thompson, ߢߢHeIIo WorId or KcAqµcpc xóoµc or
ߣߣ, USENÌX WInter ConI. Proc., San DIego, ]an, 1993, reprInted In thIs voIume.
[PLR8S] Rob PIke, 8art LocanthI and ]ohn ReIser, ߢߢHardware]SoItware TradeoIIs Ior 8It·
map CraphIcs on the 8IItߣߣ, SoItw. - Prac. and Exp., Feb 198S, VoI 1S #2, pp. 131-1S2.
[Pres90] DavId L. Presotto and DennIs M. RItchIe, ߢߢÌnterprocess CommunIcatIon In the
NInth EdItIon UnIx Systemߣߣ, SoItw. - Prac. and Exp., ]une 1990, VoI 20 #S1, pp. S1]3-
S1]17.
[Rose88] DavId RosenthaI, ߢߢA SImpIe X11 CIIent Program -or- How hard can It reaIIy be
to wrIte ߢߢHeIIo, WorIdߣߣZߣߣ, USENÌX WInter ConI. Proc., DaIIas, ]an, 1988, pp. 229-242.
[Sche86] Robert W. ScheIIIer and ]Im Cettys, ߢߢThe X WIndow Systemߣߣ, ACM Trans. on
Craph., VoI S #2, pp. 79-109.
[Sun89] Sun MIcrosystems, NFS: Network IIIe system protocoI specIIIcatIon, RFC 1094,
Network ÌnIormatIon Center, SRÌ ÌnternatIonaI, March, 1989.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->