[TUHS] Re: Earliest UNIX Workstations?

Whilst that is a reasonable assumption, I’m not sure it is true in this case. Bob Scheifler writes in 1986: "We acquired a UNIX-based version of W for the VSlOO (with synchronous communication over TCP [24] produced by Asente and Chris Kent at Digital’s Western Research Laboratory.” It does not say “C based”, but it is quite possible that the Unix port also meant moving to C. Also, the work started in June 1984 and had gone to version 10, release 3 by February 1986. That is 12 versions in 20 months. Most likely X1-X10R2 are all snapshots done in rapid succession. The change notes for X10R3 read as describing a work still in progress: http://www.retro11.de/ouxr/43bsd/usr/src/new/X/CHANGES That “work-in-progress” feel also shows in the Xterm README: "Xterm is in a reasonably usable state. We are sick and tired of working on it, but there are clearly major areas of improvement possible. Do not look to us to do more than integration work on other people's improvement. About 50% of it is the oldest existing code in the package and needing major rewrite. Our thanks to Bob McNamara for the 50% which is solid." The README for the X server itself (written in August 1985 it seems, http://www.retro11.de/ouxr/43bsd/usr/src/new/X/X/README) says: "The server has been completely rewritten several times now, and I am reasonably happy with it. I have fine-tuned it specifically for the current (sub-optimal) VAX compiler. For other machines, faster code may be obtained in some cases by changing sizes (e.g., to avoid indexing shifts on the 68000) or register declarations. Attempts to parameterize along these lines have only been made for the byte-swapping code.” So there were several rewrites from Summer 1984 till Summer 1985. In case the first version was in CLU, it would seem that the change-over to C happened in the very first months of the code base’s lifespan. The next paragraph as to the state of the code base at this time is revealing: Unfortunately, a great many invariants are not written down. Hopefully you will spend a few weeks understanding the code before you muck with it. If something seems easy to add or change, you probably forgot something important. Almost everything depends on everything else. It is almost impossible to devise rigorous test cases. Innocuous looking changes can have large performance effects, so watch out. If you muck with fundamental window components, a good cross-check is to see how quickly you can manipulate a window with, say, 100 non-adjacent subwindows. After reading the above, Jon Steinhart’s post from 5 years ago about X is all the more interesting: https://minnie.tuhs.org/pipermail/tuhs/2017-September/012089.html