Dec 292017
 
Documentation of a possible minor bug in MS-DOS 5.0.
File DOS5BUG.ZIP from The Programmer’s Corner in
Category Tutorials + Patches
Documentation of a possible minor bug in MS-DOS 5.0.
File Name File Size Zip Size Zip Type
BUGTEST.ASM 3397 1591 deflated
BUGTEST.COM 1679 961 deflated
BUGTEST.SEQ 27 26 deflated
READ.ME 1471 791 deflated

Download File DOS5BUG.ZIP Here

Contents of the READ.ME file


DOS PROGRAMMERS, NOTE: The purpose of this program is to demonstrate a
bug I have noticed in the way MS-DOS Version 5.00 loads a program into
an Upper Memory Block (UMB). You may want to write a few extra lines of
code to compensate for it. Here is what happens: When a user enters a
DOS command followed immediately by filenames or drive letters in the
format ":filename" (i.e. drive letter followed by a colon), DOS is
supposed to encode each drive letter in the bytes at offsets 5Ch and
6Ch, respectively, in the program segment prefix (PSP) as the first byte
of an unopened FCB. An entry of "A:" is supposed to give you 01h, "B:"
yields 02h, and so forth. However, when MS-DOS Version 5.00 is running
and your program has been loaded into a UMB using the LOADHIGH or LH
command, DOS falls down. The byte at 5Ch always remains a zero no
matter what, and the byte at 6Ch is coded for the *first* drive
specified! (If you specify a second drive, it ends up who-knows-where.)
If you enter "BUGTEST a: b:" under DOS Version 5.00, it will correctly
return the specified drives. But if you enter "LOADHIGH BUGTEST a: b:"
instead, you'll notice that DOS reports no first drive and the wrong
second drive. Probably nobody uses FCBs anymore, but those drive bytes
come in very handy sometimes. Grrrrr!

-- Jerry Monroe, CIS # 72321,1257
June 23, 1991



 December 29, 2017  Add comments

Leave a Reply