Article-I.D.: caip.1041
Posted: Mon Jan 20 18:09:09 1986
Date-Received: Thu, 23-Jan-86 09:02:26 EST
Sender: daemon@caip.RUTGERS.EDU
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 128
From: Dawn Banks
Some comments on Amiga DOS (and related software) prompted by earlier mail
asking for opinions. Maybe a bit long winded, but please don't construe it as
a flame, as it's not intended as one. Mostly, this is my [boring] contribution
to the ongoing dialog on what we'd like to see in Amiga DOS.
First, compared to OS/9 running on a Trash Color, the multitasking on Amiga DOS
is a lose. Not that it isn't useful, as I probably make more use of the
multitasking than the Amiga folks probably intended me to. Part of this
problem stems from the fact that our 512K Amiga system is basically a memory
starved machine; a comment I wouldn't have thought I'd be making a few months
ago, coming from a 48K Atari 800 and a 64K CoCo.
For instance, the linker is slow. Given multitasking, that doesn't bother me
too much, because I can go edit something else (or print something, or play
something) while the link is running, right? Well, not quite, because the
linker is also a memory pig when it links C programs. The lack of speed, and
the abuse of memory are particularly odd, because if you read through the
documentation, you'll find that it doesn't really DO that much. The net result
is that if I have anything significant running while the linker's doing its
thing, or if I have anything significant in the RAM: device, we run out of
memory. So, I have to sit there, watching the linker polish a floppy for a
couple of minutes, emulating a non-multitasked machine. I think ALINK is
reading all of the libraries into memory, which it doesn't really need to do.
I'm gonna have to play with this one some more.
The load file format precludes any reasonable possibility of swapping or
shuffling. Maybe to be more specific, unlike OS/9 running on a 6809, load
files aren't assumed to be position independent code. This means that once the
Amiga DOS load file has been put into memory, it's pretty well "stapled" down
to where it's been loaded with all the absolute references fixed up to reflect
the location where the module was loaded. This is not really bad in and of
itself, but it would be nice to swap tasks given ALINK's thirst for memory.
OS/9 gives you "sharable" segments, by which two people using the same segment
are really using the same segment. Not only does it allow you to save memory
while running multiple copies of something (most notably, the SHELL, of which
there always seem to be at least two invocations), but it also allows you to do
cute things. The best one is permanently incrementing the use count on the
segment so that it never gets purged from memory. Then, when you run that
program, it just looks in the task header to see how much impure storage it
wants, allocates the memory, bumps the shared segment's use count, and you're
all set. Don't have to ding the disk a bit. Later, if you want the memory
back, you can UNLINK the module, which just decrements the use count, so that
it'll get thrown out when everyone's done with it. Amiga DOS does this
completely in reverse: If you want to run something a bunch of times, and
don't want to wait around for the disk read (or can't wait around, 'cause the
disk isn't mounted), you have to copy the task into RAM:, and run it from
there. This is the most insidious form of memory waste I've seen, in that once
you run it from RAM:, you're carrying around TWO copies in memory, instead of
just one (the one you're running, and the one in RAM:).
I've been playing around with the idea of implementing programs as loadable
libraries, with "stub" programs that are run in response to a command. This
stub would open the library, and call the appropriate entry point with all the
command line arguments. Thus, you'd have code sharability and some primitive
form of caching in core copies of commands. The only bad part of this is
keeping all the stubs in C: or RAM:. Would probably have to write all the
stubs in assembler (a feature to me), because most Lattice C programs seem to
end up with load files bigger than most of the commands in C: combined.
No pipes??!??!?! Where are the &^*( pipes?
Why can't I stop a runaway task, and why do you have to go out of your way to
make your program stoppable when you write it rather than the other way around?
How about a "BREAK 2 -dammit"?
Also, from disassembler reading, it's very clear that most of the commands in
C: use some sort of CLI library, or at least a set of internal entry points to
do nearly everything from typing things to scanning the command line arguments
(FOO/K,BAR/A style). Which prompts two questions: (1) does anyone from Amiga
want to impart some knowledge of how to use these entry points, so we can all
make commands that look just like normal Amiga DOS commands, and are as SMALL
as normal Amiga DOS commands (I know, fat chance), and (2), what is it that
these CLI commands do to make the command name known to the STATUS command?
I've been through all the data structures with WACK, and I can't find any
name string that isn't filled in for anything else.
On to the file system: It's cute for a toy computer, but is this a toy
computer? In particular, Amiga doesn't seem to be making any friends with the
hashed index scheme. It's easy enough to understand why such an approach was
taken, as it solves a few nasty problems. For instance, with the scheme, you find that
you either (A) preallocate a maximum directory size when the directory is
created, and then impose arbitrary limits to the number of files in the
directory and at the same time waste precious disk space on preallocated
directories with only one or two files in them or (B) you get into the ugly
mess of learning how to dynamically expand and compress directories when they
get filled up; a problem which gets exponentially ugly if you've got more than
one task running. Still the problems aren't insurmountable, and I feel that
someone's traded programmer convenience (Commodore corp's, that is) for human
interface and long term usability. All comments about filename wildcarding
aside, this is the first operating system which I have been completely unable
to induce to place files in a directory in the order I'd like them, and that's
by design. It's very nice for files to be in a directory in alphabetic order,
if only for distribution/archive purposes. If not alphabetic, in order of
creation date is almost as nice. As it is, I can do neither, with the result
that I'm completely unable to find anything in a directory containing more than
20 or so files, unless I use the DIR command, which doesn't give me creation
dates or file sizes.
On the plus side, I really appreciate that Amiga DOS both remembers disks, and
allows me to specify the name of an as-yet unmounted volume as part of a file
specification. This allows you to run applications that access more data than
you can have mounted all at once, which in itself is a resounding win. It's
just a shame that Lattice C executable files fill a disk so fast that this is
almost the rule rather than the exception.
Overall, coming from 8 bit computers with <64K available memory and 180K byte
SSDD floppies, I'm pretty surprised at how often I run out of memory and disk
space on our 512K system with 2 880K floppies.
All of which leaves me with a burning desire to either write my own operating
system (which would be loads of fun if I really had the time on my hands) or to
pitch Amiga DOS, and go in search of OS/9 for the Amiga. The only problem with
both of these solutions is that we're fairly guaranteed that the majority of
canned software coming down the road is going to be written for whatever
Commodore supports, and not OS/9 or homegrown. Don't get me wrong: Amiga DOS
is a quantum leap above most of what's running on microcomputers these days.
If I'd never had the opportunity to work with much nicer operating systems on
larger machines, I might not be making these complaints. But, what really
hurts is that I've seen OS/9 on the ($300) TRS Color Computer, which in most
respects is far and away a superior multitasking system to Amiga DOS. Only
trouble is, that there's no software written for it (to speak of).
D. Banks.
--------