What X11 is, and why

If you were born after 2000, you probably never saw a real workstation. You probably never sat down at a Sun-3 or an SGI Indy and watched the OS do six things at once on a network filesystem while your roommate logged into the same machine from the dorm across campus. You probably grew up assuming computers were always good at all of this.

They were not.

This page is about what computers were like before they were good. Specifically: what they were like when X11 was invented, why X11 was a breakthrough, and why a windowing protocol from 1987 is still ticking on most Linux desktops in 2026. It’s also the prequel to the opcode reference on this site. If you came from there and want the byte-level protocol detail, that’s where you read it. If you want the story of why the protocol exists at all, you’re in the right place.

PCs were horrible

The IBM PC came out in 1981. By 1985 it was the standard office computer. Here is a list of things you could not do on it.

You could not run two programs at the same time. MS-DOS was a single-tasking operating system. You ran Lotus 1-2-3, or you ran WordStar, or you ran nothing. The screen belonged to one application at a time. When you wanted to switch, you exited the program, went back to a C prompt, and started the other one.

You could not have multiple windows. The screen was 80 columns by 25 rows of text, or one bitmap if a program happened to know how to draw. There was no window manager. The very concept of a “window” was a research idea.

You could not network easily. The PC shipped with a parallel port for the printer and one serial port for “communications.” An Ethernet card was a several-hundred-dollar add-on, and once you had one, you needed Novell NetWare or a third-party TCP/IP stack to do anything useful with it. There was no built-in idea of a network connection. Most PCs in 1985 never touched a network in their lives.

You could not address more than 640K of memory directly. The IBM PC’s segmented memory model and DOS’s design topped out at 640K. Anything more required “expanded memory” tricks involving page-flipping through a 64K window. These tricks were a dance, not a feature, and most programs couldn’t use the extra memory at all.

You could not recover from a crash. When a program faulted (lots of them did), the whole machine went down. No protected memory. The crash often took your unsaved work with it and sometimes corrupted the filesystem on the way out.

You could not draw a curve, easily. The graphics hardware on a standard PC of 1985 (CGA, then EGA) handled 4 to 16 colors at low resolution, and the OS didn’t help. Every application that wanted graphics shipped its own driver code for every monitor card on the market. Lotus 1-2-3 had a Lotus driver for the Hercules card and another for EGA. AutoCAD shipped a stack of drivers in the box. If your video card wasn’t on the list, the program didn’t run.

There were workarounds. Multitasking shells like DESQview existed. Windows 1.0 shipped in 1985 (the verdict, as best I remember it, was “not yet”). Add-on cards stretched the memory ceiling. Ethernet eventually became cheap. But the baseline experience of a 1985 office PC was one program, one window, no network, 640K of RAM, and a crash that took everything down with it.

This is the world that X11 was not invented for.

Workstations were the real computers

The world X11 was invented for was the Unix workstation. Sun Microsystems shipped the Sun-3 in 1985: a 16 MHz Motorola 68020, four megabytes of RAM standard (more than six times the IBM PC’s 640K ceiling), an Ethernet port on the motherboard, a 19-inch monochrome bitmap display, and BSD Unix. List price was about $9,000 for the base configuration. A loaded Sun-3/260 with color and a big disk ran past $50,000.

For that money, you got a real computer.

Preemptive multitasking. The kernel scheduled processes, and one runaway program could not lock out the rest of the system. You could run a compiler, an editor, and a database client at the same time, and they would all keep going.

Real networking. Ethernet was built in. NFS let you mount a remote disk as if it were local. rlogin let you connect to another workstation and run a shell as if you were sitting in front of it. The Sun-3 in your office and the SGI in the lab were on the same network, and they could talk to each other without you setting any of it up.

Multiple users. Unix workstations were called “workstations” because one person used them at a time, but the OS was the same Unix that ran on shared timesharing machines. Your coworker could log into your box from across the building and start a process on it without you noticing.

Bitmap graphics the OS knew about. Sun’s SunView and SGI’s IRIS GL gave applications a way to draw lines and rectangles and text without writing their own video drivers. The OS owned the screen, the applications asked the OS to draw, and everyone got along.

The catch was that every vendor’s graphics layer was different. Sun apps did not run on SGI workstations. SGI apps did not run on HPs. DEC’s DECwindows was something else again. If you wrote a graphical Unix application, you had to pick a vendor and stay there. The “open” in “open systems” had a long way to go.

The MIT problem

This was the wall MIT Project Athena hit in the mid-80s. Athena was MIT’s plan to put a workstation on every student’s desk and let any student walk up to any machine, log in, and run their software. The catch: Athena had Suns, DECstations, IBM RTs, and a few other things, all with incompatible graphics. Students could not be expected to learn three different windowing systems to take three different classes.

Athena needed a windowing system that ran on every vendor’s hardware, behaved the same way everywhere, and let one student’s program show its windows on another student’s screen across the campus network. They started from a Stanford research system called W, simplified it, and shipped X version 1 in 1984. X10 came in 1985 and got real traction outside MIT. X11 was released in September 1987 and it stuck.

X11 was three things at once.

It was a protocol. Defined down to the byte. Vendors could re-implement the X server on any hardware they wanted and apps written for one server would run on any other. This was the point. Cross-vendor compatibility was the whole problem Athena had to solve.

It was network-transparent. The application and the screen were not the same process and didn’t have to be on the same machine. You set the DISPLAY environment variable, and the program drew on whichever screen DISPLAY pointed at. This was thirty years before “cloud” anything. It just was there.

It was toolkit-agnostic. The protocol drew lines, rectangles, text, and images. Anything richer (a button, a menu, a scrollbar) was a toolkit layered on top, in client code. Xt, Athena widgets, Motif, OpenLook, and later GTK and Qt all sat on X11. The X server did not know what a button was. It just drew the pixels the toolkit told it to.

The client-server split

The shape of X11 is backwards from what most people expect, and it’s the part worth understanding.

In X11, the server is the thing with the screen. It runs on your local workstation, owns the keyboard and mouse, and draws to the bitmap.

The clients are the applications. xterm, xcalc, Emacs, Netscape, whatever you’re running. They connect to the server over the network and send drawing commands.

When you sat down at your Sun-3 in 1990 and ran a CAD program that needed more horsepower than your desktop could deliver, here is what happened. You rlogin’d into the SGI Crimson down the hall, the powerful machine your group bought because nobody could afford one per desk. You set DISPLAY=mysun:0. You ran the CAD program. The program ran on the Crimson. The drawing appeared on your Sun’s screen. The Crimson did not have a screen of its own that anyone was looking at, and your Sun could not have rendered the 3D model fast enough on its own. Everything worked over the Ethernet between them, and the CAD program had no idea any of it was happening.

This was magic in 1990 and it is still kind of magic now. The modern equivalent (a web app’s rendering on a server somewhere, displayed in your browser through a JavaScript bundle) involves vastly more layers, vastly more bytes on the wire, and is only just now starting to feel as smooth as remote X did.

How it works on the wire

X11 is a wire protocol all the way down. When a client sends a request, it puts a one-byte opcode on the socket followed by a length and the request’s arguments. The server reads the opcode, dispatches to the handler that knows how to do that one thing, does the work, and optionally sends a reply back on the same socket. The protocol is asynchronous by default. Requests do not wait for confirmation unless they have a reply, so the toolkit can pipeline hundreds of requests into a single network round-trip while the server is still busy painting.

The core protocol defines 119 opcodes. Real X11R5 and X11R6 servers shipped with another few dozen across the extensions (SHAPE for non-rectangular windows, MIT-SHM for shared-memory image transfer, XKB for the keyboard model, RENDER for antialiased glyphs, and others). Together those opcodes are the entire surface area of the X11 server. Everything any X application has ever done on screen is a sequence of them. If you want to see all of them in one place, the opcode reference lists every single one and where macXserver stands on each.

Why X11 outlived its era

The Unix workstation era ended in the late 90s. Sun, SGI, and DEC didn’t beat the PC; the PC eventually got everything the workstations had. Windows NT brought preemptive multitasking. Ethernet moved to the motherboard. Memory ceilings went away. By 2005 the workstation was dead as a category. SGI was bankrupt. Sun was four years from being eaten by Oracle.

X11 should have died with them.

It didn’t, because Linux happened. Linus shipped Linux 0.01 in August 1991. By the mid-90s Linux was running on cheap commodity PC hardware and people wanted a graphical Unix on it. X11 was sitting right there: free, mature, well-understood. XFree86 packaged it for PCs and it became the standard Linux desktop windowing system. The X.Org Foundation took over maintenance from XFree86 in 2004. X.Org is still shipping releases.

In 2026, X11 is still the default windowing system on most desktop Linux distributions. Wayland is the eventual successor and it’s making real inroads, but X11 is not going away soon. Plenty of professional Unix shops still run pure-X11 setups because they’re battle-tested and because the network-transparency feature still gets used. A research group at a national lab pipes X displays across a thousand-mile fiber link every day.

And there’s a long tail of vintage hardware. Sun-3s and SPARCstations and SGIs are still out there, in someone’s basement or someone’s vintage-computing collection, with their original CRTs and their original SunOS or IRIX installs. They speak X11 the way they always did. They want to talk to something.

Where macXserver fits

macXserver is an X11 server for macOS, written in Swift, that listens for X11 protocol connections and renders the drawing commands as native macOS windows. Plug in a Sun-3 over Ethernet, set its DISPLAY to your Mac’s IP, run xclock, and a round clock window pops up on your Retina display.

That’s the whole project in one sentence: make modern Macs the screen for vintage Unix workstations.

The mechanics live in the opcode reference . If you want to know exactly what the server has to do, byte for byte, that page lists every opcode the X11 protocol defines, every era-correct extension a real vintage workstation expects to see on the wire, and where macXserver currently stands on each.