When windows were not as transparent as they could be: Happy Birthday - X Window System!
Paw Prints: Writings of the maddog
June 19th, 2014 was the thirtieth anniversary of the announcement of the X Window System. Whether you hate it or love it, the X Window System has been a long-lasting contribution to the computing marketplace.
By the time I first saw the X Window System, Project Athena (a project sponsored by Digital Equipment Corporation, MIT and IBM) brought it a long way. MIT was developing version 10 of the system, and I was working as an Engineer at Digital for a group called Customer Services Systems Engineering (CSSE). Our group's job was to try to make our Unix products easier to maintain and use for the field people as well as the customers.
It was a heady time in the Unix world. The Unix “wars” were heating up, and various network-based file systems were trying to compete with Sun's Networked File System (NFS) while various windowing systems were also facing off against each other (Sun's NEWS versus the X Window System).
I remember going down to MIT to visit Project Athena. We had a lent them a couple of our newer, unannounced systems to help with the porting work, and we were a little concerned that the ETHERNET of the day (a whopping 10 Megabits/second) would be able to handle all the traffic being put on the wire with NFS and the X Window System at the same time.
We went to MIT's lab and found the students working on the systems in a locked closet. It was not just the systems in the locked closet, the students were in there too. People took non-disclosure agreements seriously in those days (at least MIT did) and the students were made to do all of their work in the closet, which was fortunately air conditioned. We also found that having the X Window System on the ETHERNET with NFS and some other protocols did not appreciably slow down the NFS throughput, nor did NFS seem to block or detain the X Window System, so life was good.
Of course this was the X Window System back in the days before any real 3D work, before any desktops, before any tool kits for creating button boxes, scroll bars or radio buttons. Everything you saw on the screen you had to create yourself. The X Window System was just that, a system for putting up windows, moving windows, resizing windows, with a bit of font selection thrown in. There was an X-server, a library of “X” calls, and several different window managers. There were no “GPU”s, and few “accelerated” graphics boards. Much of what was rendered on the screen was done by the main CPU putting bits into a “dumb frame buffer”.
On the east coast we were trying to ship our first X Window System product, based on X Version 10. As a CSSE person, it was part of my job to read the documentation and see if it was good enough for customers and field service people to read and to figure out how to use the hardware and software. If the documentation was not good enough, there would be more calls to our support lines and support costs would go up.
One of the documentation people was writing the programming guide for the X Window System. He would write a bit of information, then take it to the engineers to see if they agreed with what he had written. He would ask questions of the engineers, but not get very much information back. Eventually he put out a very thin manual which supposedly told how to program the X Window System, and this was packaged up for the first release.
I read the book, but could not really understand how the system worked. I went to the project leader and asked him if this book would be enough in his estimation, and he scoffed at me and said that any graphics engineer would be able to figure out the programming model from that book.
We were, of course, in a hurry to get the system to market, and so all of us were very busy.
After the system shipped, and things calmed down a bit, I decided to take the manual and try to write a simple program of my own that used the X Window System. I started reading the manual....and I read....and read....and read. I wrote many programs, none of which put even a single window up on the screen. Eventually, after about two weeks of trying (over 80 hours), I was about to quit when I hit Control-C on my workstation and a flash appeared for a fraction of a second on the screen.
It was then that I remembered a concept of “filling a buffer and flushing it”, and it occurred to me that perhaps some of my programs had been working fine, but I had never “flushed” the data out to the screen. I started putting in xflush() calls, and things started working.
It had taken me over 80 hours to write my first X Window System program. I had learned quite a bit in those 80 hours (including a few new curse words), and having seen my first window up on the screen, I decided to add a border to it....only taking me 40 hours more. Then a background.....20 more hours. Then a repeated pattern.....10 more hours. Eventually I had created about fifty “example” programs, building up from just attaching and opening the display to creating designs and text on the screen, each one building on the ones before, fully commented, with commentary on how to use the newest function and what it did. I put all of them into a directory and started formulating a set of slides around them.
I wanted to get the examples out to the field and educational people, but I felt I needed some more examples. That weekend I was to go skiing with a group of friends for a long weekend, and not wanting to miss out on their company (I had already paid my share of the costs), I took along a MicroVAX computer running Ultrix and a VT100 character cell terminal. With that I wrote the last 25 example graphics examples, and got them to compile and link. I could not test them without a graphics screen, but I did that when I got back to the office on Monday. All but one of the 25 additional example programs worked as I thought they should. I fixed the last one and bundled them up.
I soon found that my example programs were in great demand. Field people, educational people and people creating courses for customers all wanted a copy of them, which I gave freely of course.
The most interesting request came from the same engineer who had told me that the programming book was “easy to use”. He wanted them for a new employee who was going to be joining the group, a woman who had an advanced degree in computer graphics. I emailed her the examples.
Later the woman came to me and thanked me for giving her the examples. I told her I was glad that I could help, but I had been told that the programming guide was “good enough” for experienced graphics programmers. She answered with the longest string of curse words I have ever heard from a woman at one time and ended up with “.....that book!”.
It was the last time I ever trusted an engineer to tell me when the documentation was "good enough".
Carpe Diem!comments powered by Disqus
Mozilla’s product think tank sinks silently into history.
TODO group will focus on open source tools in large-scale environments.
New tool will look like GParted but support a wider range of storage technologies.
New public key pinning feature will help prevent man-in-the-middle attacks.
Carnegie Mellon researchers say 3 million pages could fall down the phishing hole in the next year.
The US government rolls new best-practice rules for protecting SSH.
Klaus Knopper announces the latest version of his iconic Live Linux system.
All websites that use these popular CMS tools could be vulnerable to denial of service attacks if users don't install the updates.
According to a report, many potential victims of the Heartbleed attack have patched their systems, but few have cleaned up the crime scene to protect themselves from the effects of a previous intrusion.
DARPA and NICTA release the code for the ultra-secure microkernel system used in aerial drones.