8½.ms 31 KB

  1. .HTML "8½, the Plan 9 Window System
  2. .TL
  3. 8½, the Plan 9 Window System
  4. .AU
  5. Rob Pike
  6. rob@plan9.bell-labs.com
  7. .AB
  8. .FS
  9. Originally appeared, in a slightly different form, in
  10. .I
  11. Proc. of the Summer 1991 USENIX Conf.,
  12. .R
  13. pp. 257-265,
  14. Nashville.
  15. Note that
  16. .CW 8½
  17. has been replaced by
  18. .CW rio
  19. (see
  20. .I rio (1)).
  21. .FE
  22. The Plan 9 window system, 8½, is a modest-sized program of novel design.
  23. It provides textual I/O and bitmap graphic services to both
  24. local and remote client programs by offering a multiplexed file service to those clients.
  25. It serves traditional UNIX files like
  26. .CW /dev/tty
  27. as well as more unusual ones that provide access to the mouse
  28. and the raw screen.
  29. Bitmap graphics operations are provided by serving a file called
  30. .CW /dev/bitblt
  31. that interprets client messages to perform raster operations.
  32. The file service that 8½ offers its clients is identical to that it uses for
  33. its own implementation, so it is fundamentally no more than
  34. a multiplexer.
  35. This architecture has some rewarding symmetries and can be implemented
  36. compactly.
  37. .AE
  38. .SH
  39. Introduction
  40. .PP
  41. In 1989 I constructed a toy window system from only a few hundred
  42. lines of source code using a custom language and an unusual architecture
  43. involving concurrent processes [Pike89].
  44. Although that system was rudimentary at best, it demonstrated that
  45. window systems are not inherently complicated.
  46. The following year, for the new Plan 9 distributed system [Pike92], I applied some of
  47. the lessons from that toy project to write, in C,
  48. a production-quality window system
  49. called 8½.
  50. 8½ provides, on black-and-white, grey-scale, or color displays,
  51. the services required of a modern window system, including
  52. programmability and support for remote graphics.
  53. The entire system, including the default program that runs in the
  54. window \(em the equivalent of
  55. .CW xterm
  56. [Far89] with `cutting and pasting' between windows \(em
  57. is well under 90 kilobytes of text on a Motorola 68020 processor, about
  58. half the size of the
  59. operating system
  60. kernel that supports it and a tenth the size of the X server
  61. [Sche86]
  62. .I without
  63. .CW xterm .
  64. .PP
  65. What makes 8½ so compact? Much of the saving comes from overall simplicity:
  66. 8½ has little graphical fanciness, a concise programming interface, and
  67. a simple, fixed user interface.
  68. 8½ also makes some decisions by fiat
  69. \(em three-button mouse, overlapping windows, built-in terminal program and
  70. window manager, etc. \(em
  71. rather than trying to appeal to all tastes.
  72. Although compact, 8½ is not ascetic.
  73. It provides the fundamentals and
  74. enough extras to make them comfortable to use.
  75. The most important contributor to its small size, though, is its
  76. overall design as a file server.
  77. This structure may be applicable to window systems
  78. on traditional UNIX-like operating systems.
  79. .PP
  80. The small size of 8½ does not reflect reduced functionality:
  81. 8½ provides service roughly equivalent to the X window system.
  82. 8½'s clients may of course be as complex as they choose,
  83. although the tendency to mimic 8½'s design
  84. and the clean programming interface means they
  85. are not nearly as bloated as X applications.
  86. .SH
  87. User's Model
  88. .PP
  89. 8½ turns the single screen, mouse, and keyboard of the terminal
  90. (in Plan 9 terminology) or workstation (in commercial terminology) into an array
  91. of independent virtual terminals that may be textual terminals supporting a shell and
  92. the usual suite of tools
  93. or graphical applications using the full power of the bitmap screen and mouse.
  94. Text is represented in UTF, an encoding of the Unicode Standard [Pike93].
  95. The entire programming interface is provided through
  96. reading and writing files in
  97. .CW /dev .
  98. .PP
  99. Primarily for reasons of history and familiarity,
  100. the general model and appearance of 8½ are similar to those of
  101. .CW mux
  102. [Pike88].
  103. The right button has a short menu for controlling window creation, destruction,
  104. and placement.
  105. When a window is created, it runs the default shell,
  106. .CW rc
  107. [Duff90], with standard input
  108. and output directed to the window and accessible through the file
  109. .CW /dev/cons
  110. (`console'),
  111. analogous to the
  112. .CW /dev/tty
  113. of UNIX.
  114. The name change represents a break with the past: Plan 9 does not provide a
  115. Teletype-style model of terminals. 8½ provides the only way
  116. most users ever access Plan 9.
  117. .PP
  118. Graphical applications,
  119. like ordinary programs,
  120. may be run by typing their names
  121. to the shell running in a window.
  122. This runs the application in the same window;
  123. to run the application in a new window one may use an external program,
  124. .CW window ,
  125. described below.
  126. For graphical applications, the virtual terminal model
  127. is extended somewhat to allow programs to perform graphical operations,
  128. access the
  129. mouse, and perform related functions by reading and writing files with
  130. suggestive names such as
  131. .CW /dev/mouse
  132. and
  133. .CW /dev/window
  134. multiplexed per-window
  135. much like
  136. .CW /dev/cons .
  137. The implementation and semantics of these files,
  138. described below, is central to the structure of 8½.
  139. .PP
  140. The default program that runs in a window is familiar to users of Blit terminals [Pike83].
  141. It is very similar to that of
  142. .CW mux
  143. [Pike88], providing mouse-based editing of input and output text,
  144. the ability to scroll back to see earlier output, and so on.
  145. It also has a new feature, toggled by typing ESC,
  146. that enables the user to control when
  147. typed characters may be read by the shell or application,
  148. instead of (for example) after each newline.
  149. This feature makes the window program directly useful for many text-editing
  150. tasks such as composing mail messages before sending them.
  151. .SH
  152. Plan 9 and 8½
  153. .PP
  154. Plan 9 is a distributed system that provides support for UNIX-like applications
  155. in an environment built from distinct CPU servers, file servers, and terminals
  156. connected by a variety of networks [Pike90].
  157. The terminals are comparable to modest workstations that, once connected to a file
  158. server over a medium-bandwidth network such as Ethernet, are self-sufficient computers
  159. running a full operating system.
  160. Unlike workstations, however, their role is just to
  161. provide an affordable multiplexed user interface to the rest of the system:
  162. they run the window system and support simple interactive
  163. tasks such as text editing.
  164. Thus they lie somewhere between workstations and X terminals in design,
  165. cost, performance, and function.
  166. (The terminals can be used
  167. for general computing, but in practice Plan 9 users do their
  168. computing on the CPU servers.)
  169. The Plan 9 terminal software, including 8½,
  170. was developed on a 68020-based
  171. machine called a Gnot
  172. and has been ported to
  173. the NeXTstation,
  174. the MIPS Magnum 3000,
  175. SGI Indigos,
  176. and Sun SPARCstations\(emall small workstations that we use as terminals\(emas
  177. well as PCs.
  178. .PP
  179. Heavy computations such as compilation, text processing,
  180. or scientific calculation are done on the CPU servers, which are connected
  181. to the file servers by high-bandwidth networks.
  182. For interactive work,
  183. these computations can access the terminal that instantiated them.
  184. The terminal and CPU server being used by a particular user are connected to the
  185. same file server, although over different networks; Plan 9 provides a view of the
  186. file server that is independent of location in the network.
  187. .PP
  188. The components of Plan 9 are connected by a common protocol based on the sharing of files.
  189. All resources in the network are implemented as file servers; programs that wish to
  190. access them connect to them over the network and communicate using ordinary file
  191. operations.
  192. An unusual aspect of Plan 9 is that the
  193. .I
  194. name space
  195. .R
  196. of a process, the set of files that can be accessed by name
  197. (for example by an
  198. .CW open
  199. system call) is not global to all processes on a machine; distinct processes
  200. may have distinct name spaces. The system provides methods by which processes
  201. may change their name spaces, such as the ability to
  202. .I mount
  203. a service upon an existing directory, making the files of the service
  204. visible in the directory.
  205. (This is a different operation from its
  206. UNIX
  207. namesake.)
  208. Multiple services may be mounted upon the same directory,
  209. allowing the files from multiple services to be accessed in the same directory.
  210. Options to the
  211. .CW mount
  212. system call control the order of searching for files in such a
  213. .I
  214. union directory.
  215. .R
  216. .PP
  217. The most obvious example of a network resource is a file server, where permanent
  218. files reside. There are a number of unusual services, however, whose design in
  219. a different environment would likely not be file-based. Many are described
  220. elsewhere [Pike92]; some examples are the representation
  221. of processes for debugging,
  222. much like Killian's process files for the 8th edition [Kill84],
  223. and the implementation of the name/value pairs of the
  224. UNIX
  225. .CW exec
  226. environment as files.
  227. User processes may also implement a file service and make it available to clients
  228. in the network, much like the `mounted streams' in the 9th Edition
  229. [Pres90].
  230. A typical example is a program that interprets an externally-defined file system
  231. such as that on a CD-ROM or a standard
  232. UNIX
  233. system and makes the contents available to Plan 9 programs.
  234. This design is used by all distributed applications in Plan 9, including 8½.
  235. .PP
  236. 8½ serves a set of files in the conventional directory
  237. .CW /dev
  238. with names like
  239. .CW cons ,
  240. .CW mouse ,
  241. and
  242. .CW screen .
  243. Clients of 8½ communicate with the window system by reading and writing
  244. these files.
  245. For example, a client program, such as a shell,
  246. can print text by writing its standard output, which is automatically
  247. connected to
  248. .CW /dev/cons ,
  249. or it may open and write that file explicitly.
  250. Unlike files served by a traditional file server, however, the instance of
  251. .CW /dev/cons
  252. served in each window by 8½ is a distinct file;
  253. the per-process name spaces of Plan 9 allow 8½ to provide a unique
  254. .CW /dev/cons
  255. to each client.
  256. This mechanism is best illustrated by the creation of a new 8½ client.
  257. .PP
  258. When 8½ starts, it creates a full-duplex pipe to be the communication
  259. medium for the messages that implement the file service it will provide.
  260. One end will be shared by all the clients; the other end is held by
  261. 8½ to accept requests for I/O.
  262. When a user makes a new window using the mouse,
  263. 8½ allocates the window data structures and forks a child process.
  264. The child's name space,
  265. initially shared with the parent,
  266. is then duplicated
  267. so that changes the child makes to its name space will not affect the parent.
  268. The child then attaches its end of the communication pipe,
  269. .CW cfd ,
  270. to the directory
  271. .CW /dev
  272. by doing a
  273. .CW mount
  274. system call:
  275. .P1
  276. mount(cfd, "/dev", MBEFORE, buf)
  277. .P2
  278. This call attaches the service associated with the file descriptor
  279. .CW cfd
  280. \(em the client end of the pipe \(em to the beginning of
  281. .CW /dev
  282. so that the files in the new service take priority over existing files
  283. in the directory.
  284. This makes the new files
  285. .CW cons ,
  286. .CW mouse ,
  287. and so on,
  288. available in
  289. .CW /dev
  290. in a way that hides any files with the same names already in place.
  291. The argument
  292. .CW buf
  293. is a character string (null in this case),
  294. described below.
  295. .PP
  296. The client process then closes file descriptors 0, 1, and 2 and opens
  297. .CW /dev/cons
  298. repeatedly to connect the standard
  299. input, output, and error files to the window's
  300. .CW /dev/cons .
  301. It then does an
  302. .CW exec
  303. system call to begin executing the shell in the window.
  304. This entire sequence, complete with error handling, is 33 lines of C.
  305. .PP
  306. The view of these events from 8½'s end of the pipe is a sequence
  307. of file protocol messages from the new client generated by the
  308. intervening operating
  309. system in response to the
  310. .CW mount
  311. and
  312. .CW open
  313. system calls executed by the client.
  314. The message generated by the
  315. .CW mount
  316. informs 8½ that a new client has attached to the file service it provides;
  317. 8½'s response is a unique identifier kept by the operating system and
  318. passed in all messages generated by I/O on the files derived from that
  319. .CW mount .
  320. This identifier is used by 8½ to distinguish the various clients so
  321. each sees a unique
  322. .CW /dev/cons ;
  323. most servers do not need to make this distinction.
  324. .PP
  325. A process unrelated to 8½ may create windows by a variant of this mechanism.
  326. When 8½ begins, it uses a Plan 9 service to `post' the client end of the
  327. communication pipe in a public place.
  328. A process may open that pipe and
  329. .CW mount
  330. it to attach to the window system,
  331. much in the way an X client may connect to a
  332. UNIX
  333. domain socket to the server bound to the file system.
  334. The final argument to
  335. .CW mount
  336. is passed through uninterpreted by the operating
  337. system.
  338. It provides a way for the client and server to
  339. exchange information at the time of the
  340. .CW mount .
  341. 8½ interprets it as the dimensions of the window to be
  342. created for the new client. (In the case above, the window has been
  343. created by the time the mount occurs, and
  344. .CW buf
  345. carries no information.)
  346. When the
  347. .CW mount
  348. returns, the process can open the files of the new window and begin I/O to
  349. use it.
  350. .PP
  351. Because 8½'s interface is based on files,
  352. standard system utilities can be used to control its services.
  353. For example,
  354. its method of creating windows externally is packaged in a
  355. 16-line shell script, called
  356. .CW window ,
  357. the core of which is just a
  358. .CW mount
  359. operation that prefixes 8½'s directory to
  360. .CW /dev
  361. and runs a command passed on the argument line:
  362. .P1
  363. mount -b $'8½serv' /dev
  364. $* < /dev/cons > /dev/cons >[2] /dev/cons &
  365. .P2
  366. The
  367. .CW window
  368. program is typically employed by users to create their
  369. initial working environment when they boot the system, although
  370. it has more general possibilities.
  371. .PP
  372. Other basic features of the system fall out naturally from the
  373. file-based model.
  374. When the user deletes a window, 8½ sends the equivalent of a
  375. UNIX
  376. signal to the process group \(em the clients \(em in the window,
  377. removes the window from the screen, and poisons the incoming connections
  378. to the files that drive it. If a client ignores the signal and
  379. continues to write to the window, it will get I/O errors.
  380. If, on the other hand, all the processes in a window exit spontaneously,
  381. they will automatically close all connections to the window.
  382. 8½ counts references to the window's files; when none are left,
  383. it shuts down the window and removes it from the screen.
  384. As a different example, when the user hits the DEL key to generate an
  385. interrupt,
  386. 8½ writes a message to a special file, provided by Plan 9's
  387. process control interface, that interrupts all the processes
  388. in the window.
  389. In all these examples, the implementation works seamlessly
  390. across a network.
  391. .PP
  392. There are two valuable side effects of implementing
  393. a window system by multiplexing
  394. .CW /dev/cons
  395. and other such files.
  396. First, the problem of giving a meaningful
  397. interpretation to the file
  398. .CW /dev/cons
  399. .CW /dev/tty ) (
  400. in each window is solved automatically.
  401. To provide
  402. .CW /dev/cons
  403. is the fundamental job of the window system, rather than just an awkward burden;
  404. other systems must often make special and otherwise irrelevant arrangements for
  405. .CW /dev/tty
  406. to behave as expected in a window.
  407. Second, any program that can access the server, including a
  408. process on a remote machine, can access the files using standard
  409. read and write system calls to communicate with the window system,
  410. and standard open and close calls to connect to it.
  411. Again, no special arrangements need to be made for remote processes to
  412. use all the graphics facilities of 8½.
  413. .SH
  414. Graphical input
  415. .PP
  416. Of course 8½ offers more than ASCII I/O to its clients.
  417. The state of the mouse may be discovered by reading the file
  418. .CW /dev/mouse ,
  419. which returns a ten-byte message encoding the state
  420. of the buttons and the position of the cursor.
  421. If the mouse has not moved since the last read of
  422. .CW /dev/mouse ,
  423. or if the window associated with the instance of
  424. .CW /dev/mouse
  425. is not the `input focus', the read blocks.
  426. .PP
  427. The format of the message is:
  428. .DS
  429. .CW 'm'
  430. 1 byte of button state
  431. 4 bytes of x, low byte first
  432. 4 bytes of y, low byte first
  433. .DE
  434. As in all shared data structures in Plan 9,
  435. the order of every byte in the message is defined
  436. so all clients can execute the same code to unpack the message
  437. into a local data structure.
  438. .PP
  439. For keyboard input, clients can read
  440. .CW /dev/cons
  441. or, if they need character-at-a-time input,
  442. .CW /dev/rcons
  443. (`raw console').
  444. There is no explicit event mechanism to help clients that need to read
  445. from multiple sources.
  446. Instead, a small (365 line) external
  447. support library can be used.
  448. It attaches a process
  449. to the various blocking input sources \(em mouse, keyboard, and perhaps
  450. a third user-provided file descriptor \(em
  451. and funnels their input into a single pipe from which may be read
  452. the various types of
  453. events in the traditional style.
  454. This package is a compromise. As discussed in a previous paper
  455. [Pike89] I prefer
  456. to free applications from event-based programming. Unfortunately, though, I see
  457. no easy way to achieve this in single-threaded C programs, and am unwilling
  458. to require all programmers to master concurrent programming.
  459. It should be noted, though, that even this compromise results in a small
  460. and easily understood interface. An example program that uses it is
  461. given near the end of the paper.
  462. .SH
  463. Graphical output
  464. .PP
  465. The file
  466. .CW /dev/screen
  467. may be read by any client to recover the contents of the entire screen,
  468. such as for printing (see Figure 1).
  469. Similarly,
  470. .CW /dev/window
  471. holds the contents of the current window.
  472. These are read-only files.
  473. .PP
  474. To perform graphics operations in their windows, client programs access
  475. .CW /dev/bitblt .
  476. It implements a protocol that encodes bitmap graphics operations.
  477. Most of the messages in the protocol (there are 23 messages in all, about
  478. half to manage the multi-level fonts necessary for efficient handling
  479. of Unicode characters)
  480. are transmissions (via a write)
  481. from the client to the window system to perform a graphical
  482. operation such as a
  483. .CW bitblt
  484. [PLR85] or character-drawing operation; a few include return information
  485. (recovered via a read) to the client.
  486. As with
  487. .CW /dev/mouse ,
  488. the
  489. .CW /dev/bitblt
  490. protocol is in a defined byte order.
  491. Here, for example, is the layout of the
  492. .CW bitblt
  493. message:
  494. .DS
  495. .CW 'b'
  496. 2 bytes of destination id
  497. 2x4 bytes of destination point
  498. 2 bytes of source id
  499. 4x4 bytes of source rectangle
  500. 2 bytes of boolean function code
  501. .DE
  502. .KF
  503. .ie h .html - <center><a href="8½.fig1.png"><img src="8½.fig1s.png"></a></center>
  504. .el .BP fig1.ps 4.16 5.6 r 0 0
  505. .EP
  506. .IP
  507. Figure 1.
  508. A representative 8½ screen, running on a NeXTstation under Plan 9
  509. (with no NeXT software). In the upper right, a program announces the
  510. arrival of mail. In the top and left are a broswer for astronomical
  511. databases and an image of a galaxy produced by the browser.
  512. In the lower left there is a screen editor,
  513. .CW sam
  514. [Pike87],
  515. editing Japanese text encoded in UTF,
  516. and in the lower right an 8½ running recursively and, inside that instantiation,
  517. a previewer for
  518. .CW troff
  519. output.
  520. Underneath the faces is a small window running the command that
  521. prints the screen by passing
  522. .CW /dev/screen
  523. to the bitmap printing utility.
  524. .sp
  525. .KE
  526. .PP
  527. The message is trivially constructed from the
  528. .CW bitblt
  529. subroutine in the library, defined as
  530. .P1
  531. void bitblt(Bitmap *dst, Point dp,
  532. Bitmap *src, Rectangle sr, Fcode c).
  533. .P2
  534. .PP
  535. The `id'
  536. fields in the message indicate another property of 8½:
  537. the clients do not store the actual data for any of their bitmaps locally.
  538. Instead, the protocol provides a message to allocate a bitmap, to be
  539. stored in the server, and returns to the client an integer identifier,
  540. much like a
  541. UNIX
  542. file descriptor, to be used in operations on that bitmap.
  543. Bitmap number 0 is conventionally the client's window,
  544. analogous to standard input for file I/O.
  545. In fact, no bitmap graphics operations are executed in the client at all;
  546. they are all performed on its behalf by the server.
  547. Again, using the standard remote file operations in Plan 9,
  548. this permits remote machines having no graphics capability, such
  549. as the CPU server,
  550. to run graphics applications.
  551. Analogous features of the original Andrew window system [Gos86]
  552. and of X [Sche86] require more complex mechanisms.
  553. .PP
  554. Nor does 8½ itself operate directly on bitmaps.
  555. Instead, it calls another server to do its graphics operations for it,
  556. using an identical protocol.
  557. The operating system for the Plan 9 terminals contains an internal
  558. server that implements that protocol, exactly as does 8½, but for a single
  559. client. That server stores the actual bytes for the bitmaps
  560. and implements the fundamental bitmap graphics operations.
  561. Thus the environment in which 8½ runs
  562. has exactly the structure it provides for its clients;
  563. 8½ reproduces the environment for its clients,
  564. multiplexing the interface to keep the clients separate.
  565. .PP
  566. This idea of multiplexing by simulation is applicable to more
  567. than window systems, of course, and has some side effects.
  568. Since 8½ simulates its own environment for its clients, it may run
  569. in one of its own windows (see Figure 1).
  570. A useful and common application of this
  571. technique is to connect a window to a remote machine, such as a CPU
  572. server, and run the window system there so that each subwindow is automatically
  573. on the remote machine.
  574. It is also a handy way to debug a new version of the window system
  575. or to create an environment with, for example, a different default font.
  576. .SH
  577. Implementation
  578. .PP
  579. To provide graphics to its clients, 8½ mostly just multiplexes and passes
  580. through to its own server the clients' requests, occasionally rearranging
  581. the messages to maintain the fiction that the clients have unique screens
  582. (windows).
  583. To manage the overlapping windows it uses the layers model,
  584. which is handled by a separate library [Pike83a].
  585. Thus it has little work to do and is a fairly simple program;
  586. it is dominated by a couple of switch statements to interpret
  587. the bitmap and file server protocols.
  588. The built-in window program and its associated menus and text-management
  589. support are responsible for most of the code.
  590. .PP
  591. The operating system's server is also compact:
  592. the version for the 68020 processor, excluding the implementation
  593. of a half dozen bitmap graphics operations, is 2295 lines of C
  594. (again, about half dealing with fonts);
  595. the graphics operations are another 2214 lines.
  596. .PP
  597. 8½ is structured as a set of communicating coroutines,
  598. much as discussed in a 1989 paper [Pike89].
  599. One coroutine manages the mouse, another the keyboard, and another
  600. is instantiated to manage the state of each window and associated client.
  601. When no coroutine wishes to run, 8½ reads the next file I/O request from
  602. its clients, which arrive serially on the full-duplex communication pipe.
  603. Thus 8½ is entirely synchronous.
  604. .PP
  605. The program source is small and compiles in about 10 seconds
  606. in our Plan 9 environment. There are ten source files and
  607. one
  608. .CW makefile
  609. totaling 5100 lines.
  610. This includes the source for the window management process,
  611. the cut-and-paste terminal program,
  612. the window/file server itself,
  613. and a small coroutine library
  614. .CW proc.c ). (
  615. It does not include the layer library
  616. (another 1031 lines)
  617. or the library to handle the cutting and pasting of text
  618. displayed in a window (960 lines),
  619. or the general graphics support library that manages all the
  620. non-drawing aspects of graphics \(em arithmetic on points and rectangles,
  621. memory management, error handling, clipping, \(em plus fonts,
  622. events, and non-primitive drawing operations such as circles and ellipses
  623. (a final 3051 lines).
  624. Not all the pieces of these libraries are used by 8½ itself;
  625. a large part of the graphics library in particular is used only by clients.
  626. Thus it is somewhat unfair to 8½ just to sum these numbers, including
  627. the 4509 lines of support in the kernel, and arrive
  628. at a total implementation size of 14651 lines of source to implement
  629. all of 8½ from the lowest levels to the highest.
  630. But that number gives a fair measure of the complexity of the overall system.
  631. .PP
  632. The implementation is also efficient.
  633. 8½'s performance is competitive to X windows'.
  634. Compared using Dunwoody's and Linton's
  635. .CW gbench
  636. benchmarks on the 68020,
  637. distributed with the ``X Test Suite'',
  638. circles and arcs are drawn about half as fast in 8½ as in
  639. X11 release 4 compiled with
  640. .CW gcc
  641. for equivalent hardware,
  642. probably because they are currently implemented in a user library
  643. by calls to the
  644. .CW point
  645. primitive.
  646. Line drawing speed is about equal between the two systems.
  647. Unicode text is drawn about the same speed by 8½ as ASCII text by
  648. X, and
  649. the
  650. .CW bitblt
  651. test is runs four times faster for 8½.
  652. These numbers vary enough to caution against drawing sweeping
  653. conclusions, but they
  654. suggest that 8½'s architecture does not penalize its performance.
  655. Finally, 8½ boots in under a second and creates a new window
  656. apparently instantaneously.
  657. .SH
  658. An example
  659. .PP
  660. Here is a complete program that runs under 8½.
  661. It prints the string
  662. .CW \&"hello
  663. .CW world"
  664. wherever the left mouse button is depressed, and exits when the
  665. right mouse button is depressed.
  666. It also prints the string in the center of its window, and maintains
  667. that string when the window is resized.
  668. .P1
  669. #include <u.h>
  670. #include <libc.h>
  671. #include <libg.h>
  672. void
  673. ereshaped(Rectangle r)
  674. {
  675. Point p;
  676. screen.r = r;
  677. bitblt(&screen, screen.r.min, &screen, r, Zero); /* clear */
  678. p.x = screen.r.min.x + Dx(screen.r)/2;
  679. p.y = screen.r.min.y + Dy(screen.r)/2;
  680. p = sub(p, div(strsize(font, "hello world"), 2));
  681. string(&screen, p, font, "hello world", S);
  682. }
  683. main(void)
  684. {
  685. Mouse m;
  686. binit(0, 0, 0); /* initialize graphics library */
  687. einit(Emouse); /* initialize event library */
  688. ereshaped(screen.r);
  689. for(;;){
  690. m = emouse();
  691. if(m.buttons & RIGHTB)
  692. break;
  693. if(m.buttons & LEFTB){
  694. string(&screen, m.xy, font, "hello world", S);
  695. /* wait for release of button */
  696. do; while(emouse().buttons & LEFTB);
  697. }
  698. }
  699. }
  700. .P2
  701. The complete loaded binary is a little over 26K bytes on a 68020.
  702. This program should be compared to the similar ones in the excellent paper
  703. by Rosenthal [Rose88].
  704. (The current program does more: it also employs the mouse.)
  705. The clumsiest part is
  706. .CW ereshaped ,
  707. a function with a known name that is called from the event library
  708. whenever the window is
  709. reshaped or moved, as is discovered inelegantly but adequately
  710. by a special case of a mouse message.
  711. (Simple so-called expose events are not events
  712. at all in 8½; the layer library takes care of them transparently.)
  713. The lesson of this program, with deference to Rosenthal, is that if
  714. the window system is cleanly designed a toolkit should be unnecessary
  715. for simple tasks.
  716. .SH
  717. Status
  718. .PP
  719. As of 1992, 8½ is in regular daily use by almost all the 60 people in our
  720. research center. Some of those people use it to access Plan 9 itself; others
  721. use it as a front end to remote
  722. UNIX
  723. systems, much as one would use an X terminal.
  724. .PP
  725. Some things about 8½ may change.
  726. It would be nice if its capabilities were more easily accessible
  727. from the shell.
  728. A companion to this paper [Pike91] proposes one way to do this,
  729. but that does not include any graphics functionality.
  730. Perhaps a textual version of the
  731. .CW /dev/bitblt
  732. file is a way to proceed; that would allow, for example,
  733. .CW awk
  734. programs to draw graphs directly.
  735. .PP
  736. Can this style of window system be built on other operating systems?
  737. A major part of the design of 8½ depends on its structure as a file server.
  738. In principle this could be done for any system that supports user processes
  739. that serve files, such as any system running NFS or AFS [Sun89, Kaza87].
  740. One requirement, however, is 8½'s need
  741. to respond to its clients' requests out of order:
  742. if one client reads
  743. .CW /dev/cons
  744. in a window with no characters to be read,
  745. other clients should be able to perform I/O in their windows, or even
  746. the same window.
  747. Another constraint is that the 8½ files are like devices,
  748. and must not be cached by the client.
  749. NFS cannot honor these requirements; AFS may be able to.
  750. Of course, other interprocess communication mechanisms such as sockets
  751. could be used as a basis for a window system. One may even argue that
  752. X's model fits into this overall scheme. It may prove easy and worthwhile
  753. to write a small 8½-like system for commercial
  754. UNIX
  755. systems to demonstrate that its merits can be won in systems other than
  756. Plan 9.
  757. .SH
  758. Conclusion
  759. .PP
  760. In conclusion, 8½ uses an unusual architecture in
  761. concert with the file-oriented interprocess communication of Plan 9
  762. to provide network-based interactive graphics to client programs.
  763. It demonstrates that even production-quality window systems are not
  764. inherently large or complicated
  765. and may be simple to use and to program.
  766. .SH
  767. Acknowledgements
  768. .PP
  769. Helpful comments on early drafts of this paper were made by
  770. Doug Blewett,
  771. Stu Feldman,
  772. Chris Fraser,
  773. Brian Kernighan,
  774. Dennis Ritchie,
  775. and Phil Winterbottom.
  776. 8½'s support for color was added by Howard Trickey.
  777. Many of the ideas leading to 8½ were tried out in earlier, sometimes less
  778. successful, programs. I would like to thank those users who suffered
  779. through some of my previous 7½ window systems.
  780. .SH
  781. References
  782. .LP
  783. [Duff90] Tom Duff, ``Rc - A Shell for Plan 9 and UNIX systems'', Proc. of the Summer 1990 UKUUG Conf., London, July, 1990, pp. 21-33, reprinted, in a different form, in this volume.
  784. .LP
  785. [Far89] Far too many people, XTERM(1), Massachusetts Institute of Technology, 1989.
  786. .LP
  787. [Gos86] James Gosling and David Rosenthal,
  788. ``A window manager for bitmapped displays and UNIX'', in Methodology of Window Management, edited by F.R.A. Hopgood et al., Springer, 1986.
  789. .LP
  790. [Kaza87] Mike Kazar, ``Synchronization and Caching issues in the Andrew File System'', Tech. Rept. CMU-ITC-058, Information Technology Center, Carnegie Mellon University, June, 1987.
  791. .LP
  792. [Kill84] Tom Killian, ``Processes as Files'', USENIX Summer Conf. Proc., Salt Lake City June, 1984.
  793. .LP
  794. [Pike83] Rob Pike, ``The Blit: A Multiplexed Graphics Terminal'', Bell Labs Tech. J., V63, #8, part 2, pp. 1607-1631.
  795. .LP
  796. [Pike83a] Rob Pike, ``Graphics in Overlapping Bitmap Layers'', Trans. on Graph., Vol 2, #2, 135-160, reprinted in Proc. SIGGRAPH '83, pp. 331-356.
  797. .LP
  798. [Pike87] Rob Pike, ``The Text Editor \f(CWsam\fP'', Softw. - Prac. and Exp., Nov 1987, Vol 17 #11, pp. 813-845, reprinted in this volume.
  799. .LP
  800. [Pike88] Rob Pike, ``Window Systems Should Be Transparent'', Comp. Sys., Summer 1988, Vol 1 #3, pp. 279-296.
  801. .LP
  802. [Pike89] Rob Pike, ``A Concurrent Window System'', Comp. Sys., Spring 1989, Vol 2 #2, pp. 133-153.
  803. .LP
  804. [Pike91] Rob Pike, ``A Minimalist Global User Interface'', USENIX Summer Conf. Proc., Nashville, June, 1991.
  805. .LP
  806. [Pike92] Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, and Phil Winterbottom,
  807. Operating Systems Review
  808. Vol 27, #2, Apr 1993, pp. 72-76
  809. (reprinted from Proceedings of the 5th ACM SIGOPS European Workshop, Mont Saint-Michel, 1992, Paper nº 34, and reprinted in this volume).
  810. .LP
  811. [Pike94] Rob Pike and Ken Thompson, ``Hello World or Καλημέρα κόσμε or \f(Jpこんにちは 世界\fP'', USENIX Winter Conf. Proc., San Diego, Jan, 1993, reprinted in this volume.
  812. .LP
  813. [PLR85] Rob Pike, Bart Locanthi and John Reiser, ``Hardware/Software Tradeoffs for Bitmap Graphics on the Blit'', Softw. - Prac. and Exp., Feb 1985, Vol 15 #2, pp. 131-152.
  814. .LP
  815. [Pres90] David L. Presotto and Dennis M. Ritchie, ``Interprocess Communication in the Ninth Edition Unix System'', Softw. - Prac. and Exp., June 1990, Vol 20 #S1, pp. S1/3-S1/17.
  816. .LP
  817. [Rose88] David Rosenthal, ``A Simple X11 Client Program -or- How hard can it really be to write ``Hello, World''?'', USENIX Winter Conf. Proc., Dallas, Jan, 1988, pp. 229-242.
  818. .LP
  819. [Sche86] Robert W. Scheifler and Jim Gettys,
  820. ``The X Window System'',
  821. ACM Trans. on Graph., Vol 5 #2, pp. 79-109.
  822. .LP
  823. [Sun89] Sun Microsystems, NFS: Network file system protocol specification,
  824. RFC 1094, Network Information Center, SRI International, March, 1989.
  825. .br