124 The X-Windows Disaster X: The First Fully Modular Software Disaster X Windows started out as one man’s project in an office on the fifth floor of MIT’s Laboratory for Computer Science. A wizardly hacker, who was familiar with W, a window system written at Stanford University as part of the V project, decided to write a distributed graphical display server. The idea was to allow a program, called a client, to run on one computer and allow it to display on another computer that was running a special program called a window server. The two computers might be VAXes or Suns, or one of each, as long as the computers were networked together and each implemented the X protocol.1 X took off in a vacuum. At the time, there was no established Unix graph- ics standard. X provided one—a standard that came with its own free implementation. X leveled the playing field: for most applications every- one’s hardware suddenly became only as good as the free MIT X Server could deliver. Even today, the X server still turns fast computers into dumb terminals. You need a fairly hefty computer to make X run fast—something that hard- ware vendors love. The Nongraphical GUI X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these pro- grams have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and- paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down? 1We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relation- ships, the server is the remote machine that runs the application (i.e., the server pro- vides services, such a database service or computation service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.” We’re going to follow X terminology when discussing graphical client/servers. So when you see “client” think “the remote machine where the appli- cation is running,” and when you see “server” think “the local machine that dis- plays output and accepts user input.”

X: The First Fully Modular Software Disaster 125 Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to pur- chase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn’t get all of those ugly fonts. It’s a trade-off. The Motif Self-Abuse Kit X gave Unix vendors something they had professed to want for years: a standard that allowed programs built for different computers to interoper- ate. But it didn’t give them enough. X gave programmers a way to display windows and pixels, but it didn’t speak to buttons, menus, scroll bars, or any of the other necessary elements of a graphical user interface. Program- mers invented their own. Soon the Unix community had six or so different interface standards. A bunch of people who hadn’t written 10 lines of code in as many years set up shop in a brick building in Cambridge, Massachu- setts, that was the former home of a failed computer company and came up with a “solution:” the Open Software Foundation’s Motif. What Motif does is make Unix slow. Real slow. A stated design goal of Motif was to give the X Window System the window management capabil- ities of HP’s circa-1988 window manager and the visual elegance of Microsoft Windows. We kid you not. Recipe for disaster: start with the Microsoft Windows metaphor, which was designed and hand coded in assembler. Build something on top of three or four layers of X to look like Windows. Call it “Motif.”' Now put two 486 boxes side by side, one running Windows and one running Unix/Motif. Watch one crawl. Watch it wither. Watch it drop faster than the putsch in Russia. Motif can’t compete with the Macintosh OS or with DOS/Windows as a delivery platform. Ice Cube: The Lethal Weapon One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the man- tra. That is, the X servers provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good