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