Win'95 seems to have a very serious partitioning flaw in its Fdisk routine
creating the extended partition. The following text describes this flaw in
detail and some of the ways you can avoid it.
Some people didn't seem too interested when I first reported this anomaly
except for the people at MicroFirmware who have been working with me on this
problem, which appears to be a MAJOR bug in the Win'95 operating system. We
will begin to see many, many more reports of this problem as time goes on
because of the authoring of BIOS's that support int13 extensions in order to
allow Win'95 to take full advantage of LBA addressing on the new and larger
EIDE Hard drives, along with the newer systems being shipped with and having
their hard drives formatted with Win'95.
The following is the formula required to have this anomaly occur:
1. You have to have one of the latest BIOS's that support the use of int13
extensions and full LBA.
2. You have to Fdisk using the Win'95 version of the program.
3. You have to have one of the latest EIDE hard drives that support full LBA
and have to have partitioned it into at least two partitions.
Once you have the above ingredients you will unfortunately have the same
problem on your hands. According to Microsoft, they have become aware of the
problem but have no plans to correct it until the release of the next
operating system. Until then save your old DOS disks and Fdisk with them and
then finish the job with Win'95.
By having this problem brought in to the spotlight we be able to help prevent
someone from suffering some very serious losses through data corruption. To
most of the home PC users like myself, the data loss would not be too
serious other than recreating some lost data but the potential disaster for
business is could be astronomical.
Problems with New Partition Types Used by WIN95
FDISK
Part One - WIN95 FDISK Shows PRI or EXT DOS Partition, DOS 6.x Shows
NON-DOS
We have seen some cases where a hard drive will work fine with WIN95
but the drive will not show up when booted under DOS 6.x and the DOS 6.x
FDISK
command will show that the drive has a NON-DOS partition.
Supposedly WIN95's FDISK and DOS 6's FDISK are interchangeable. For the most
part they are - any partition created by MS-DOS 6.0, 6.20, 6.21, or 6.22 (or
even most earlier versions) should work fine with WIN95. WIN95's FDISK
should show these partitions as Primary DOS or Extended DOS Partitions just
as DOS 6's FDISK would. In fact WIN95 actually runs on top of MS-DOS 7.0. The
WIN95/DOS 7 FDISK command resides in the WINDOWS\COMMAND directory. WIN95's
FDISK has added two new partition types, which it may choose to assign to a
drive that it is partitioning. These are type 0Eh for a Primary DOS
Partition and type 0Fh for an Extended DOS Partition. These appear to be
treated the same as type 06h (Primary DOS) and type 05h (Extended DOS)
which are used by MS-DOS 3.3, 4.x, 5.x and 6.x.
WIN95 FDISK may use Type 6 and Type 5 when partitioning a drive or it may use
the newer Type E and Type F. If a partition is labeled as type E or F, then
any DOS version prior to DOS 7 (WIN95) will consider this a NON-DOS Partition
and will not be able to recognize it.
If WIN95 is installed on top of an existing DOS 6.x / WIN3.1 installation,
this problem will not occur since WIN95 is not partitioning the hard drive
and WIN95 will not change an existing partition type. The problem also will
not occur if WIN95 is installed on a new, blank hard drive, since DOS 6.x
can not be installed on top of a WIN95 installation.
The scenario in which we initially discovered this anomaly is also not a
likely one - partitioning drive with WIN95 FDISK and then installing an
earlier DOS. The situation in which this is likely to occur is when a new
hard drive is added to an existing hard drive so that one drive was
partitioned with DOS 6 FDISK and another drive is partitioned with WIN95
FDISK. Sometimes there is no problem since WIN95 FDISK may use the normal
type 6 or type 5. But if the drive is labeled as a type E or F and the system
is booted from the original drive using the option to boot previous DOS
version, then the new drive will not be accessible by DOS 6.x or
earlier.
These new partition types are mentioned in the Microsoft Knowledge Base
http://www.microsoft.com/kb/) in article Q69912.
The reason for these new partition types has to with supporting the new Int13
Extensions (which both our BIOS and WIN95 can use) to take full advantage of
LBA addressing on newer EIDE hard drives. If a hard drive supports LBA and
the BIOS supports LBA, then the BIOS and the drive will use LBA addressing
between themselves. To take full advantage of LBA, it should also be used by
the operating system and applications when communicating with the drive.
Apparently these new partition types are used by WIN95 to accomplish
this.
The solution to the problem of not being able to access a drive partitioned
with WIN95 FDISK is to repartition the drive with DOS 6's FDISK. This
solution was suggested to us by the second and third level of Microsoft's
technical support that we spoke with. Microsoft also explained that this is
an example of a problem that occurs as technology is moved into the future -
in other words, we can't expect all new software and hardware to be backwards
compatible with everything that precedes it or we will not be able to advance
to newer standards.
Part Two - "Phantom" Drives and Potential for Massive Data
Corruption
And there is more to the story. Even in cases where DOS 6.x or earlier is not
in the picture at all, there can still be major problems related to the new
partition types used by WIN95. Apparently these new partition types are used
by WIN95 FDISK when it detects that the BIOS supports the new int13
extensions. The following details an experiment we did to duplicate a problem
reported by a customer.
Motherboard: Micronics JX30
BIOS: Micro Firmware Phoenix BIOS part no. M4HS45 version 4.05.07
Hard Disk 1: Western Digital AC31200 1.2GB EIDE
Hard Disk 2: Western Digital AC2850 850MB EIDE
CD-ROM: NEC CDR260
Zeroed out boot sectors on both drives using DEBUG script (as described in
HDCLEAR.TXT - available on our BBS). Booted with WIN95 Startup Disk - used
WIN95 FDISK to create primary partition on first half of first drive,
extended partition with one logical drive on second half, and one primary
partition on second drive using entire drive. We found that the first drive
had a type 6 (primary) partition and a type F (extended) partition and the
second drive had a type E (primary) partition. Then installed WIN95 with no
problems.
All drive letters look as expected:
HD1: C:, E:
HD2: D:
CD-ROM: F:
Restarted system in MS-DOS mode - drive letters still look OK.
We copied a file to drive E:, we'll call it EFILE1. Then we typed EXIT to go
back to WIN95. We now have an extra drive letter showing up under My
Computer. C:, D: and F: are the same, what was drive E: is now G:, and E: is
now a mirror image of drive C:. Reboot and everything looks OK. (Note - this
did not occur in cases where the system decided to reboot when we typed EXIT
to return to WIN95). We also found this - the file that we copied to drive
E: in DOS mode does not show up if we start a DOS prompt under WIN95 and look
at at drive E:. If we now copy a different file, EFILE2, to drive E:, this
file will not show up if we restart in DOS mode. The other file, EFILE1, will
still be present. We edited the partition table to change the primary
partition on the first drive to a type E: - same results. We then changed
all partition types to type 5 and 6 - all problems disappeared. Also - we
later repeated the above experiment with just one hard drive, also
partitioned into a primary and an extended partition, and had the same
results.
On further investigation our engineers found that WIN95 is modifying some of
the partition information in memory (see last section below) when changing
between DOS mode and WIN95. This happened only on the partitions that were
marked as type E or type F. This did not occur when the 32BitDisk drivers
were disabled in WIN95.
These findings are preliminary, but we believe this to be a bug in WIN95. We
are still looking into this and will attempt to pursue this with Microsoft.
We welcome any information on this problem. We may possibly decide to remove
the int13 extensions from our BIOS ("dumbing it down") to prevent this
problem.
In the meantime we recommend that all large drives to be used with WIN95
under Phoenix 4.04 or 4.05 BIOS (or any BIOS implementing int13 extensions)
be partitioned with DOS 6.22 FDISK. In the case of drives already using a
type E or type F partition, it is possible to just edit the partition table
and change the byte that describes the partition type. We can't guarantee
that this is safe to do but it seems to be. This procedure is described in
the following section.
Also - we later repeated the above experiment with just one hard drive, also
partitioned into a primary and an extended partition, and had the same
results.
Here is a DEBUG script that can be used to look at the partition table to
identify the partition type. Various disk utilities can be used
instead.
C:\>DEBUG
- A 100
xxxx:xxxx MOV AX,201 (ignore xxxx:xxxx segment:offset values on left)
xxxx:xxxx MOV BX,200
xxxx:xxxx MOV CX,1
xxxx:xxxx MOV DX,80 (or use 81 for 2nd drive, 82 for 3rd, 83 for
4th)
xxxx:xxxx INT 13
xxxx:xxxx INT 3
(press ENTER an extra time here to return to dash prompt)
- G=100
(ignore register dump)
- D 3BE 3FF (following output is a hex dump of the partition table)
x1 x2
xxxx:xxxx x3 x4 x5 x6 x7 x8 x9 10-11 12 13 14 15 16 xx xx
xxxx:xxxx xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx
xxxx:xxxx xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx
xxxx:xxxx xx xx xx xx xx xx xx xx-xx xx xx xx xx xx 55 AA
- Q (quits back to DOS prompt)
The hex dump resulting from above procedure shows the partition table for the
first hard drive. The above values 1 through 16 are the 16 bytes (each
represented by 2 digits of hexadecimal) that hold the information for one
partition. There are four 16-byte slots - so that four partitions can be
defined on the drive - for instance, a Primary DOS partition and an Extended
DOS partition may be defined, as well as partitions created by other
operating systems. These four 16-byte slots are followed by the values 55
AA which identifies this as a valid partition table. The 55 AA also
indicates the end of the boot sector. The fifth byte in each slot (5 above)
indicates the partition type. Here are the partition types used by MS-DOS as
indicated in Q69912:
Type: Size: FAT type: First used in:
01 - PRI DOS 0-15MB 12-bit FAT MS-DOS 2.0
04 - PRI DOS 16-32MB 16-bit FAT MS-DOS 3.0
05 - EXT DOS 0-2GB n/a MS-DOS 3.3
06 - PRI DOS 32MB-2GB 16-bit FAT MS-DOS 4.0
0E - PRI DOS 32MB 16-bit FAT Windows 95
0F - EXT DOS 0-2GB n/a Windows 95
Here are what some of the other values indicate:
1 - Active Status 80 = Active
00 = Not Active
2 - Starting Head of Partition
3/4 - Starting Cylinder and Sector (combined)
5 - Partition Type
6 - Ending Head of Partition (1 less than total number of heads)
7/8 - Ending Cylinder and Sector (combined)
9/10/11/12 - Relative Partition Sector Start
(no. of sectors between partition table and start of partition)
13/14/15/16 - Size of Partition (in sectors)
Here is a DEBUG script that can be used to modify the partition type. Various
disk utilities can be used instead.
CAUTION: Be very careful not to make any mistakes in this
procedure.
This also assumes that DOS is the only OS in the picture and that
there is nothing complicated about the hard drive setup is - if
partitions from other operating systems are present, results may
vary. Also we cannot guarantee that this procedure is safe anyway.
We strongly recommend that a drive be repartitioned with DOS 6.x
FDISK instead of modifying the partition table. Please make sure
that you have a complete backup before beginning.
Note that the first part of this script is the same as that above.
You can use the above script to look at the partition table and then just
continue on with the first "- E" below instead of quitting with "-Q".
C:\>DEBUG
- A 100
xxxx:xxxx MOV AX,201 (ignore xxxx:xxxx segment:offset values on left)
xxxx:xxxx MOV BX,200
xxxx:xxxx MOV CX,1
xxxx:xxxx MOV DX,80 (or use 81 for 2nd drive, 82 for 3rd, 83 for 4th)
xxxx:xxxx INT 13
xxxx:xxxx INT 3
(press ENTER an extra time here to return to dash prompt)
- G=100
(ignore register dump)
- E 3C2 (to show type of partition in first slot)
xxxx:xxxx NN. (ignore segment:offset to left)
NN indicates partition type. To change the type, just
type in the new type immediately following thedot and
then press ENTER to return to dash prompt
- E 3D2 (to show type of partition in second slot)
This will also return a segment:offset valuefollowed
two digits of hex and a dot. Change as above.
- E 3E2 (to look at 3rd entry - normally 00)
- E 3F2 (to look at 4th entry - normally 00)
So far changes have only been made in memory - you can bail out by
typing Q at the dash prompt. To write these changes to the
partition table, continue:
- A 100
xxxx:xxxx MOV AX,301
(press ENTER an extra time to return to dash prompt)
- G=100 (ignore register dump)
- Q (quits to DOS prompt)
Here is some additional detail from our cheif engineer on what bytes are
being modified:
The bytes that are getting changed are in one of DOS's data tables;
It's something like this:
Offset Description
------ -----------
00h DWORD pointer to next table entry; offset is 0FFFFh if last one.
04h BYTE BIOS drive (80h=first hard drive, etc.)
05h BYTE relative DOS drive (0=A,1=B,2=C,etc)
06h WORD sector size
08h BYTE number of sectors per cluster
09h WORD number of reserved sectors
0Bh BYTE number of copies of the FAT
0Ch WORD number of root directory entries
0Eh WORD number of sectors per DOS drive (for drives <32M)
10h BYTE media type (0F8h for hard drive partitions)
11h WORD number of sectors per FAT
13h WORD number of sectors per track
15h WORD number of heads
17h DWORD number of hidden sectors
1Bh DWORD number of sectors per DOS drive (for drives >32M)
1Fh-26h ?????
27h-3fh Seems to be a duplicate of offsets 06h-1Eh
40h-4Ah ?????
4bh-55h Volume label
56h-5Ah ?????
5Bh-63h Filesystem type (FAT12 or FAT16)
The descriptions for offsets 06h-1Bh are based on what seems to be exactly
the same data in the DOS boot sector for the partition.
The problem encountered, at for drives with partition type 0fh, is that the
data at offset 17h in this structure seems to be based from the beginning of
the physical drive, not from the partition table defining the partition as is
usually the case. Once Windows 95 is started with the 32 bit disk access
enabled, something changes this value to that of the relative sector start
field in the partition entry for that partition. At this point, Windows 95 is
happy with the extended partition, but if you exit back out to DOS, or run an
program in single application mode, the extended partition looks trashed (as
DOS is looking in the completely wrong location on the drive for it). Of
course, attempting to write to the extended partition at this point will
trash data elsewhere on the drive too.
------------------------------------------------------------------------------
Micro Firmware Technical Support
-----------------------------------------------------------------------------
Voice 405-321-8333 email support@firmware.com
Fax 405-321-8342 WWW
http://www.firmware.com
BBS 405-573-5538 CIS GO PCVEND Section 8
IE 7
Firefox 2.0
