[TUHS] X and NeWS history (long)

Arthur Krewat writes: Larry McVoy writes: OK, you asked for it. I think that I need to ask the Thing King to zark in a few crates of old memories... I spent mt teenage years as a graphics person as a result of my summer job at Murray Hill working on the Glance-G terminal project. Side-tracked into test and measurement after getting my EE degree and doing cool black magic electronics at Tektronix. Got back into graphics and software when Tek tried to get into the UNIX workstation business. Started working on window systems at that time, and continued after I quit Tek and moved to the bay area to play at the startup game. Started consulting after the third startup failed which I'm still doing today. While at Tek one of my jobs was to come up with a C language binding for GKS, the Graphical Kernel System standard. That itself is a funny story which ties into the earlier troff thread. I designed a language binding and wrote it up. My friend Ed, author of "Real Programmers Don't Use Pascal", worked down the road at GSS (Graphics Software Systems). He told me that "yours looks better than ours, you should bring it to the standards committee". Amazingly enough my management bought off on it, I brought my draft to the Huntsville meeting, and it was adopted as the draft standard. Why? Because we had troff and an Imprint-10! Those were the days when people equated typeset with professional. I recall discussing the issues with the C binding at an ANSI C committee meeting in San Franscisco; probably met some you there. ANSI X3X3 formed a window management subcommittee X3H3.6 somewhere along the line. I moved over there as I was pretty much done with the GKS stuff and the window management end of things was more interesting. Life changed in that committee when the X push happened. But first, a bit on a parallel track. I knew Keith Lantz at Stanford who, if I remember correctly, had a graduate seminar and wanted to talk about window management systems. I came in as a guest lecturer. Partly because of this I became aware of the origins of X as those weren't the days when one could easily just get technical papers on line. For those of you unfamiliar with this, Stanford had developed the V operating system which featured very fast synchronous IPC. I believe that this ran on the original Stanford University Network (SUN) boards. They also developed the W window system which ran on top of V. I'm a bit fuzzy on the continental shift, but I believe that W made the cross country trip to MIT via some sort of DEC connection. Maybe they had funded some of the Stanford research. Gosling and Rosenthal had been working on the Andrew window system at CMU. I don't remember whether or not this was UNIX-based, but one of their early design decisions was to minimize round-trips because they didn't have fast synchronous IPC. Despite this prior art, Scheifler took the W code, ported it to UNIX, and called it X. As one would expect, the performance was terrible. X got stuck at this state, version 10, for a long time. Sun announced NeWS during this stagnant period. Freaked out Apollo, DEC, HP, etc. who got together at DEC's Hamilton Avenue building to plot the "anything but Sun" strategy. They were successful in holding off the adoption of NeWS until they could rewrite X to eliminate many of the synchronous round trips from the protocol resulting in X version 11 which was pretty much completely incompatible with version 10. In many respects Sun botched NeWS politically. Large numbers of businesses relied on applications that ran on Sun's SunView window system which was heavily hooked into the OS and not even remotely portable. They couldn't use NeWS instead of SunView because they were running real businesses. There was no way to run SunView and NeWS at the same time so businesses couldn't run new NeWS-based applications and old SunView applications at the same time. I'm a bit fuzzy here, but the decision to merge X and NeWS was a bad technical solution to a political problem. Sun wanted to be able to say "We have X too." Unfortunately, folks at Sun agreed to do this project without knowing what they were talking about; it got rough when they realized that the NeWS and X graphics models were completely incompatible. Oh, despite all of the hype, there was actually nothing useful that one could do using X at the time. Not being very well socially adjusted, I annoyed a lot of people by going to show floors and looking at X running things like maze and loudly proclaiming "Oh, that's exactly what I do for a living." Somewhere along the line Sun also decided to produce a mostly automated system to convert SunView programs to use X. I think that this was called XView. I remember billing for many a late night to actually get the thing working. One of my other clients at the time was AED (advanced electronic displays). If you were lucky enough to have a color frame buffer in those days it was likely one of theirs. They had a project to build X accelerator boards that plugged into Sun workstations. I think that I got called in because it wouldn't work on the 3/260 which I eventually tracked down to the behavior of the cache that only the 260 had. AED was trying to figure out what to do as the world had changed and frame buffers couldn't compete with workstations. I came up with the idea to make an X server that would run in a SunView window so that companies that relied on SunView applications could run X applications concurrently. We called this XTool in keeping with the SunView application naming scheme. I think that I still have a few "XTool - Safe X for Suns" tee shirts around somewhere. This project unfortunately failed because AED was bought by someone with a "ship it now, that'll force folks to fix the bugs" attitude. XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two. We showed XTool off at some shows. People would come by the booth and ask "how did you get it to run so fast?" Being me, I loudly answered "We cheated. We designed ours first." Turns out that one of these times Keith Packard and Jim Gettys were walking by which resulted in some long-standing animosity. Back to the standards track. Any of you that have done ANSI work know that CBEMA has a one organization, one vote policy. When Scheifler showed up at X3H3.6 all other work stopped and X became a draft standard. Whenever there was a vote everybody would look to see how Bob was voting and voted with him. For political reasons, all of the voting members from X Consortium member companies had been told that they couldn't vote against X for technical reasons. You may also know that one has to pay to be on an ANSI committee. I wrote the ANSI Secretariet and told them that I felt that by having both the X Consortium and their member companies voting violated the spirit of the one organization one vote rule, and that I couldn't justify continuing to pay to be on the committee with this behavior. They took it under advisement. Eventually, public review time came around. I submitted a document containing something on the order of 800 comments. These were pretty repetitious because I had to hit the document one request at a time, but the major themes were: o The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there. o The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added. o The bit encodings should be part of a separate language binding, not part of the functional description. I received a reply from the committee that said "Thank you for you comments." I wrote the ANSI Secretariet and asked "Don't the rules for milestone 9 say that the technical committee must make all reasonable efforts to accomodate public review comments?" The Secretariet wrote the committee. Everybody on the committee from companies such as Sun who had bee prohibited from voting no for technical reasons all jumped up and cried "procedural violation" and voted against forwarding the standard. Scheifler stormed out. I heard later than Scheifler wrote an angry letter to the Secretariet saying "how dare you listen to that one lone consultant when I have the backing of all of these major companies?" The response was "Didn't you read our rules before joining?" Of course, by the time all of this settled out X was entrenched setting back the state of UNIX UI for a long time. A couple of decades ago I bough a Sun Ultra-60 and asked whether it was worth paying for the dual processor version. The answer that I got was "Yes. You need one processor to run X and another for everything else." Wrapping this up, I have a section in the book that I'm writing where I talk about how to design a good API. I pose the question of why none of the original Apple Mac API published in 1985 taking about 1,200 pages is in use today whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is still in use and has been copied by many other systems. I'm sure that everyone on this list knows the answer. X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation." Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls. Wrapping this up on a happy note, some years ago I was hanging out yakking at the Hacker's Conference when this guy I didn't recognize due to hair loss came up to me and said "I'm not going to say that you weren't an asshole because you were, but you were right." It was Keith Packard who was trying to get X running on the OLPC and had run into the issue of clients allocating server memory that couldn't be freed. Been good friends since. Same with Gettys. Well, that's the whole sordid take from my point of view. Hope that you enjoyed it. Jon