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

126 The X-Windows Disaster idea at the time (especially if you are in a research community, experiment- ing with different approaches for solving the human-computer interaction problem), it created a veritable user interface Tower of Babel. If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try mak- ing sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week—and that’s before you consider combinations like control-left-but- ton, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view. As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM,” “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communi- cate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session man- agement. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late—by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over back- wards to be backward compatible with the mistakes of the past. The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason that cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and- drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release. In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolu- tions to obsolete nonproblems, a twisted mass of scabs and scar tissue