🚀 go-pugleaf

In article <538@stag.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes:
> In article <3216@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
> >Oh yes, let's get some terms straight.
[ and then I went a bit off the deep end ]

[shells]
> Fair enough, though you don't list "third party" here for the ST. Gulam is
> very powerful, and there's also the CRAFT programming environment.

I tend not to include third party stuff. I haven't found any third-party
shells worth the hassles (incompatibilities with batch files, and stuff).
Are all ST shells batch-file compatible?

[filesystem]
> Actually, I'd say the ST filesystem looks identical to MS-DOS. I suppose
> we can let that slide, since MS-DOS evolved from CP/M anyway...

You're right. It is an MS-DOS derivitive. CP/M-68K was too slow, and rather
than tune it to make it faster they re-did it from scratch. I don't know
if that was a good idea, but it may have been the only option.

[O/S]
> You're being somewhat of a bigot here. An operating system manages system
> resources on behalf of a user, as a most basic definition.

My basic definition of an O/S is that it manages all the resources available
to the user. If it doesn't have a scheduler (i.e., doesn't manage CPU time)
it's not what I'd call an O/S. I waited 6 years for a computer with an O/S,
though I expected that it'd be running UNIX.

> The ST has somewhat more comprehensive a system
> than either the Mac or PC, since it also utilizes memory protection and tries
> to maintain a distinction between user and supervisor mode.

I used to think so, too, but according to people who've done O/S work on the
ST it doesn't have any useful memory protection for multitasking.

> I don't know enough
> about the Amiga to compare, though it obviously must also support these
> features or else the much-crowed-about inherent multitasking would be a crock.

Which features? Amiga programs run in user mode. There is no way, on a bare
68000, to protect programs from each other. Like the ST, the Amiga does
protect the operating system itself.

> Please define library manager. I've seen the Mac resource manager. It's an
> interesting idea, but intolerably slow.

OK. On the Amiga everything is handled by libraries and intertask
communication. All "os calls" are made by calling libraries and sending
messages to tasks (using the message-passing routines in exec.library).
To open a library (say, graphics.library), you call the routine in the
exec.library "OpenLibrary". It returns the base of a jump-table for that
library. Exec.library itself has a jump table with a known address. If
the library you want to use is on disk, it loads it in. When everyone using
a library finally closes it, it's marked as unused and may be purged if
its memory is needed.

> There's a "third party" PD package that implements this on the ST,
> which seems to do the trick very nicely. As such, I find this "none" entry for
> the ST to also be incorrect.

I'm sure you can find third-party PD packages for all these things... but a
developer can't depend on the user having them available... so they have to
keep on duplicating the code.

> You fail to mention MSDOS device drivers. Shame shame shame.

Sorry.

> TOS also allows for TSRs, which is basically what device drivers are.

Not really. On the Amiga a device driver is just another program... but one
that accepts and handles a certain set of packets. 

> what do you mean by "libraries, drivers, and handlers"?

Libraries: see above.
Drivers: These handle physical devices, and are accessed by the dos library.
Handlers: These handle virtual devices, such as the timer or windows (each
	console window is a virtual terminal).

> This would follow, given your assertion that the Amiga has an operating system
> and none of the other machines do, since multi-tasking is a feature of an
> operating system. However, your entries here would tend to conflict with the
> previous entry. Too bad.

Yeh. Well, like I said, I kind of went off the deep end. I was just pissed
at the people who were using the term "operating system" to refer to anything
from a user interface (GEM Desktop, or the Amiga Workbench or CLI), to a file
system (MS-DOS, AmigaDOS), to a programming interface.

> Also, the ST operating system is really more than you would lead others to
> believe. It's called GEMDOS, after all, to imply that the graphics environment
> aspect is really intrinsic to the system as a whole.

This is one of the really amazing things about the ST and the Mac. They started
with what's really an incidental part of an operating system (the user
interface) and made it central to the whole machine. The amount of twisted
logic you send up with is amazing... witness the recent Mac engineer on
comp.sys.next who couldn't understand how UNIX windowing systems (and the
Amiga windowing system, for that matter) handled refresh without involving
the program.

> And though the GEM desktop
> Finally, much of this is only of great import to a hacker. An application user
> doesn't care if GEM is the operating system or if a mouse click will generate
> an asynchronous interrupt to resume a suspended task.

It does make a difference. Like the computer novice, with an Amiga, who didn't
comprehend why someone would *want* a desk acessory... "Can't you just run
your print in the background and click up something else while it's going on?"

> Speed is something that's more commonly talked about, true?

Perceived speed. People don't mind a database taking 10% longer to look
something up if you can still use the computer while it's doing it. WHen
you talk about speed, you're really talking about responsiveness. And the
Amiga is the most responsive machine I have ever used.
-- 
Peter "Have you hugged your wolf today" da Silva  `-_-'  Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net      'U`