🚀 go-pugleaf

In article <3216@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes:
>Oh yes, let's get some terms straight.
>
>		Amiga		ST		Mac		IBM
>
>User		Workbench	GEM Desktop	Finder		COMMAND.COM
>interface	or
>(shell)		CLI

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.

>
>User		Intuition	GEM		Toolbox		none
>interface
>(library)
>
>File system	AmigaDOS	CP/M-68K	MacOS		MS-DOS

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

>
>Operating	Amiga EXEC	none		none		none
>system
>(kernel)

You're being somewhat of a bigot here. An operating system manages system
resources on behalf of a user, as a most basic definition. Since all of these
machines have, at the very least, code to allocate memory, control access to
physical devices, etc., then by definition they do have operating systems,
however limited or primitive. 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 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.

>
>Library		Amiga EXEC	none		Resource	none
>manager						manager

Please define library manager. I've seen the Mac resource manager. It's an
interesting idea, but intolerably slow. I suppose it corresponds to the Apollo
library manager, or MACH's shared libraries. Dynamic linking is definitely a
nice thing. 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.

>
>Operating	Libraries	D/As		D/As		TSRs
>system		Drivers				Resources
>extensions	Handlers

You fail to mention MSDOS device drivers. Shame shame shame. TOS also allows
for TSRs, which is basically what device drivers are. Just because the folks
at Atari aren't pointing things out to your attention doesn't mean they don't
exist. In this case, I think your own words are somewhat appropriate -
"programming an ST is like programming a PC." The same techniques, or ideas at
least, apply. I suppose, before going much further, you should also define
your terms some more - what do you mean by "libraries, drivers, and handlers"?
I'm assuming you're using terms specific to Amiga parlance, and not just the
usual meanings of "device driver," in which case I would say "driver" and
"handler" were synonymous.

>
>Multitasking	Inherent	Third party,	Multifinder	Windows
>				partial.	Switcher	Third party,
>								partial.

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.

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. And though the GEM desktop
is simply a user interface, the Graphics Envuironment Manager is really a part
of the operating system, and performs ("partial") multitasking management.
Inherently. I grant you that it's very limited, but it provides most of the
features one would expect from a full multi-user multitasking system, including
IPC primitives and job control.

Not to say that things are all perfect or wonderful in the ST world, but they're
certainly as crippled as you make things sound. There's a lot of delay loops in
TOS that would have to be rewritten before it could handle multitasking more
flexibly. There are lots of things I'd like it to do that it doesn't, but it's
not impossible to implement these by oneself.

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. And for programming, there
are few systems I've seen that provide a more powerful and flexible environment.
Sure, it irks me that I can't pop up Uniterm while I'm compiling something. Big
deal, it doesn't take very long to compile stuff anyway. Fast filesystems are
nice that way. That's also an interesting point you fail to summarize in your
table - the ST and PC disk I/O are probably the fastest around. I'd venture to
say the Amigas comes in next, and the Mac last, though the Mac may very well be
faster for all I know. (I *know*, for a fact that the ST disk I/O is faster than
the Amigas. Even with identical devices, like a freshly formatted Quantum 80S.)
Even my Sun 3-260 with SMD disk controller is hard pressed to deliver the same
kind of performance. (On second thought, no, it zips along pretty well too.)

Speed is something that's more commonly talked about, true? I mean, speed is
noticed by anyone, hacker or application user. And while an ST may not be
faster than an AT clone with 20MHz 80286 installed, it's easily the fastest
of the three (ST, Mac, Amiga). I suppose I could spend the bucks for an Amiga
2000 with 68020, but I'd still be stuck with a machine with slow disks... (And
when you're compiling code, it's disk speed that matters, unless you happen to
be using Turbo C or something...)

>-- 
>Peter "Have you hugged your wolf today" da Silva  `-_-'  Hackercorp.
>...texbell!sugar!peter, or peter@sugar.uu.net      'U`

Sorry for the length...
--
  /
 /_ , ,_.                      Howard Chu
/ /(_/(__                University of Michigan
    /           Computing Center          College of LS&A
   '              Unix Project          Information Systems