Date: Wed, 23 Sep 1998 16:59:49 -0600 (MDT)
Message-Id: <199809232259.QAA01524@kewlaid.highfiber.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
To: opendos AT delorie DOT com
From: raster AT highfiber DOT com (Charles Dye)
Subject: Re: Suggestions for DR-DOS
Content-Transfer-Encoding: 8bit
Precedence: bulk

Guti <guti AT qsystems DOT es> writes, among many other suggestions:

>            þ Interrupt 21h service 30h (Get DOS version number), returns
>              DOS version (AL, AH) 6.00 and must be 7.02; OEM (BH) 0 and
>              0 is for PC DOS from IBM, so DR DOS must have another OEM
>              identificator number.

That's correct.  DR DOS is emulating PC DOS 6.0.  Having 21/30 return the
actual version number might look like a good idea at first, but would
almost certainly cause problems.  Many programs assume (wrongly) that any
DOS returning a major version number of 7 must be Windows 95.  See the
demented TV-LIE program shipping with IBM DOS 7 for an example of the
horrible lengths you must go to to compensate!  Better to leave the version
number at 6.

To check for DR DOS and get the correct BDOS level, use 21/4452 and examine
the return value in .AX.

>	    þ Include in each new release a file called WHATSNEW.TXT with
>              the history of improvements, bugs fixed, ... for every part
>              of DR DOS.

Agreed.

>            þ Implementation of the SERIAL command for allowing the user
>              to change or view the serial number of his disks.

The documented DOS IOCTL call to do this is correctly implemented in
DR DOS.  I'm not certain about the undocumented call, 21/69.  But any
program which uses the standard method should work fine.

(But what a useless thing to do!  The volume serial number appears to be
a mechanism to detect disk changes in floppy drives with defective
change-line hardware.  Most DR DOS commands don't even display this
rather boring piece of internal data.)

>	    þ Support for Windows 9x VFAT (good work with the betas of
>              long file name, but still not finished) and FAT32. (Also
>              Windows NT HPFS?)

I'd have to disagree.  Microsoft's LFN storage is terrible -- consider
how even Microsoft's own disk utilities, like DOS 6.x SCANDISK, trash
them.  This isn't Caldera's fault, but I question the wisdom of cloning
such an awful standard.  Especially when it conflicts with passwords,
the only real innovation DR DOS adds to the filesystem.  A better idea
might be to store the LFNs in a separate file, as 4DOS does.

FAT32 would be a useful improvement to add.  HPFS -- don't hold your
breath.

>            þ Multiple configuration files (CONFIG.SYS and AUTOEXEC.BAT)
>              should be supported with compatibility against MS DOS and 
>              PC DOS.

Already implemented.  DR DOS will look for a DCONFIG.SYS (and, IIRC, also
an ODCONFIG.SYS) before the usual CONFIG.SYS.  You can use SHELL= to
start a batch file other than AUTOEXEC.BAT.

>            þ DIR command should have the "standard" options used by the
>              MS DOS, PC DOS and 4DOS DIR command; specially the /S
>              command for subdirectory search.

The DR DOS implementation of DIR is definitely annoying.  One particular
peeve of mine is /A -- documented as "display all files" but that's really
not what it does at all.  Some of the ideas in DIR apparently date back
to CP/M, like that odd "Directory files exist" message.  I suspect that the
thinking here is along the lines of "Since XDIR is so much better, why
bother to update DIR?"  One good answer would be "compatibility with MS-
DOS batch files."

raster AT highfiber DOT com