LPC: 25 years of X

The version of X we know today is X11. There were nine predecessor versions (one got skipped), but the first version to escape widely was X10, which was released in 1986. Companies were shipping it, and the vendors which formed the X Consortium were starting to think that the job was done, but the X developers successfully pleaded for the opportunity to make one more "small" set of revisions to the X protocol. The result was X11 - a complete reworking of the whole system - which was released on September 15, 1987; it is still running today.

There was a wealth of new ideas in X11, some of which made more sense than others. One of those ideas was the notion of an external window manager. In X, the window manager is just another process working with the same API. This approach helped to create a consistent API across windows, and it also made it possible to manage broken (non-responding) applications in a way that some other systems still can't do. On the other hand, the external window manager created a lot of on-screen flashing - a problem which still pops up today - and it does not work entirely well with modern compositing techniques, getting in the way of the page-flipping operations needed to make things fast.

The use of selections for cut-and-paste operations was another early X11 innovation. With selections, the source of selected data advertises its availability, and the destination requests it in the desired format. This mechanism allows data to be selected and moved between applications in almost any format. Unfortunately, the "cut buffer" concept was left in, so applications had to support both modes; the fact that Emacs was not updated to use selections for a very long time did not help. The existence of multiple selections created interoperability problems between applications. On the other hand, the selection mechanism proved to be a very nice foundation for drag-and-drop interfaces, and it handled the transition to Unicode easily.

Input has been the source of a number of problems. The requirement that applications specify which events they want made sense when the focus was on trying to make the best use of a network connection, but it led to some interesting behavioral changes depending on how applications selected their events. X was meant to be a policy-free system, but, in retrospect, the rules for event delivery were a significant amount of policy wired into the lowest levels of the system.

"Grabs," where an application can request exclusive delivery of specific events, were a case in point. "Passive grabs" allow window managers to bind to specific keys (think alt-middle to resize a window), but that required a non-intuitive "parent window gets it first" policy when these grabs are in use. "Synchronous grabs" were worse. They were intended to help create responsive interfaces in the face of slow networks and slow applications; clicking on a window and typing there will do the right thing, even if the system is slow to respond to the click and direct keyboard focus correctly. It was a complicated system, hard to program to, harder to test, and it required potentially infinite event storage in the X server. And it's really unnecessary; no applications use it now. This "feature" is getting in the way of more useful features, like event redirection; it may eventually have to be removed even at the cost of breaking the X11 protocol.

Text input was not without problems of its own; X went to considerable effort to describe what was written on every key, and required applications to deal with details like keyboard maps and modifier keys. It worked reasonably well for English-language input, but poorly indeed for Asian languages. The addition of the XIM internationalization layer did not really help; it was all shoved into the Xlib library and required that applications be rewritten. It also forced the installation of a large set of core fonts, despite the fact that most of them would never be used.

Text output was "an even bigger disaster." It required that fonts be resident in the server; applications then needed to pull down large sets of font metrics to start up. That was bad enough, but generating the font metrics required the server to actually rasterize all of the glyphs - not fun when dealing with large Asian fonts. Adding fonts to the system was an exercise in pain, and Unicode "never happened" in this subsystem. In retrospect, Keith says, there was an obvious warning in the fact that neither FrameMaker nor Xdvi - the two applications trying to do serious text output at that time - used the core fonts mechanism.

This warning might have been heeded by moving font handling into clients (as eventually happened), but what was done at that time, instead, was to layer on a whole set of new kludges. Font servers were introduced to save space and make addition of fonts easier. The XLFD (X logical font description) mechanism inflicted font names like:

    -adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1

on the world without making life easier for anybody. The compound text mechanism brought things forward to iso-2022, but couldn't handle Unicode - and, once again, it required rewriting applications.

The X drawing model had amusing problems of its own. It was meant to be "PostScript lite," but, to get there, it dispensed with small concepts like paths, splines, and transforms, and it required the use of circular pens. So there really wasn't much of PostScript left. The model required precise pixelization, except when zero-width "thin" lines were used - but all applications ended up using thin lines. Precise pixelization was a nice concept, and it was easily tested, but it was painfully slow in practice.

The use of circular pens was the source of more pain; the idea was taken from the PostScript "Red Book," but, by then, the PostScript folks had already figured out that they were hard to work with and had kludged around the problem. A line drawn with a circular pen, in the absence of antialiasing, tends to vary in width - it looks blobby. The generation of these lines also required the calculation of square roots in the server, which was not the way to get the best performance. Even so, people had figured out how to do circular pens right, but nobody in the X team knew about that work, so X did not benefit from it.

Rather than provide splines, the X11 protocol allowed for the drawing of ellipses. But there was a catch: ellipses had to be aligned with the X or Y axis, no diagonal ellipses allowed. There was a reason for this: there was a rumor circulating in those days that the drawing of non-axis-aligned ellipses involved a patented algorithm, and, for all of the usual reasons, nobody wanted to go and actually look it up. It turns out that the method had been published in 1967, so any patent which might have existed would have been expired. But nobody knew that because nobody was willing to take the risks involved with researching the alleged patent; even in the 1980's, software patents were creating problems.

As an added bonus, the combination of ellipses and circular pens requires the evaluation of quartic equations. Doing that job properly requires the use of 128-bit arithmetic; 64-bit floating-point numbers were not up to the job.

Color management was bolted on at a late date; it, too, was shoved into the "thin and light" Xlib layer. It provided lots of nice primitives for dealing with colors in the CIE color space, despite the fact that users generally prefer to identify colors with names like "red." So nobody ever used the color space features. And the "color management" code only worked with X; there was no provision for matching colors in output to graphic metafiles or printed output. X color management was never a big hit.

[PULL QUOTE: All of these mistakes notwithstanding, one should not overlook the success of X as free software. END QUOTE] All of these mistakes notwithstanding, one should not overlook the success of X as free software. X predates version 1 of the GPL by some five years. Once the GPL came out, Richard Stallman was a regular visitor to the X Consortium's offices; he would ask, in that persistent way he has, for X to change licenses. That was not an option, though; the X Consortium was supported by a group of corporations which was entirely happy with the MIT license. But in retrospect, Keith says, "Richard was right."

X was an industry-supported project, open to "anybody but Sun." Sun's domination of the workstation market at that time was daunting to vendors; they thought that, if they could displace SunView with an industry-standard alternative, they would have an easier time breaking into that market. Jim Gettys sold this idea, nearly single-handedly, to Digital Equipment Corporation; it is, arguably, the first attempt to take over an existing market with free software. It worked: those vendors destroyed Sun's lock on the market - and, perhaps, Keith noted, the Unix workstation market as a whole.

There were problems, needless to say. The MIT license discourages sharing of code, so every vendor took the X code and created its own, closed fork. No patches ever came back to the free version of X from those vendors. Beyond that, while the implementation of X11 was done mainly at DEC, the maintenance of the code was assigned to the X Consortium at MIT. At that point, Keith said, all innovation on X simply stopped. Projects which came out of the X Consortium in these days were invariably absolute failures: XIE, PEX, XIM, XCMS, etc. There began the long, dark period in which X essentially stagnated.

X is no longer stagnant; it is being heavily developed under freedesktop.org. As X has come back to life, its developers have had to do a massive amount of code cleanup. Keith has figured out a fail-safe method for the removal of cruft from an old code base. The steps, he said, are these:

1. Publish a protocol specification and promise that there will be long-term support.

2. Realize failure.

3. "Accidentally" break things in the code.

4. Let a few years go by, and note that nobody has complained about the broken features.

5. Remove the code since it is obviously not being used.

Under this model, the XCMS subsystem was broken for five years without any complaints. The DGA code has recently been seen to have been broken for as long. The technique works, so Keith encouraged the audience to "go forth and introduce bugs."

The important conclusion, though, is that, after 25 years, X survives and is going strong. It is still able to support 20-year-old applications. There are few free software projects which can make that sort of claim. For all its glitches, kludges, and problems, the X Window System is a clear success.