Path: utzoo!attcan!uunet!samsung!dali!ogicse!emory!mephisto!mcnc!rti!bcw
From: bcw@rti.rti.org (Bruce Wright)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Need input for future DOS release
Summary: Can't be done ...
Message-ID: <3713@rtifs1.UUCP>
Date: 29 Mar 90 05:25:05 GMT
References: <26909@ut-emx.UUCP>
Organization: Research Triangle Institute, RTP, NC
Lines: 61

In article <26909@ut-emx.UUCP>, boerner@ut-emx.UUCP (Brendan B. Boerner) writes:
> Here are a couple of things I wouldn't mind seeing in a new version of
> MS-DOS.  I realize some have already been mentioned but I thought I'd
> send the whole list as is anyway.
> 
> 1) The ability to load/unload device drivers at any time - not just
> during the boot process.  Sorta like Novell's Netware Loadable Modules
> on NetWare/386.

In general you can't do this, though if a driver is specifically
written to be unloadable it's possible.  Sometimes (maybe on the
PC environment most of the time) you can unload a driver that 
wasn't written to be that way, but it's sort of an accident of the 
hardware/software environment if that's the case.  Unfortunately
the first time you find out about a problem with something like
that is when your machine crashes or wipes out your disk or
something, so it's not particularly recommended.

> 2) A TSR Manager.  Programs written to use it would let it know what
> resources that they need (e.g. what interupts they would like to be
> activated on).  It would keep track of what program uses what
> interrupts so if a call were made to unload a TSR, it would be able to
> unload it without affecting others in the chain.

Again, to do this right requires cooperation from the TSR's.  Though
you can get a fairly high percentage by just restoring the interrupt
vectors in low RAM, there's always the possibility of other hardware
or software modifications that might have been made.  It wouldn't
be practical to save the entire machine state before each TSR (!)

> 3) A file system which supports symbolic links
> 
> 4) Rename (or move) across directories within the same volumne
> 
> 5) A better wildcard capability.  Dir *X.* would display files ending
> with X, with any extension, not all files.

All of these would be nice, and would be quite implementable, though
the first one would require some modifications to the disk structure
(not the first time that's happened though).  I've never understood
why problem #4 exists, and problem #5 is essentially a crock that
got carried over from CP/M (and should have been left there, IMHO).

> 6) A larger command line limit.  This would allow paths with length
> greater than 128 chars.

You might be able to make a special case for the PATH and SET
commands (or possibly for all internal DOS commands), but in general 
this is not possible without introducing incompatibilities, which
Microsoft is not likely to do.  None of the programs that currently
use command lines would be able to work after this kind of change!!

It would be nice to allow the PATH to get longer somehow; although
the performance resulting from such a long PATH isn't very good,
it's sometimes helpful to do it temporarily.  There is, of course,
the possibility that some programs copy the PATH into a fixed-size
variable and allowing PATH to grow that large could cause problems
(though obviously only if you actually set it that large).
Fortunately, I think such programs are probably fairly rare.

						Bruce C. Wright