Mail Archives: opendos/2002/01/10/02:40:20
Hmmm ... Well, I can tell you what happens on Windoze 95B too :
It changes the OEM ID to this strange "xxxxxIHC" string. However,
I had never noticed this before, because the diskettes continue to
work properly and never produces "read error" or "floppy not formatted"
messages.
I also tried changing the OEM ID from "xxxxxIHC" to "DRDOS 7."
(similar to "DRDOS 7" but without the extra space and with added
decimal point), but this was still converted back to "xxxxxIHC".
Joe.
> -----Original Message-----
> From: Matthias Paul [SMTP:Matthias DOT Paul AT post DOT rwth-aachen DOT de]
> Sent: Wednesday, October 31, 2001 6:53 AM
> To: opendos AT delorie DOT com
> Subject: FYI: Bugs in DR-DOS 7.03
>
------ snip ------
> 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
>
>
>
- Raw text -