Forking this thread as we are now way off the original and very cogent topic, which I would like to see continued. (Very valid to ask about good emulations of early GUI systems like Apollo, LispMs, PERQ, Xerox D* etc)
Peter’s mentions of TRIPOS (which was used on a Sage IV for Amiga Lorraine bring-up) has me renew my ask: If anyone has media for TRIPOS for the Sage/Stride systems please reach out. > On Sep 22, 2020, at 03:02, Peter Corlett via cctalk <cctalk@classiccmp.org> > wrote: > > On Mon, Sep 21, 2020 at 11:29:14PM -0500, Richard Pope via cctalk wrote: >> The Amiga 1000 with AmigaDos and Workbench was released in late 1985. >> AmigaDos is based on Unix and Workbench is based on X-windows. > > Er, no. > > The Amiga's operating system is a pre-emptive multitasking microkernel which > uses asynchronous message-passing betwen subsystems, which is not the Unix way > of doing things at all. Unix provide libraries of synchronous procedure calls > which block the caller until the job is done. > > Although "AmigaDOS" appears prominently in the terminal as one boots > Workbench, > that's only the filesystem and command-line shell. Due to time pressure, they > bought in TRIPOS and filed off the serial number. TRIPOS is a fairly clunky > thing written in BCPL that never sat well with the rest of the system, but it > was quite probably the only DOS they could buy in which worked in a concurrent > environment. TRIPOS is the reason why disks were slow on the Amiga. > > The other bit that got reduced from a grander vision was the graphics, which > became blocking libraries rather than device drivers. The window manager ran > as > its own thread which gave the illusion of responsiveness. > > The "X Window System" (not X-windows or other misnomers) is an ordinary[1] > Unix > process which provides low-level primitives for a windowing system. > "Workbench" > is just an ordinary AmigaDOS process which provides a file manager. You can > even quit it to save memory, and the rest of the GUI still works. They are not > the same thing or "based" on each other at all. > > > [1] Well, some implementations are setuid root or have similar elevated > privileges so they can have unfettered access to the bare metal and thus > tantamount to being part of the kernel, but that's basically corner-cutting > by a bunch of cowboys and it is possible to do this sort of thing properly > without introducing a massive security hole. >