Message-ID: <000301c161a7$ca477d40$027efea9@atlantis>
From: "Matthias Paul" <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
To: <opendos AT delorie DOT com>
Subject: FYI: Bugs in DR-DOS 7.03
Date: Tue, 30 Oct 2001 20:52:51 +0100
Organization: University of Technology, RWTH Aachen, Germany
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id f9V137Q29701
Reply-To: opendos AT delorie DOT com

FYI, citing from a discussion that takes place in alt.msdos.programmer &
comp.os.msdos.apps under the subject "good EMS/XMS/RAM driver for MS-DOS"
(with some re-editing):

>> Personally I am aware of a total of four new bugs in DR-DOS 7.03
>> compared to 7.02, but several dozens of issues have been fixed and
>> many new usability enhancements and minor new features were added
>> between these two releases.
>>
>> So, if you happen to run into one of the new problems (rather
>> unlikely under normal conditions) you might be better off using
>> DR-DOS 7.02 (or at least parts of 7.02), but otherwise I would
>> recommend the DR-DOS 7.03 release. Itīs more advanced and usually
>> more stable. (Of course, as in any software, there are still some
>> unresolved old issues...)

On 2001-10-26, Jack Yazel asked:

> Are the four bugs identified somewhere or can you describe them?

Summarizing what has been discussed in this forum over the
past years, here are the four new bugs and one additional
compatibility issue (a few more new issues - like the bug in
the CHAIN [D]CONFIG.SYS directive - existed in 7.02, but were
corrected in 7.03, see the WHATSNEW.TXT in the distribution):

1. Bug: INT 21h/6601h fails with BX=0:

   | INT 21 - DOS 3.3+ - GET GLOBAL CODE PAGE TABLE
   |         AX = 6601h
   | Return: CF set on error
   |             AX = error code
   |         CF clear if successful
   |             BX = active code page
   |             DX = system code page

   A minor modification of INT 21h/6602h (!) with DR-DOS 7.02+
   IBMDOS.COM (since update 1998-04-15) caused INT 21h/6601h (!)
   to fail, if the *unused* register BX is 0 on entry. Also, DR-DOS
   sets CF on error, but does not properly clear CF if there is
   no error, so the Carry flag return shouldn't be relied upon.

   Workarounds:

   The proposed workaround for (still actively developed) drivers
   and applications is to always call this function with BX=FFFFh
   and DX=FFFFh to ensure this condition will never be triggered.
   Otherwise the behaviour would depend on the random contents of
   BX, which is not a good thing to rely on... BX and DX should be
   checked to have changed from FFFFh before assuming the function
   was successful.

   Write a small TSR that sits on top of this function and changes
   BX=0 to BX=FFFFh before passing the function down to the kernel.

2. Bug: The floppy parameters may get trashed by the new 2nd level
   BIOS decompressor in DR-DOS 7.03 IBMBIO.COM under some rare
   conditions. This is not normally visible, but can occur using
   certain unusual boot methods and will cause floppy access to
   behave erratic.
   If you donīt have problems accessing floppies you donīt need to
   worry about this. (Despite the existance of this bug, DR-DOS 7.03
   is otherwise much improved in logging in and accessing non-standard
   floppy formats and other media (like Flash disks) compared to 7.02
   and to MS-DOS/PC DOS in general...)

   Workaround: Try different boot methods.

3. Bug: The (faulty) removal of the previously functional DR-DOS 7.02
   LPT4: built-in device driver will cause the system to crash when
   attempting to redirect AUX to LPT4 using the AUX=4 [D]CONFIG.SYS
   directive.

   Workaround: Do not use AUX=4 under DR-DOS 7.03. [D]CONFIG.SYS
   directives AUX=0 and 1..3, LPT1=..LPT3=[io_address][,timeout] as
   well as LPT4=io_address[,timeout] still work fine under 7.03.

4. Bug: A dangling (hard-wired) pointer in IBMBIO.COMīs discardable
   resume code of the built-in CLOCK$ device driver, which doesnīt
   line up with other code changes in 7.03, may cause the system
   to not come back properly after the system has entered suspend
   mode after very long periods of inactivity.
   This usually manifests itself in EMM386 protection faults under
   TASKMGR, unstable behaviour after the wakeup, or a solid lock.
   This problem may also be visible with some issues of 7.02, but
   not with OpenDOS 7.01 or Novell DOS 7. This problem cannot occur
   on older systems which do not support suspend mode.

   Workaround: Disable any power saving/suspend mode options in
   the machineīs BIOS setup, so that the system never enters
   suspend mode, or reboot the system after a wakeup.

5. Issue: When DR-DOS FDISK or FORMAT are used to format a volume,
   they write a (valid!) BIOS Parameter Block (BPB) table, which
   for some odd reasons is not always properly interpreted by
   MS-DOS/PC DOS, OS/2 (maybe NT) due to the "DRDOS  7" OEM
   label in there.

   The problem is that when these OSes will find this OEM label
   they seem to ignore some of the (valid!) entries in the BPB and
   unnecessarily try to recalculate the geometry values based on
   the remaining values in the BPB. Presumably this undocumented
   behaviour is to cope with actually faulty BPBs written by very
   old issues of MS-DOS/PC DOS and OS/2 themselves?!? (At least
   I have no other reasonable explanation for this strange behaviour.)

   Everything would still be fine if these calculations would be
   correct, but under some conditions (for example unexpected
   cluster sizes) they do not line up with the actual formatting
   of the drive and this will either cause the partition to be
   unaccessable (under OS/2 and maybe NT) or will appear garbaged
   under MS-DOS/PC DOS (this usually occurs for partitions < 128 Mb
   only, where the new DR-DOS FDISK unfortunately assigns a sub-
   optimal cluster size).

   In the worst case write access to a not properly recognized
   partition under MS-DOS/PC DOS may cause the partition to become
   actually garbaged! However, if the partitions look fine under
   MS-DOS/PC DOS (the most common case, fortunately), there is no
   risk to damage them.
   Since DR-DOS uses the BPB info in the correct and documented
   way, it does not have any problems to access such partitions,
   even if they would have non-standard formats.

   Another effect of the use of a DR-DOS BPB can occur when
   reading or writing DR-DOS formatted floppies under Windows.
   When the write protection level is not in the read-only
   position, any read (!) or write access to the medium under
   the Windows 9x GUI - even a simple "DIR A:" in a DOS box -
   will immediately cause Windows to write a garbaged OEM label
   to the medium! This in turn will typically cause some form
   of "read error" or "floppy not formatted" message soon
   later (at least after the next disk change). (I could
   reproduce this on several completely independent Windows 98
   and 98SE installations - 95 and ME have not been tested,
   but I assume they behave similar.)

   It seems as if Windows 9x destroys the OEM label on the medium
   if it finds an unrecognized (though perfectly valid) BPB (as
   per MS/IBM specification), and for unknown reasons it will
   then overwrite the OEM label with an ill-formatted "IHC"
   signature and some kind of time stamp or random number.
   Please note that, strange as it is, this is *not* caused by
   a virus, but by some part of the Windows system. And it only
   occurs under the GUI, not under plain vanilla DOS.
   Since Windows destroys only the eight bytes of the OEM label
   and nothing else in the BPB, FAT or the data area, DR-DOS can
   still happily read and write such floppies without any problems.
   Changing the OEM label back to something reasonable like
   "IBM  3.3" with a disk editor, the floppy can also be accessed
   under Windows again...

   All in all, it comes out that in contrast to offical docs the
   OEM label is not just cosmetics, but is used by MS/IBM systems
   to alter the interpretation of the other values in the BPB.
   Hence, to avoid any problems, the OEM label must be in the
   format "sssssn.n", whereby "sssss" is a (random???) string, and
   "n.n" is a version number with a decimal point in between.
   While other formats are commonly used by 3rd party software,
   they may cause the same behaviour to occur if the BPB values
   do not match Windowsī expectations. Since DR-DOS BPBīs mimic
   those of Compaq DOS/PC DOS 3.31 the version number must be "3.3"
   to ensure a proper interpretation of the BPB.

   Workaround: Either do not use the (otherwise more powerful)
   DR-DOS FDISK and FORMAT utilities and use the MS-DOS counterparts
   instead (DR-DOS has no problems to work with partitions created
   by MS-DOS/PC DOS.). Or, after using the DR-DOS tools, change
   the "DRDOS  7" OEM label to "IBM  3.3" using a disk editor.
   This will fix the problem. You can also decompress the DR-DOS
   utilities with PKLITE -x and patch the OEM label in there to
   match "IBM  3.3" instead of "DRDOS  7".

Well, these issues may look stronger than they are in practise -
in all the years I did not run into any of these problems on a large
number of completely different systems, except for more or less
artificially created conditions during stress tests. Fortunately,
these problems can be easily avoided or worked around.

 Matthias

-- 

Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org