Path: utzoo!attcan!uunet!ginosko!husc6!ukma!gatech!udel!princeton!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli) Newsgroups: comp.sys.amiga Subject: Re: My AmigaDOS 1.4 wishlist Keywords: Huh? Message-ID: Date: 30 Jul 89 02:17:10 GMT References: <12878@well.UUCP> Organization: Drew University/NJIN Lines: 106 Note: I removed comp.sys.amiga.tech from the Newsgroups: line. Kent, with all due respect, what computer are you talking about? Certainly not the Amiga that I use! In article <12878@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: > I've heard "it's in there" about the 1.4 release. Here are my entries in > the great 1.4 wish list sweepstakes, in hopes that this is timely, and > finds some you missed. > > Most important: make sure that the hard disk and other file system control > software is compatible with SCSI, removable medium, 1.5 Gbyte disks. These SCSI support, removable medium and 2.2GIG disks are all supported in 1.3! Check out (for example) GVP, they've shipped a SCSI controller that supports removable media (even 1.2 or 1.1 included DiskChange :-) support. Basically all the driver has to do is issue a DiskChange command when media is removed. > drives should arrive before the 1.4 release. (Mfgr's name available to > CATS on request, if you haven't already had a demo of the existing > prototype.) In particular, limitations of "partition" sizes, numbers of FFS supports 2.2gig per partition therefore (a) removing the need for partitions [if you don't believe in them] or (b) permitting you to make any size partition you want [if you do believe in them] > files/directories per directory node, maximum length of a path name, etc., OFS and FFS have no limits on # of files (MS-DOS does). Max length of path name has never affected me except just now when I couldn't go more than 8 deep. I never knew there was a limit until you just mentioned this and I opened a CLI to test it out. > should all be reviewed and improved in anticipation of truely fast, huge > (and extremely cheap; ~ $1/Mbyte drive cost) storage systems. In most > cases, hard limits should be replaced by soft limits; path name arrays -> > path name c-strings, directory name arrays -> directory name link lists, > und so weiter. I can hardly wait to put my 400 floppy disksfull of PD > software and data on one huge disk, and, at last, sort it out. [Naturally > the only practical backup for such a beast is another one just like it, so > I'll probably buy two!] Ummm... what's stopping you from doing that now? > Merge list and dir commands ("ls" would be a catchy name for the result!) [deleted long tirade about a proposed improved LIST/DIR command] Ummm... is you want ls, find it on the fish disks. > Replace/supplement the existing "Pipe:" device with a real Unix(tm)-like > "|" pipe that can be used in a one line command. That's the shell, not the OS (but a 1.4 suggestion non-the-less). I've heard rumors... > Add a command to display/kill locks, to help clean things up when a disk > icon won't go away because some careless programmer left a lock engaged. How about a command to display and kill careless programmers? > Add a capability to use extended selection for _any_ program, without > change to the object module, to make it think it is getting command line > input. I added a tool icon to my favorite microemacs (the one from [Tirade deleted] That's in most of the startup code from most compilers that I've seen. Of course, all that Workbench stuff will change in 1.4 and be much better (we've been told). > While I'm on the subject, add paragraph flowing capability (preferably > including a fixed "indentation string" option, like GNUEmacs has) to the > Extras 1.3 MEmacs. That would make it almost usable for text processing > tasks on simple ASCII files, since it already works in extended selection > mode. Yes, Emacs is nice, and text editors can always use more features :-) > An otherwise empty, INSTALLed disk with :s/startup-sequence = "loadwb" > and :loadwb version 1.3 its only files fails to boot with a return code 20 > from loadwb. The 1.3 docs for loadwb do not give any preconditions for its > successful operation, and none of the commands' docs give return code > interpretations. Both these problems need fixing. [I was trying to make > the Hack_Game: disk bootable, but it needed a workbench loaded to be > useful. No joy.] That would be nice to be documented, and certainly isn't as (ummm...) outlandish as your first couple comments. I *belive* that all you need is icon.library but I've never looked into it. (hard drives do that to you :^) [Other things deleted] > Thanks for listening, as usual. > > well!xanthian > Kent, the man from xanth, now just another echo from The Well. -Tom -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University :) Is it my imagination or are a lot of people posting everything twice? (: ...or is this some new rule that I don't know about?