From: "Matthias Paul" Organization: Rechenzentrum RWTH Aachen To: opendos AT delorie DOT com Date: Thu, 21 Sep 2000 18:07:41 +0100 Subject: Re: DRDOS FDISK X-mailer: Pegasus Mail v3.22 Message-ID: <2497644673D@reze-1.rz.rwth-aachen.de> Reply-To: opendos AT delorie DOT com On Mon, 18 Sep 2000 Robert W Moss wrote: > > Second, it writes a strange OEM ID string. Something like > > "DRDOS 7" if memory serves. This ID string is probably > > purely cosmetic for DR-DOS, but MS-DOS uses it to decide > > whether or not to "trust" the values in the BIOS parameter > > block which specify (for example) the cluster size... and, > > indirectly, the start of the root directory.... > > > > This ID string was covered by Paul Mattias in a post several months ago. > Several different entries were used by DRDOS, NDOS7, OPENDOS7.x, > IBM PCDOS. Yep. It's true that I wrote about it some time ago and did a quite huge amount of research to isolate the problem and find the trigger conditions for my independent development on DR DOS. The results of this are already reported to Ralf Brown for inclusion in his INTERxx list, but unfortunately didn't showed up in INTER61. For those interested, it will probably be covered in INTER62 (INT 19h). I know it sounds strange, but it is actually true what Charles Dye wrote (he originally isolated the problem long before I even knew about it): MS-DOS/PC DOS, OS/2 (and probably NT too) use the OEM label in the boot sector to decide which other fields in the BPB (the BIOS Parameter Block) at the start of the boot sector to trust on and which other values to leave alone. My research revealed that they probably do this to detect and work around bugs in their *own* history. Early issues of MS/PC-DOS FDISK and FORMAT sometimes wrote invalid data into the tables. However, it was never documented anywhere, that the OEM label is no longer don't care. A quick fix is to just replace the OEM label in the boot sectors created by DR DOS "xxxxxyyy" by "xxxxx3.3", preferable "IBM 3.3". The "xxxxx" is don't care, but the "yyy" must be in the format "n.n", and should match the style of BPB written to the disk. Version numbers above 5.0, however, can cause problems with some 3rd party disk utilities like PC Tools. You can do this using DEBUG or using a Disk Editor. Partitions using this old signature will work OK with MS-DOS/PC DOS and OS/2 in all known cases. You can also patch FORMAT, FDISK, and SYS to use these signatures after unpacking them using "PKLITE filename -x". (But don't touch the FAT32 BPB prototype in FDISK.) However, it would be better to make the use of the BPB entries identical to the BPBs written by MS-DOS 6 or 7 (DR DOS writes them in Compaq or PC DOS 3.3 style, hence the old signature "IBM 3.3"), but this is not applicable for a field patch. This would also fix another problem I saw on a Windows 98 machine with Chip Away Virus in the ROM-BIOS. On this machine, the OEM label is overwritten with a special "IHC" checksum every time you access a floppy (even a simple "DIR a:" with a non-write-protected media will be sufficient). No other changes are made to the media, however. I saw this only when the GUI was up, not under plain DOS 7 nor DR-DOS. It is my assumption that this behaviour is due to this Anti-Virus feature of the ROM-BIOS (I am not completely sure about this, but no virus-scanner was able to detect a virus). The problem is, that overwriting the OEM label of a floppy formatted under DR-DOS 7.02+ will again trigger the problem mentioned above, and Windows 98 will no longer be able to access the media, while there are no problems under DR-DOS, because it definitely does not make any use of th OEM label... > It was not purely cosmetic and was used basically for the same reasons > MSDOS (all versions) used it. If you check back in the archives you > should be able to find it and the changes he made to correct it in the > OPENDOS/DR-DOS/DRDOS versions. The problem is that these changes have still not been made public by Caldera/Lineo, although this was fixed more than a year ago, and, of course, I cannot (at present) make them public myself... I still hope future will bring a good solution for everyone... Matthias ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html -------------------------------------------------------------------