Date: Thu, 20 Mar 1997 06:56:04 -0500 (EST) From: "Mike A. Harris" Reply-To: "Mike A. Harris" To: dg AT dcs DOT st-and DOT ac DOT uk cc: opendos AT mail DOT tacoma DOT net Subject: Re: [opendos] Wishlist v2.0 In-Reply-To: <18040.9703141838@orkney.dcs.st-andrews.ac.uk> Message-ID: Organization: Total disorganization. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Mar 1997 dg AT dcs DOT st-and DOT ac DOT uk wrote: > 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. I agree that direct writes have no place in the kernel, however I think they should be placed instead OPTIONALLY into the applications themselves. That way you merely add a command line switch and voila! > > >>>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. I think you're misunderstanding what we mean by an IFS, so I'll clarify it for once and for all. Can I mount an ext2 filesystem under MSDOS for both read and write right now, and have access to symbolic links, long mixed case filenames, etc? I don't mean hashed names, I mean that NEW PROGRAMS WRITTEN SPECIFICALLY for OPENDOS could use long mixed case ext2 filenames. Older programs would get hashed names on the old interrupts. This way no compatibility issues come up AT ALL. Newer programs could then take FULL ADVANTAGE of the each filesystem's NATIVE features. If you can show me how to make a DOS symlink on an ext2 filesystem with the existing DOS interface then you'll have convinced me that the entire IFS discussion is fruitless. Otherwise, a *NEW* IFS layer *IS* needed and GREATLY WANTED. Picture this... C: is an FAT drive D: is an ext2 drive E: is an HPFS drive C:\> D: D:\>CD longdirectoryname D:\longdirectoryname> LN /S verylongfilenamethatneedstobeshorter shortname D:\longdirectoryname> LN /S D:\ link_to_HPFS_drive D:\longdirectoryname> DIR Volume in drive D: is an ext2 mounted filesystem . .. subdirectory1 <---> verylongfilenamethatneedstobeshorter shortname -> verylongfilenamethatneedstobeshorter link_to_HPFS_drive -> D:\ Now if an old DOS legacy app tries to read one of these drives it will get hashed names for all of these files. Something like: SUBDI#ZQ.001 <---> VERYL#GF.001 SHORT#8R.001 LINK_#F3.001 This way NO BACKWARDS COMPATIBILITY is lost, however we can take full advantage of other filesystem technologies that exist. Do you see the advantages of this kind of setup? If not, then you don't need to use the IFS layer at all. Just keep using FAT. Other people have other needs however. Another example of this usefulness is: I have a lot of graphics files in my ext2 partition that I can currently read in DOS via the ext2tools package which basically lets DOS read ext2 drives via the current so called DOS IFS. This ONLY GIVES HASHED FILENAMES TO LEGACY APPS. In no way are ANY DOS programs, past or future able to use ext2 symlinks, long filenames, etc. However under the new IFS that we are proposing, NEW programs can be written which can go through the NEW IFS and actually take real long mixed case filenames. That way I could download a new OpenDOS IFS whizbang graphics viewer and be able to use the filenames I'm used to. The new whizbang program would still work in normal DOS too though because it would be aware that no IFS was present and would revert to the older mechanism. Therefore EVERYONE is happy and NO COMPATIBILITY is lost period. > 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. Well, the IFS support that is there is not good enough, and it cant be extended to do what we want without a new API because DOS doesn't allow mixed case names, directory permissions, symlinks, hardlinks, etc... Under the new IFS, DOS WOULD allow these things transparently. I've looked at the DOSEMU code and you're better off looking at the MACH name mangler files from the DOSemu source tree than looking at the LREDIR sources. If you'd like I can find the filenames for you. The code is pretty solid looking. >>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. It has absolutely nothing to do with an IFS at all. I think you misinterpret the structure of this wishlist. > 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: Since DIR is an INTERNAL command in COMMAND.COM and since it is what displays the file descriptions, that is where the file description code must reside. In the source for the internal DIR command, as well as perhaps XDIR. A "DESCRIBE" command is also needed. I *HEAVILY* push that the 4DOS description method be used for compatibility reasons. > SET PATH=C:\SYSTEM\OPENDOS;@;C:\SYSTEM\UTILS > > would search SYSTEM\OPENDOS *before* checking to see if the command was an > internal one. This would drastically slow down command execution. Internal commands are internal because they are frequently used, and for the most part they are small in code size. Therefore the command processor looks to see if the command you just entered is an internal command first. Making it look in an external path first would be slow and VERY BAD programming practice. A much better way to bypass an internal command is the way that 4DOS implements it. DIR - does the internal dir *DIR - bypasses the internal dir and looks for an external one. 4DOS processes commands as follows: 1) Aliases 2) Internal commands 3) External commands By placing an * in front of #1 or #2 you bypass that level of command interpretation. In other words if you have an alias called DIR and you say *DIR, it bypasses the alias and uses the internal command. If you didn't have an alias and you used *DIR you'd get an external DIR command. I believe 2 *'s will bypass both an alias AND an internal although I can't confirm this. > >>>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. I'm not sure if the kernel is REALLY limited to 64k or not. If it really is, I'm sure that the reason for such a limit can be "fixed" by a better design. > How would you specify parameters? Well, the default OpenDOS out of the box setup wouldn't require such a thing. If you were to recompile/etc... then you may have to use a boot loader which would specify kernel command line options to the kernel not unlike LILO/Linux does. Again, Joe Blow wouldn't need to know or care about this because he wouldn't be compiling his own kernel. > What would you do if you needed to boot without a particular driver? You would either not compile that driver into the kernel in the first place, or you would recompile. Simple. Either way, you would have the option from the start of what you were doing. If you didn't like drivers compiled into the kernel, then you wouldn't do that would you. What about other users who WOULD like that option? Should they not have THEIR opendos requested features fulfilled as well? > What would you do if you wanted to *replace* a given > driver? Recompile? Yuck. What would I do? I would recompile if I'd previously compiled into the kernel. If it was a loadable module, I'd either download a new module or recompile just that module. Again, very simple. What would Joe Blow do if his whatever driver didn't work? He'd do the same thing he does now when his whatever driver doesn't work. Again, everyone is happy. Joe Blow downloads his new driver or goes to his computer guru. I on the other hand just recompile my driver or my kernel. You don't sound like you've had any experience with loadable modules. You only make a loadable module for something that either isn't used very often, or else for a piece of hardware that is sometimes removed. There are other reasons as well, but that is a good explanation IMO. > If you needed to boot without a particular driver, then you > wouldn't compile that driver into the kernel in the first > place. > > *Not* a good idea. Precicely. That is why you'd have the option. Since the default distribution would not use drivers built into the kernel, you'd be the one responsible if you'd compiled a driver in and then needed to boot without it so it would be your own bad 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. Correct, it would be OpenDOS-32. Many people like the idea. I'm not the only one. Regardless, it wouldn't make the 16 bit version obsolete, nor would it discontinue support for it. A perfect example is Linux. Linux started out as a 32 bit OS for the 386 and higher. Right now there is a project going that is porting Linux to the 16 bit 286. Why? Beats the hell out of me! Would porting Linux to a 64bit architecture in any way affect the 32 bit version? Would it stop 32 bit developement? Answer: NO, Linux has allready been ported to 64 bit processors (or is being ported). It all comes down to this: If you're not interested in a 32bit DOS, then ignore postings and questions/answers about this topic. I for one would like to see many of the 16 bit utilities ported to 32 bit and am willing to try porting them myself. I don't know much about the kernel becoming 32 bit, but I suspect that it is possible. Whenever you say that "it isn't possible", someone will shortly make your face turn red by doing the "impossible". > If you want a 32-bit protected mode operating system, use Linux > or Demos or something. I do use Linux. I don't know what "Demos" is. Regardless of what you want, when the OpenDOS sources are released, I guarantee you that before too long an OpenDOS 32 will emerge. First as an enhanced utility set, and then a command processor, etc... If you don't like this, then don't use it. Use the 16 bit stuff. > If you want to try to convert DOS into a 32-bit protected mode > operating system then it won't be DOS. Correct, it will be OpenDOS-32. > >>>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. Fine with me. W95 sucks. Some of the apps are nice, but the OS sucks. > >>>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. No, if you write a TSR properly you can unload it if it was the last TSR that was loaded. It is hardly dynamic. A Dynamically loaded module (driver) can be inserted or removed from a running kernel at any time without rebooting. This is not possible with TSR's. > 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. I don't fully understand what you're saying here. Perhaps a better understanding of the "loadable module" concept is in order. The best way for this to be implemented is for either a TSR to be loaded, or built into the kernel (at users discretion) that hooks all interrupts, etc. If a CDROM module is being used, and the CDROM module isn't loaded, then the TSR (having allready hooked the CDROM interrupt) sees that the CDROM is being requested to be used. It then loads the module via DPMS or whatever and then jumps into the module to complete the request. A timer is started which counts how long since a device has been used. If the device hasn't been used for a while, the driver is unloaded until needed again. This is a "demand loaded" situation. The other situation is where you must manually load the modules yourself. Lets say you are in DOS and don't normally have your CDROM driver loaded. You do a dir of your CD and get: ERROR: Module not loaded for CDROM device. You then type: C:\> LOADMOD C:\DOS\MODULES\CDROM.DLD Then you can use the CDROM. When you no longer need it, you can either just leave the driver loaded, or else you can unload it with: C:\> REMOVMOD CDROM.DLD This is different from the TSR load/unload method because only the last loaded TSR can be unloaded. With the insertable module method, a module can be inserted or removed ANYTIME, and in any order. > >>>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. Yes, but then we don't have the internal things that OpenDOS's COMMAND.COM has. Sure we get the cool 4DOS stuff, but then lose some OpenDOS compatibility. Are you saying that you don't want to see ANY features added to COMMAND.COM? > >>>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. Can't comment much here. I disable coredumps in Linux as I've got no use for them. Likewise in DOS, I'd not have much of a use for them. HOWEVER, a memory dump program would be a useful tool, perhaps part of an optional OpenDOS addon package. > > >>>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? No. Not needed. Do you ever read the mail on this list? If you do, you'd realize that we've stated that older programs would follow the standard if they were installed in the "defined standard directories" if they aren't, then they merely don't get to take advantage of the OpenDOS uninstaller program. They'd still be fully functional. > [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!] Since the original sender's address appears in the To: field, and the list appears in the CC field automatically, to send just to the list, one has to remember which list members don't want CC's and who is indifferent to them. Since many of us read many mailing lists, it is impossible to remember who doesn't want CC's and who does or is indifferent. I've gotten many requests from different people asking if I could PLEASE CC replies to them from various lists. In my 5 years experience with Internet/Bitnet mailing lists, listserv's, etc, I've found that it is a common standard practice to CC replies to the sender. Since most lists are set up so that the list is the CC, it makes it impossible to satisfy everyone's wants. Since there are other side effects if the list was to appear in the TO field and the sender in the CC field, it is best to merely follow standard practice. Thus if you get dupes, either delete them as you get them, or use a front end mail processor such as procmail to remove dupes. If you don't want to download the dupes and then process them, then set up a dupe processor on your server end. This is what I've done and it works great. Only rarely do I get dupes now. If you don't run Linux for your internetting, then I recommend the server side approach. For example, my email comes into the blackwidow computer. I've got procmail set up to kill dupes. Then when I connect via modem to the pop server I download my mail without dupes and my local procmail sorts it into different folders. If you need any help trying to set any of this up, feel free to contact me privately. Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris Computer Consultant | Coming soon: dynamic-IP-freedom... My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html mailto:mharris AT blackwidow DOT saultc DOT on DOT ca Question: Where can I get a good WYSIWYG HTML editor for Linux?