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

Article-I.D.: 3comvax.373
Posted: Wed Jan 22 02:45:42 1986
Date-Received: Fri, 24-Jan-86 08:30:34 EST
References: <1041@caip.RUTGERS.EDU>
Reply-To: mykes@3comvax.UUCP (Mike Schwartz)
Organization: 3Com Corp; Mountain View, CA
Lines: 61


For those of you using Lattice 'C' out there, I made the followig observation
today.  The following function compiles into 100 bytes of code on the
IBM PC (you can bet the 68000 requires 150 bytes, based upon the size
of LC1 and LC2 on both machines):
encrypt(encrp, mask)
char encrp[], mask[];
{
	int i;

	for (i=0; i<6; i++)
		encrp[i] ^= mask[i];
	}

Just for yuks, I coded the same thing by hand in assembler and it requied
12 bytes.

The best strategy for programming the Amiga might be to make libraries and
write small front end programs.  This will share code and will reduce
memory requirements.  

Not only is ALINK a memory hog, but it is slow.  It is not smart enough
to read in it's libraries all at once, or it might be faster.  Too bad
Amiga.lib is 74K, or it might be faster, too.  I have watched ALink run
whle the workbench showed dynamically how it used the ram.  Alink actually
used more ram after it started writing out the executable file (?!?).

Before putting any blame on the folks at Amiga for the woes of AmigaDos,
it might be better to keep in mind that AmigaDos was written by MetaComco
NOT AMIGA.  Amiga is responsible for everything from Trackdisk.device
down, and everything I see there is super!  Intuition, on the highest level,
also seems to be pretty darn good.

What Amiga can do to make AmigaDos better might be limited by the software
that requires the standard AmigaDos startup stuff.

I am no Unix expert, but aren't ports and pipes (between processes) the
same (sorry, but I am ignorant if they aren't).  If you refer to pipes on
the command line, I am glad tht Amiga left them out rather than tying up
RAM or using floppies for the piped data.  I have these pipes available to
me under MS DOS all day, but I rarely use them and see no absolute need for
them.

Someone posted a source to unix-style ls for the Amiga, including wildcards,
etc.  So who cares if the Amiga doesn't do wildcards nice, it does now!!
This ls also sorts the directories by date and time and alphabetically too!
This ought to make the disk directory format less of an issue (although it
does take a while to enumerate (expand) wildcards).

Consider this - the Amiga is making a new standard that in most ways is
better than the old ones (unix and MS Dos included here).  To me it is
no worse than Unix to program for, and light years better than MS DOS.
Given time, the Amiga will mature into something that might make us all
(except for the religious) forget unix.  The only problems seem to be
software, and software is real cheap and can be easily replaced.  Compared
to the 8 bit machines, the Amiga is a godsend.  Compared to the IBM PC and
the Atari ST (I have not heard about any standard programatic interfaces
or a standard language or anything for it) and the Mac, the Amiga is a 
DREAM to program on.

Put that in your pipe and smoke it!