Mail Archives: opendos/1997/03/20/08:42:06
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
<DIR> .
<DIR> ..
<DIR> subdirectory1
<---> verylongfilenamethatneedstobeshorter
<SYM> shortname -> verylongfilenamethatneedstobeshorter
<SYM> 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:
<DIR> SUBDI#ZQ.001
<---> VERYL#GF.001
<SYM> SHORT#8R.001
<SYM> 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?
- Raw text -