X Myths 139 The color situation is a total flying circus. The X approach to device inde- pendence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many dif- ficult questions: Server: What is your Display? Client: display = XOpenDisplay("unix:0") Server: What is your Root? Client: root = RootWindow(display,DefaultScreen(display)) Server: And what is your Window? Client: win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1, BlackPixel(display,DefaultScreen(display)), WhitePixel(display,DefaultScreen(display))) Server: Oh all right, you can go on. (client passes) Server: What is your Display? Client: display = XOpenDisplay("unix:0") Server: What is your Colormap? Client: cmap = DefaultColormap(display, DefaultScreen(display)) Server: And what is your favorite color? Client: favorite_color = 0 /* Black. */ /* Whoops! No, I mean: */ favorite_color = BlackPixel(display, DefaultScreen(display)) Client: /* AAAYYYYEEEEE!!*/ (client dumps core and falls into the chasm) Server: What is your display? Client: display = XOpenDisplay("unix:0") Server: What is your visual? Client: struct XVisualInfo vinfo if (XMatchVisualInfo(display,DefaultScreen(display), 8, PseudoColor, &vinfo) != 0) visual = vinfo.visual Server: And what is the net speed velocity of an XConfigureWindow request? Client: /* Is that a SubStructureRedirectMask or * a ResizeRedirectMask? */ Server: What?! how am I supposed to know that? Aaaauuuggghhh!!!! (server dumps core and falls into the chasm)

140 The X-Windows Disaster X Graphics: Square Peg in a Round Hole Programming X Windows is like trying to find the square root of pi using roman numerals. —Unknown The PostScript imaging model, used by NeWS and Display PostScript, solves all these horrible problems in a high-level, standard, device indepen- dent manner. NeWS has integrated extensions for input, lightweight pro- cesses, networking, and windows. It can draw and respond to input in the same arbitrary coordinate system and define window shapes with Post- Script paths. The Display PostScript extension for X is intended for output only and doesn’t address any window system issues, which must be dealt with through X. NEXTSTEP is a toolkit written in Objective-C, on top of NeXT’s own window server. NEXTSTEP uses Display PostScript for imaging, but not for input. It has an excellent imaging model and well- designed toolkit, but the Display PostScript server is not designed to be programmed with interactive code: instead all events are sent to the client for processing, and the toolkit runs in the client, so it does not have the low bandwidth, context-switching, and code-sharing advantages of NeWS. Nevertheless, it is still superior to X, which lacks the device-independent imaging model. On the other hand, X’s spelling has remained constant over the years, while NeXT has at various times spelled their flagship product “NextStep,” “NeXTstep,” “NeXTStep,” “NeXTSTEP,” “NEXTSTEP,” and finally “OpenStep.” A standardized, consistent spelling is certainly easier on the marketing ’droids. Unfortunately, NeWS and NEXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude.