Mail Archives: opendos/2000/11/07/12:12:30
Hi all,
Now that the signal-to-noise-ratio has hopefully again become
positive, I hope that this info may help those who are still
interested in technical and DOS related details and who may
wish to further investigate the "FDISK problem".
This is partially based on a post I made back on 2000-03-14
and stuff I sent to Ralf for inclusion in INTER61 (and will
probably show up with INTER62). BTW. Ralf Brown's Interrupt
List INTER61 (FreeDOS people call it RBIL) can be found at
http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html
Please send any additions and corrections to me (or directly
to Ralf, if you like).
Format of a DOS 2.0+ boot sector:
00h 3 BYTEs Jump to the bootstrap loader
03h var BPB or extended BPB depending on OS version and
filesystem
var bootstrap loader
1FDh BYTE (DOS 3.3, Compaq DOS 3.31 and DR DOS 5.0-7.03 FDISK)
boot unit
Format of a DOS FAT12/FAT16 boot sector:
Offset Size Description
00h 3 BYTEs Jump to the bootstrap loader
DOS checks the first byte to be either E9h (JMP
NEAR) or EBh (JMP SHORT). In the second case the
3rd byte is checked to be 90h (NOP).
The DR DOS family additionally allows a first
byte of 69h.
--- BPB---
03h 8 BYTEs OEM ID either indicating the OS or the formatter
Note: The correct format of the OEM string is 5
chars "abcde" description plus "x.y" version
number.
While the OEM string is don't care for any OS of
the DR DOS family, the version number in the OEM
ID is (undocumented) *not* don't care for MS-
DOS/PC DOS and OS/2 (probably also not for NT),
as depending on the version number these OSes
decide how to interpret the remainder of
the BPB, and which entries to trust.
Changing this to values not recognized by these OS
may cause serious malfunctioning under MS-DOS/
PC DOS and OS/2.
Examples:
- OS/2 Warp 3 cannot access hard disk partitions
formatted and/or SYSed under Novell DOS 7 -
DR-DOS 7.03, while it has no problems to access
DR DOS 6.0 partitions, which used "IBM 3.3".
The reason is simply, that Novell DOS 7 uses
"NWDOS7.0" as OEM label causing OS/2 to
interpret the BPB in the DOS 4.0+ style, not
the Compaq DOS 3.31 style. Changing the label
to "IBM 3.3" will fix the problem.
Note, that this is not a DR-DOS bug, as the BPB
is properly filled out with the correct values.
TODO: Test with OS/2 Warp 4!!!
- MS-DOS 6.22 can seriously corrupt FAT16
partitions < 128 Mb when created by DR-DOS
7.02/7.03 FDISK 2.00-2.14, as they assign a
"non-standard" cluster size (4 Kb instead of 2
Kb). Just changing the OEM label to "IBM 3.3",
without modifying the cluster size etc.
fixes the problem. Apparently MS-DOS does not
use the cluster size value in the BPB when it
does recognize the OEM label, and its own
calculations based on the other values are
wrong.
Also, this is not a DR-DOS FDISK bug, as the
BPB is filled out correctly for this kind of
partition.
- MS-DOS 7 / Windows 98 can no longer log-in
floppies formatted under DR DOS when the OEM
label is in an incompatible format like
"?????IHC", as apparently modified to by some
unknown anti-virus protection.
Instead it displays "Sector not found" etc.
error messages. Such floppies are still
readable without any problems under DR-DOS, and
SCANDISK, CHKDSK, etc. cannot find any problems
as there are none!
Changing this back to "IBM 3.3" or "DRDOS702"
will fix the problem.
Known OEM strings:
"MSDOS2.0"
"MSDOS3.1" MS-DOS 3.1
"MSDOS3.3" MS-DOS 3.3
"MSDOS4.0" MS-DOS 4.01
"MSDOS5.0" MS-DOS 5.0 - 6.22
Note: PC Tools DISKFIX has a bug when
the version number in the OEM label is
greater than 5.0.
"MSWIN4.0" Windows 95 (and Windows NT 4
FlexBoot???)
"MSWIN4.1" Windows 95 OSR 2 - Windows 98 SE
"IBM 3.0" PC DOS 3.0
Note: Reportedly the PC DOS 3.0 SYS
utility erroneously created BPBs that
were starting at offset +02h of the
boot sector due to a *short* jump at
offset +00h.
"IBM 3.1" PC DOS 3.1
"IBM 3.2" PC DOS 3.2
"IBM 3.3" PC DOS 3.3, DR DOS 5.0 - 6.0,
and FDISK of Novell DOS 7, OpenDOS
7.01, DR-OpenDOS 7.02, DR-DOS 7.02
"IBM 5.0" PC DOS 5.0, Compaq MS-DOS 5.0
"IBM 6.0" PC DOS 6.1
"IBM 7.0" PC DOS 7
"IBM 10.0" OS/2 1.0
"IBM 20.0" OS/2 2.0
"DIGITAL " DOS Plus 1.2 - DR DOS 5.0 "Leopard"
BETA 3
"NWDOS7.0" Novell DOS 7 FORMAT & SYS
Note: The BPB usage for this kind of
boot sector is identical to the DR DOS
"IBM 3.3" style.
"OPENDOS7" OpenDOS 7.01 FORMAT & SYS
Note: The BPB usage for this kind of
boot sector is identical to the DR DOS
"IBM 3.3" style.
"DRDOS702" DR-OpenDOS 7.02 FORMAT & SYS
Note: The BPB usage for this kind of
boot sectors is identical to the
DR DOS "IBM 3.3" style.
"DRDOS 7" DR-DOS 7.02 FORMAT & SYS, DR-DOS 7.03
Note: The BPB usage for this kind of
boot sectors is identical to the
DR DOS "IBM 3.3" style.
"DRDOS7.X" DR-DOS 7.02 - DR-DOS 7.03 FDISK for
FAT32
"PARAGON!" Paragon Technology Systems PTS-DOS
6.51 SYS
also: Paragons' PTS-DOS 2000 (SYS.COM/
SYSFAT32.COM) for FAT12/16/32
"DOSBOOT" Paragon Technology Systems PTS-DOS
6.51 FORMAT
"PTSDOS60" PhysTechSoft PTS-DOS 6.60 (SYS), 6.70,
2000
"PTS 6.60" PhysTechSoft PTS-DOS 6.60 FORMAT
"PTSDOS70" PhysTechSoft's PTS-DOS 7 BETA 1 (1995)
"DLDOS622" Datalight ROM-DOS 6.22 FAT12/FAT16
"DLDOS710" Datalight ROM-DOS 7.10??? FAT32
(disabled in ROM-DOS 6.22 SYS)
"RxDOS6.0" RxDOS 6.0
"RxDOS7.2" RxDOS 7.2
"?????IHC" anti-virus-protection???
Note: This signature was seen in many
boot images from various sources,
including from major companies like
DeLL.
This signature was also seen created
when under Windows 98 a floppy was
accessed in a drive (even a "DIR
A:" was sufficient!!!).
The "IHC" was always the same, the
"?????" appears to be a random binary
code, changing every time. The machine
had an ASUS MB with ALI chipset, Award-
BIOS 4.51PG, and "ChipAwayVirus",
but the observed modification only
happened under the GUI, not on plain
MS-DOS 7.10 or DR-DOS.
BUG: Since the version number in the OEM
label gets overwritten, this will make
DR-DOS floppies unreadable under
MS-DOS and Windows 9x, since
for compatibility reasons even the
DR-DOS 7.03 BPB still uses the hidden
sectors field in Compaq DOS 3.31
style. This is no problem, and
the floppies are still accessable
under DR-DOS but MS-DOS needs the OEM
string to decide how to interpret the
remainder of the BPB, and as the OEM
string gets overwritten, MS-DOS can
no longer properly log-in such
floppies. The workaround is to
change the OEM label back to
"IBM 3.3" using a disk editor.
BTW. This problem does not show with
media formatted with "non-standard"
OEM labels (e.g. fresh pre-formatted
floppies out of the box, or formatted
under other DOSes with "non-standard"
OEM labels) simply because the other
BPB entries are 100% MS-DOS 4.00+
compatible, while the DR-DOS entries
are still 3.31.
0Bh WORD Bytes per sector (usually 512)
0Dh BYTE Sectors per Cluster
0Eh WORD Reserved sectors at beginning (normally 1, the
boot sector). The FAT area begins after the
reserved sectors.
10h BYTE FAT copies (normally 2)
11h WORD Root directory entries: This is normally 512.
This shows the maximum number of files and
directories that root directory can hold. This
is because the root directory has a constant
length (512 entries * 32 bytes/entry /
512 bytes/sector = 32 sectors)
13h WORD Total sectors on disk (small): If we have less
than 65536 sectors in the partition, this value
contains the number. If it's more, then the
number is stored in bytes 20h- 23h.
This is an entry that was left from the old DOS
versions, when partitions could have up to 65536
sectors.
15h BYTE Media descriptor byte: This byte is always F8h
for hard disks.
16h WORD Sectors per FAT: This shows how many sectors
does each FAT take up. This depends on how many
clusters the partition has, and what is the FAT
type (12bit/16bit).
This can be from 1 to 255 sectors.
Note: MS-DOS has a bug when setting this to 256
sectors!!!
18h WORD Sectors per track: Same as the physical disk's
sectors per track value.
1Ah WORD Sides: Same as the physical disk's head number.
---DOS 2.0???---
1Ch WORD hidden sectors
end of structure???
---DOS 3.0+???---
1Ch DWORD Special hidden sectors: This is how many sectors
exist between the partition's description sector
and the boot sector. Usually one track.
Note: If not using 32-bit calculation, the high
byte of this entry must be zero.
20h DWORD Big total number of sectors: If we have more
than 65536 sectors in the partition, their
number is written here.
Note: If not using 32-bit calculation, this entry
must be zero.
---DOS 5.0+ extended parameter block in boot sector---
24h WORD Physical drive number: This is the physical
drive number (c: 80h, d: 81h etc.).
or BYTE drive unit
BYTE reserved
26h BYTE Extended boot record signature: This marks an
extended boot record. If it is 29h, the disk was
formatted by DOS 4.0+??? 5.0???
27h DWORD Volume serial number
2Bh 11 BYTEs Volume label
"NO NAME "
Sometimes also: (PTS-DOS) "NO LABEL "
36h 8 BYTEs FS ID: "FAT12 ", "FAT16 ", "UNKNOWN ".
Bootstrap loader starts approximately here...
BUGS: Under PC DOS 3.30 the total number of sectors and the big
total number of sectors can sometimes both be zero (due to
OS/2 SETUP???). If MS-DOS/PC DOS IO.SYS/IBMBIO.COM
detects such boot sectors it uses the value from the
partition record rather than the boot sector.
The PC DOS 3.3 FDISK and OS/2 1.0 FDISK had a bug where they
calculated a maximum number of sectors for a drive (total
sectors + hidden sectors) to be 10000h, while the
PC DOS 3.3 IBMBIO.COM can only handle a maximum of
FFFFh. If later issues of PC DOS/MS-DOS detect this,
they decrement the total number of sectors by 1.
DR DOS 5.0 - 7.03 FORMAT/SYS FAT12/FAT16 extended boot sector
parameter table:
00-3Dh same as for DOS 5.0+
3Eh WORD physical sectors per cluster (a 512 bytes)
40h WORD target load offset (0000h)
42h WORD target load segment (0070h) (can be patched)
44h WORD last cluster value (FFFFh)
46h 12 BYTEs boot file name ("IBMBIO COM",0)
52h WORD location where BIOS expects directory segment
(0050h)
54h WORD FAT buffer segment low (0800h)
56h WORD FAT buffer segment high (1800h)
Note: The DR DOS boot sector reads in the whole boot file (up to 29
Kb), which can be physically located anywhere on disk as
long as the file is listed in the root of the drive (and
the drive has no more than 512 root dir entries) and it
does not need to be stored continously. Hence it is
possible to update the system files with the standard COPY
command. The boot sector also allows to boot off logical-
sectored media with 1 Kb sectors, e.g. Wyse partitions,
and copes with root directoriess that aren't an exact
fit with sectors.
DR DOS 5.0 - 7.03 FDISK FAT12/FAT16 extended boot sector
parameter table:
00h..23h same as for DOS 3.3
24h WORD physical sectors per cluster (a 512 bytes)
26h BYTE number of sectors in image
27h BYTE reserved
28h WORD target load offset (0000h)
2Ah WORD target load segment (0070h) (can be patched)
2Ch WORD last cluster value (FFFFh)
2Eh 12 BYTEs boot file name ("IBMBIO COM",0)
3Ah WORD location where BIOS expects directory segment
(0050h)
3Ch WORD FAT buffer segment low (0800h)
3Eh WORD FAT buffer segment high (1800h)
40h BYTE count of allowed retries when reading sectors
(10)
---optional---
41h BYTE reserved / count of sectors to read (1)
...
1FDh BYTE physical boot drive unit (also used by Compaq
DOS 3.31 and DOS 3.3)
Note: The DR DOS boot sector reads in the whole boot file (up to 29
Kb), which can be physically located anywhere on disk as
long as the file is in listed in the root of the drive
(and the drive has no more than 512 root dir entries)
and does not need to be stored continous. Hence
it is possible to update the system files with the standard
COPY command. The boot sector also allows to boot off
logical-sectored media with 1 Kb sectors, e.g. Wyse
partitions, and copes with root directors that aren't an
exact fit with sectors.
######################################################################
It is actually nothing more than switching the OEM label xxxxxyyy
in FDISK, FORMAT, and SYS back to "IBM 3.3" instead of "DRDOS 7" /
"DRDOS702". Of course, you can do the same using DISKEDIT or DEBUG.
This also fixes serious OS/2 problems to access DR-DOS partitions.
As far as I have tracked this down, the problem was not the xxxxx
string (like "MSDOS", "MSWIN", "IBM ", "DIGITAL", or "DRDOS"), but
the yyy number (usually in the format y.y):
MS-DOS, PC DOS and OS/2 use it to switch between various historic
forms how to use the entries in the BPB table at the beginning of
the boot sector.
For compatibility with Compaq DOS 3.31 and older issues of DR DOS,
DR-DOS 7 still uses the entry for hidden sectors as an absolute value,
while (at least for logical drives in an extended partition) it is
used relative to the current partition by recent issues of MS-DOS etc.
(usually 3Fh always on current harddisks).
Changing the version number in the OEM label to anything but "3.3"
will since break OS/2 (and under some conditions - for example unusual
cluster sizes - also MS-DOS/PC-DOS). However, its not as easy as just
changing the boot sector setup, because the cause for the
incompatiblity is not the FORMAT, SYS, or FDISK utility itself, but
the Generic IOCTL function they use to retrieve that value. Changing
the reported value there would break all older issues of these
utilities because they do not contain strict tests for the DOS version
number as the MS-DOS/PC DOS tools do.
This could cause malfunction when run on future issues of DR-DOS.
So, it's best to just stick with "IBM 3.3" for now...
Matthias
-------------------------------------------------------------------
Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------
- Raw text -