Amiga Roots, TRIPOS - Off Topic, was Re: Exploring early GUIs

[null]

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