Build your own X: project-based programming tutorials

There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly.

https://news.ycombinator.com/item?id=6864364

"For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm

John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)

https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047...

https://news.ycombinator.com/item?id=15325226

>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.

>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.

>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.

>The bit encodings should be part of a separate language binding, not part of the functional description.

>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.