From: dg AT dcs DOT st-and DOT ac DOT uk Message-Id: <18040.9703141838@orkney.dcs.st-andrews.ac.uk> To: opendos AT mail DOT tacoma DOT net Subject: Re: [opendos] Wishlist v2.0 In-Reply-To: chambersb@juno.com's message of Thu, 13 Mar 97 21:01:29 -0500. <19970313 DOT 180558 DOT 11959 DOT 1 DOT chambersb AT juno DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Mar 97 18:38:30 +0000 Sender: owner-opendos AT mail DOT tacoma DOT net Precedence: bulk I got several replies to my critique (!) of the wishlist. They were all pretty similar, so I'm just replying to this one; I'm not picking on this person in particular. Large sections are cut for brevity. >>>1] Direct screen write >>No. Direct screen write is totally inappropriate in the kernel. It >Should have been written: Everything added is OPTIONAL. Ie, if you don't >want any of the additions on this list, you can turn them off. Optional, sure. I, personally, use direct screen writes on my 486 to speed things up. But the place for this isn't in the kernel, it's in a TSR; I use VANSI.SYS. As a rule, you don't want to put extraneous features in the kernel. There's limited space available and it reduces flexibility. Besides, modularisation is Good. >>>3] IFS support >>What, you mean support for a *different* IFS than the one we've >>already got? >The whole point of IFS is to have more than you already have. What if >you have a Linux drive on your system? Think FAT'll let you use it? I do believe that people have a rather mistaken idea of what an IFS is. IFS stands for Installable File System. This lets you install run-time drivers that will give invisible access to non-standard file systems. Contrary to popular belief, DOS has extensive support for this. Example: NWCDEX is an IFS that gives access to ISO9660 and High Sierra format filesystems, on CD. Example: Personal Netware is an IFS that gives access to remote file systems mounted via Netware (I forget exactly what protocol). Example: INTERLNK is an IFS. Example: I once had a program that gave access to about 150 formats of CP/M floppy discs. That, too, was an IFS. What's needed is not IFS *support* (that's already there) but the IFS modules themselves. I'd like an ext2 module as much as the next sentient being. I'd be willing to give it a try, myself; unfortunately, I can't find any on-line documentation or source. The closest I've got is the DOSEMU LREDIR.SYS source, which is an uncommented nightmare. If anyone can give me a pointer I'd be grateful. >>>4] File Descriptions >> >>Better suited for an external program. If I can get gdbm ported to >>Borland I >>might give it a try. >With IFS, It's trivial to write this one in. I'm afraid I fail to see what the IFS has to do with file descriptions. Somebody said that file descriptions should be integrated into the kernel so that DIR displayed them. While this would be useful, I feel that it's a questionable use of valuable kernel space. A better solution is either to use DOSKEY to alias DIR to XDIR (or a similar external command) and then modify that, or (my favourite) modify the kernel so that you can specify the position the internal commands appear on the path. eg: SET PATH=C:\SYSTEM\OPENDOS;@;C:\SYSTEM\UTILS would search SYSTEM\OPENDOS *before* checking to see if the command was an internal one. >>>6] Compile all drivers in the kernel >>You're kidding, right? >Again, optional. There are *lots* of drivers. There's a kernel limit of 64kB. How would you specify parameters? What would you do if you needed to boot without a particular driver? What would you do if you wanted to *replace* a given driver? Recompile? Yuck. *Not* a good idea. >>>10] Make the source compilable by one compiler and linker (not our >>This is definitely needed. But not DJGPP. DJGPP is a 32-bit >And yet, isn't a 32bit DPMI OS which utilizes V86 consoles _definitely_ >what we want? The only problem is the overhead - for just the kernel, >though, and without any external crap (sound, graphics, et cetera, >they're all drivers) the kernel shouldn't be too bad. DOS is a 16-bit real-mode operating system. It is *not* a 32-bit protected mode operating system. If you want a 32-bit protected mode operating system, use Linux or Demos or something. If you want to try to convert DOS into a 32-bit protected mode operating system then it won't be DOS. >>>12] Make W95 run from OpenDOS >>Almost certainly not possible, I'm afraid; MS-DOS 7 was majorly bent >Doesn't W95 let you keep an older version of DOS if you wish? Then why >couldn't we make it work like this? Yes, but but it won't *run* from that older version. It'll let you boot into your old DOS, *or* into MS-DOS 7 and Windows 95. It won't let you do both. >>>13] On the fly DLD's (dual mode) (Dynamically Loaded Driver) >>Not possible with block devices and file systems, because of the way >>drives >>are allocated. Most other drivers are already dynamic (TSR's). >I would hardly call TSR's dynamic - you load them manually, and then >they're loaded for good. If you write the TSR properly you can unload them again. As for automatic loading? How is DOS supposed to know what interrupts correspond the old devices? The only way I can see of doing it is to load a TSR that watches certain interrupts and loads another TSR when they're called. If you're doing that anyway, you may as well load the second TSR and have done with it. >>>14] Add 4DOS's cool stuff >>Mmmm... possibly. 4DOS is very complex. I think that anyone who >>actually needs >Again, optional. This is easy --- anyone who wants 4DOS can *install* 4DOS. >>>21] Coredump!!! >>Well, I've been doing Unix programming for some years now and I have >>*never* >>found a use for a coredump. >What, you've NEVER made a program that crashed? Either you're the best >programmer in the world, or you're full of sh*t. Core dumps tell you >where you're program crashed, making debugging a _lot_ easier. Hadn't >this ever occured to you? I didn't say that. A lot of my programs crash. I said that I've never found a use for a coredump, which is perfectly true. When I need to debug a program, I don't use a coredump, I use a live copy connected to GDB. You get a lot more info that way. Core dumps are really a relic of the old punched-card days when the code/compile/execute cycle was a lot slower than it is now. >>>22] FSSTND >>It's too late. >Why? Is there any good reason software can't be written FIRST for OD, >_then_ ported to other OS's? IMHO, This'll help it more than anything. Are *you* willing to backport the several million DOS programs that are currently in existence? [Note: Please do NOT cc: replies to me! I'm on the list so I'll get the reply anyway! Doing that means I get two copies!] -- ------------------- http://www-hons-cs.cs.st-and.ac.uk/~dg -------------------- If you're up against someone more intelligent than you are, do something totally insane and let him think himself to death. --- Pyanfar Chanur ---------------- Sun-Earther David Daton Given of Lochcarron ------------------