Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site caip.RUTGERS.EDU Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!pesnta!pyramid!ut-sally!im4u!caip!DEC.BANKS From: DEC.BANKS@MARLBORO.DEC.COM Newsgroups: net.micro.amiga Subject: More unwanted opinions on Amiga DOS Message-ID: <1041@caip.RUTGERS.EDU> Date: Mon, 20-Jan-86 18:09:09 EST 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. --------