The X Window System quietly hit its 25th anniversary back in June; it is,
one of the oldest and most successful free software projects in existence.
Keith Packard has been working with X for most of that time; at the Linux
Plumbers Conference in Portland he used his keynote address to look at the
highlights (and lowlights) of those 25 years and some of the lessons that
have been learned.
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:
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
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
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.
All of these mistakes notwithstanding, one should not overlook the success
of X as free software.
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
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:
- Publish a protocol specification and promise that there will be
- Realize failure.
- "Accidentally" break things in the code.
- Let a few years go by, and note that nobody has complained about the
- 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
to post comments)