Tuesday, July 2, 2024

X Window System At 40

X11R1 on Sun
Techfury90 CC0
I apologize that this post is a little late. On 19th June the X Window System celebrated its 40th birthday. Wikipedia has a comprehensive history of the system including the e-mail Bob Scheifler sent announcing the first release:
From: rws@mit-bold (Robert W. Scheifler)
To: window@athena
Subject: window system X
Date: 19 June 1984 0907-EDT (Tuesday)

I've spent the last couple weeks writing a window
system for the VS100. I stole a fair amount of code
from W, surrounded it with an asynchronous rather
than a synchronous interface, and called it X. Overall
performance appears to be about twice that of W. The
code seems fairly solid at this point, although there are
still some deficiencies to be fixed up.

We at LCS have stopped using W, and are now
actively building applications on X. Anyone else using
W should seriously consider switching. This is not the
ultimate window system, but I believe it is a good
starting point for experimentation. Right at the moment
there is a CLU (and an Argus) interface to X; a C
interface is in the works. The three existing
applications are a text editor (TED), an Argus I/O
interface, and a primitive window manager. There is
no documentation yet; anyone crazy enough to
volunteer? I may get around to it eventually.

Anyone interested in seeing a demo can drop by
NE43-531, although you may want to call 3-1945
first. Anyone who wants the code can come by with a
tape. Anyone interested in hacking deficiencies, feel
free to get in touch.
Scheifler was right that it was a "good starting point for experimentation", but it wasn't really a usable window system until version 11 was released on 15th September 1987. I was part of the team that burned the midnight oil at MIT to get that release out, but my involvement started in late 1985.

Below the fold are some reflections on my contributions, some thoughts on the astonishing fact that the code is still widely deployed after 40 years, and some ideas on why it has been so hard to replace.

Involvement

I arrived at Sun in September 1985 to work with James Gosling on a window system for Sun's workstations. We had worked together developing the window system for Carnegie-Mellon's Andrew project. We both realized that, if Unix and Unix workstations like Sun's were to succeed, they had to have a widely adopted window system. Ideally, we thought, it would have three key attributes:
  • An imaging model at a higher level than simply a grid of pixels, so that applications didn't have to adapt to varying screen resolutions. The clear favorite was Adobe PostScript's, which had appeared on the Apple LaserWriter in January 1985.
  • Networking, so that applications could run wherever it made sense with their user interface where the user was. In the mid-80s both workstations and networks were slow, running a window system was a big load on a Motorola 68000. Having two CPUs working on an application, the client-server model, helped.
  • Programmability, because it was hard to provide a good user experience if there was a slow network round-trip required for each response to a user action. If the window system were programmable, the code that responded to the user's actions could run on the user's workstation, eliminating the network round-trip.
Gosling had left C-MU some months earlier. He was adamant that it was possible to implement PostScript on a 68000 fast enough to be a window system. Adding networking, mouse and keyboard extensions to PostScript would satisfy all three of our requirements. Because Adobe's PostScript in the 68000-based LaserWriter was notoriously slow I was skeptical, but I should have known better than to doubt his coding skills. A couple of months later when Gosling showed me a prototype PostScript interpreter running incredibly fast on a Sun/1, I was convinced to join him on what became the NeWS project.

Once at Sun I realized that it was more important for the company that the Unix world standardized on a single window system than that the standard be Sun's NeWS system. At C-MU I had already looked into X as an alternative to the Andrew window system, so I knew it was the obvious alternative to NeWS. Although most of my time was spent developing NeWS, I rapidly ported X version 10 to the Sun/1, likely the second port to non-DEC hardware. It worked, but I had to kludge several areas that depended on DEC-specific hardware. The worst was the completely DEC-specific keyboard support.

Because it was clear that a major redesign of X was needed to make it portable and in particular to make it work well on Sun hardware, Gosling and I worked with the teams at DEC SRC and WRL on the design of X version 11. Gosling provided significant input on the imaging model, and I designed the keyboard support. As the implementation evolved I maintained the Sun port and did a lot of testing and bug fixing. All of which led to my trip to Boston to pull all-nighters at MIT finalizing the release.

My involvement continued after the first release. I was the editor and main author of the X Inter-Client Communications Conventions Manual (ICCCM) that forms Part III of Robert Scheifler and Jim Gettys' X Window System. A user's X environment consists of a set of client applications, an X server managing displays and input devices, and a window manager application implementing a user interface that allows the user to allocate the server's resources such as windows to the clients. The window manager needs to communicate the resource allocations to the clients, and the clients need to communicate between themselves to support, for example, cut-and-paste. The ICCCM explains its scope thus:
Being a good citizen in the X Version 11 world involves adhering to conventions that govern inter-client communications in the following ares:
  • Selection mechanism
  • Cut buffers
  • Window manager
  • Session manager
  • Manipulation of shared resources
  • Device color characterization
This part of the book proposes suitable conventions without attempting to enforce any particular user interface.
xkcd 2730
There is a certain justice in The UNIX-HATERS Handbook's description of my efforts:
one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” ... It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. 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 backwards to be backward compatible with the mistakes of the past.
Jim Morris, who ran the Andrew project at C-MU, was very wise about what we were getting into: "We're either going to have a disaster, or a success disaster". He often added: "And I know which I prefer!". Jim was exaggerating to make two points:
  • Being a success didn't mean the problems were over, it meant a different set of problems.
  • Ignoring the problems of success was a good way of preventing it.
X11 was definitely a "success disaster".

Why X not NeWS?

NeWS Xardox
Public Domain
NeWS was amazing technology, providing each of our requirements with usable performance on a 68000. Its interpreter was a clean-room implementation of PostScript from the "BlueRed Book", with extensions that provided cooperative multi-threading, networking, arbitrary-shaped translucent windows, and a fully object-oriented toolkit. Steve Jobs agreed with us that PostScript was the right imaging model, although the Display PostScript interpreter he licensed from Adobe for the NextSTEP window system was far more restricted. The overwhelming success of JavaScript has validated our argument for programmability. So why did X11 take over the world? My view is that there are three main arguments, any one of which would have been decisive:
  • We and Jobs were wrong about the imaging model, for at least two reasons. First, early on pixels were in short supply and applications needed to make the best use of the few they were assigned. They didn't want to delegate control to the PostScript interpreter. Second, later on came GPUs with 3D imaging models. The idea of a one-size-fits-all model became obsolete. The reason that Wayland should replace X11 is that it is agnostic to the application's choice of imaging model.
  • Although we were right about the need for programmability, PostScript was the wrong language. Even back in 1985 Gosling and I were veteran programmers, with experience in many languages including not just C and Assembler, but also LISP, Prolog and Smalltalk. We didn't find PostScript's stack-based language intimidating. But already by that time Darwinian evolution had focused CS education on C-like languages, so the majority of application programmers were intimidated. And NeWS wasn't just stack-oriented, it was also object-oriented and multi-threaded, and none of these were optional, making it even more intimidating. In a sense NeWS was an echo of the success of Sun in the early days — a bunch of really good engineers building the system they wanted to use, not one for the mass market.
  • A major reason for Sun's early success was that they in effect open-sourced the Network File System. X11 was open source under the MIT license. I, and some of the other Sun engineers, understood that NeWS could not displace X11 as the Unix standard window system without being equally open source. But Sun's management looked at NeWS and saw superior technology, an extension of the PostScript that Adobe was selling, and couldn't bring themselves to give it away. But they also couldn't ignore the fact that X11 was popular with their customer base, who could run the MIT X11 environment any time they wanted. The result was the ghastly kludge called the Xnews server, a monument to the inability of Sun to follow McNealy's "all the wood behind one arrow" dictum. Wikipedia correctly notes that:
    This seriously degraded the NeWS interpreter performance and was not considered a very good X11 server either.

Longevity

The anniversary bought forth several commentaries on its extraordinary longevity, including:
  • Richard Speed's The X Window System is still hanging on at 40 is aptly subtitled "Never underestimate the stickiness of legacy technology" and concludes:
    In 2022, we wondered if "Wayland has what it takes to replace X." Two years later, the question is still open, although the direction of travel is clear. Yet the stickiness of "it just works" is not to be underestimated, and we would not be surprised if the 50th anniversary rolls around and there is still someone clinging to X11 for that one old app that won't run properly on anything else.
    This is very likely. In order to displace X11, Wayland had to be compatible with it via the XWayland server. So there is little motivation to rewrite existing applications to use Wayland directly.
  • Kevin Purdy's 40 years later, X Window System is far more relevant than anyone could guess starts:
    Often times, when I am researching something about computers or coding that has been around a very long while, I will come across a document on a university website that tells me more about that thing than any Wikipedia page or archive ever could.

    It's usually a PDF, though sometimes a plaintext file, on a .edu subdirectory that starts with a username preceded by a tilde (~) character. This is typically a document that a professor, faced with the same questions semester after semester, has put together to save the most time possible and get back to their work. I recently found such a document inside Princeton University's astrophysics department: "An Introduction to the X Window System," written by Robert Lupton.

    X Window System, which turned 40 years old earlier this week, was something you had to know how to use to work with space-facing instruments back in the early 1980s, when VT100s, VAX-11/750s, and Sun Microsystems boxes would share space at college computer labs. As the member of the AstroPhysical Sciences Department at Princeton who knew the most about computers back then, it fell to Lupton to fix things and take questions.
    I really like Lupton's assessment:
    "It worked, at least relative to the other options we had," Lupton said. He noted that Princeton's systems were not "heavily networked in those days," such that the network traffic issues some had with X weren't an issue then. "People weren't expecting a lot of GUIs, either; they were expecting command lines, maybe a few buttons... it was the most portable version of a window system, running on both a VAX and the Suns at the time... it wasn't bad."
    Purdy quotes Evan Jenkins from thirteen years ago:
    X is the oldest lady at the dance, and she insists on dancing with everyone. X has millions of lines of source, but most of it was written long ago, when there were no GPUs, and no specialized transistors to do programmable shading or rotation and translation of vertexes. The hardware had no notion of oversampling and interpolation to reduce aliasing, nor was it capable of producing extremely precise color spaces. The time has come for the old lady to take a chair.
There hasn't been an official release of X11 for twelve years, but it is proving very hard to kill off.

12 comments:

Superkuh said...

X11 will outlive all the various incompatible waylands if only because the waylands architecture was designed, and continues to be designed, in a way that is completely incompatible with screen readers for the blind. No wayland exists that can be used by a blind or otherwise disabled person. It's been like this for 9 years now.

Eric Lease Morgan said...

I used X just this morning. 'Works great! If it is not broken, then don't fix it. Thanks for the posting. --Eric Lease Morgn

don said...

No unified release for 12 years because that's not how they've done it for 12 years. As clearly indicated on their release page, the individual components now have releases when relevant, and their email list for that purpose remains active, with a few releases a month.

thx1111 said...

Wayland Protocol, without some intrinsic concept of "network communication", may be dependent upon Xwayland forever. And, while Wayland Protocol does have some concept of a Linux "seat", it is not apparent that it has any clear distinction between "incoming devices" and "outgoing devices" which might be embodied by completely different computer systems. In the "Internet of Things", the "user input device" may not at all be "wired to" the "user display server". I say that despite the currently atrocious user interface provided for "casting" the display from a Smart Phone to a TV. "Cast the display to this room. Cast the display to that room." The display server moves, while the user input device stays the same, especially when that user input device might be an "AI agent" with voice recognition. Wayland Protocol, ironically, seems designed for a time gone by.

Paul McJones said...

You say, "Its interpreter was a clean-room implementation of PostScript from the 'Blue Book', ... ". The Blue Book is the PostScript Language Tutorial and Cookbook; the Red Book is the PostScript Language Reference Manual.

Has the NeWS source code ever been released?

David. said...

Paul, thanks for the correction. I looked for my copies but couldn't find them because many of my books are in boxes right now, so I was working from memory.

Matt Belge said...

This post is fun for me to see, as in 1988 I had the job of helping my employer devise a strategy for creating applications that could run on PCs, Macs, and Unix workstations. At first we were looking at Apollo as the target, but soon realized Sun and X-Windows was a much better target because it was closer to a standards based system. I pored over whatever X Windows guidelines I could get at the time. Thank you for an incredible, and long lasting contribution to the world of network computing !

thx1111 said...

Comparing Xorg to Wayland presents a challenge in that the terminology of comparison requires lingo and jargon that may not have the same connotations for everyone. Even then, related terms of comparison attempt to emphasize particular but different distinctions. A useful analysis of Wayland by de-facto `mpv` Wayland developer "Dudemanguy" describes a fundamental distinction between X and Wayland as "mechanism" vs "policy". See "Wayland Isn't Going to Save The Linux Desktop", June 10, 2022, https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html And, while a two year old review of Wayland might be suspect as out of date, the 2008 September initial release of the Wayland Protocol itself was almost 16 years ago now. This "mechanism" vs "policy" distinction is closely related to Eric Raymond's "bazaar" vs "cathedral" distinction, particularly with respect to Eric's introductory characterization, "delegate everything you can, be open to the point of promiscuity", which, in fact, may serve as a very good summary of precisely what Wayland does *not* do. In contemporary terms, these distinctions are similarly related to the now prominent "democracy" vs "autocracy" distinction.

Another useful analysis of Wayland is embodied in this graphic from "Skullnet" at https://imgur.com/AIvLISX which illustrates the fragmentation consequent of Wayland's stubbornly narrow ideology, resulting in competing and incompatible implementations of the Wayland Protocol.

Oddly, what is missing from the Wayland Protocol serves to illuminate also what is missing from the X Window System. Perhaps the major fault of the Wayland design philosophy is the juvenile security model it imposes, by failing to distinguish and apply "permission levels" and "access control lists" to "application windows", and instead, policing screen real estate sort of the way North Korea polices access to foreign pop culture. Of course, the other glaring omission from the X Window System, given now 40 years after its inception, is the lack of an integrated compositor. It might be said that the job of the "X server" is to manage the display hardware, including its multiplicities, color spaces, pixel densities, and "accessibility" alternatives, and the job of the "X compositor" would be to manage the "application windows", including their individual Access Control Lists and network abstractions.

Even though the man page at Xserver(1) readily admits that "The X protocol intrinsically does not have any notion of window operation permissions or place any restrictions on what a client can do; if a program can connect to a display, it has full run of the screen.", an integrated "X compositor" could address both this current lack of a compositing standard and this lack of an advanced security model in the existing X Window System.

An overwhelming advantage in extending Xorg's existing X Window System implementation is its obvious compatibility with legacy X Window System applications - and its 40 years of "user testing". In an ideal world, perhaps some courageous and compassionate person might extend the X Window System to include this integrated "X compositor", and then we could all get on peacefully with our lives.

mtp said...

Hi David,

Thank you for this nice article. I am wondering if you could provide some insights into the history of the root window stipple (pattern) that the X Window System featured (since at least X10R3) called "root_weave." When did this pattern come into existence? And who designed it? Are there any interesting stories about it or the other bitmaps that X featured?

Kind regards,

Matt

David. said...

Another illustration of how hard it is to displace a network protocol that "just works" from Dan Goodin's Hackers can use new Blast-RADIUS attack to breach a huge number of networks:

"The purpose of RADIUS is to provide centralized authentication, authorization, and accounting management for remote logins.

The protocol was developed in 1991 by a company known as Livingston Enterprises. In 1997 the Internet Engineering Task Force made it an official standard, which was updated three years later. Although there is a draft proposal for sending RADIUS traffic inside of a TLS-encrypted session that's supported by some vendors, many devices using the protocol only send packets in clear text through UDP (User Datagram Protocol).

Since 1994, RADIUS has relied on an improvised, home-grown use of the MD5 hash function.
...
“Surprisingly, in the two decades since Wang et al. demonstrated an MD5 hash collision in 2004, RADIUS has not been updated to remove MD5,” the research team behind Blast RADIUS wrote in a paper published Tuesday and titled RADIUS/UDP Considered Harmful."

David. said...

Matt Proud has an excellent deep dive into the Iconography of the X Window System: The Boot Stipple. Go read it.

X11 said...

I wish the development of the latest linux graphics stack took lessons from X11, instead it seems they took most of the inspiration from android. Maybe not initially but over the years this is undeniably the case. Unfortunately there is no mega company to unify the direction we are all taking, even the standardization attempts like wlroots seem to be splitting. So X11 even after all this time might be the thing uniting all desktop unices.