Apparent Win98SE IO.SYS bug

Hi,

I have had trouble with W98SE and LBA partitions. I was getting phantom
drives on some PC's. It turns out to be a bug in IO.SYS that occurs
when an LBA partition exists in or follows a 0x05 extended partition.

The problem is that when IO.SYS is calculating the absolute key to
access a partition it adds the offset for the partition to the relative
key twice (rather than just once).

It seems easy to patch IO.SYS to fix this problem but any such patch may
have unwanted side-effects. I have searched (mainly via google) but
can't find any reference to this error anywhere.

Does anyone know about this error and any info or fixes for it ?

-- Steven

On Tue, 22 Feb 2005 12:41:37 +1000, Steven wrote:

Hi,

I have had trouble with W98SE and LBA partitions. I was getting phantom
drives on some PC's. It turns out to be a bug in IO.SYS that occurs
when an LBA partition exists in or follows a 0x05 extended partition.

The problem is that when IO.SYS is calculating the absolute key to
access a partition it adds the offset for the partition to the relative
key twice (rather than just once).

It seems easy to patch IO.SYS to fix this problem but any such patch may
have unwanted side-effects. I have searched (mainly via google) but
can't find any reference to this error anywhere.

Does anyone know about this error and any info or fixes for it ?

-- Steven

You find the rules you have to follow here (DOS/Windows 95/98/ME
Partition Issues):

http://www.partitionsupport.com/partitionnotes.htm


If an extended partition ends cylinder 1024 or later, the type of the
extended partition must be type 0F. If it is not, data damage will
occur. Links to next extended partition tables should still be type
05.

If the last partition in any extended partition is not a FAT
partition, each disk cannot contain more than one primary FAT
partition. If this rule is not followed, data damage can occur.

If the last partition in any extended partition is not a FAT
partition, all extended partitions should be of the same type. If one
disk has an extended partition type 0F, all extended partition on all
disks in the system must be type 0F. Damage can occur if this rule is
not followed.

If the extended partition is type 85 (Linux Extended), the extended
partition does not count as an extended partition in these matters.
--
Svend Olaf

On Tue, 22 Feb 2005 08:06:38 GMT, (Svend
Olaf Mikkelsen) wrote:

You find the rules you have to follow here (DOS/Windows 95/98/ME
Partition Issues):

http://www.partitionsupport.com/partitionnotes.htm

Thanks for the link and all the work.

If an extended partition ends cylinder 1024 or later, the type of the
extended partition must be type 0F. If it is not, data damage will
occur. Links to next extended partition tables should still be type
05.

Yes, this can be a hassle. However, it is possible to have a 0x05
partition exceeding cylinder 1024 that works correctly if you write a
null EBR to cylinder 1023 and set the LBA continuation key in the
previous EBR to point to cyl 1024 (or wherever the next logical drive
is). This allows DOS to access all logical drives before cyl 1023 and
other systems (W98, NT, Linux) will access all logical drives. The
major restriction here is that no logical drive can span cyl 1023. This
idea works because systems that use CHS stop when the null EBR is
encountered but systems that use LBA bypass this EBR and continue along
the chain.

If the last partition in any extended partition is not a FAT
partition, each disk cannot contain more than one primary FAT
partition. If this rule is not followed, data damage can occur.

If the last partition in any extended partition is not a FAT
partition, all extended partitions should be of the same type. If one
disk has an extended partition type 0F, all extended partition on all
disks in the system must be type 0F. Damage can occur if this rule is
not followed.

These are manifestations of the bug I am reporting. But they only apply
to W95/W98/ME and not to NT4 or NT5 or Linux or even FreeDOS. I haven't
tested with W95 or ME (but have noted your comments about the
commonality of the restrictions).

It seems odd that one sub-family of Windows is different from the rest
of the world. Do you know any good reasons for preserving this
difference ? I assume there must be some sense behind it as MS has
never offered a fix.

-- Steven

What's the EBR?

"Steven" wrote in message
...
On Tue, 22 Feb 2005 08:06:38 GMT, (Svend
Olaf Mikkelsen) wrote:

You find the rules you have to follow here (DOS/Windows 95/98/ME
Partition Issues):

http://www.partitionsupport.com/partitionnotes.htm

Thanks for the link and all the work.

If an extended partition ends cylinder 1024 or later, the type of the
extended partition must be type 0F. If it is not, data damage will
occur. Links to next extended partition tables should still be type
05.

Yes, this can be a hassle. However, it is possible to have a 0x05
partition exceeding cylinder 1024 that works correctly if you write a
null EBR to cylinder 1023 and set the LBA continuation key in the
previous EBR to point to cyl 1024 (or wherever the next logical drive
is). This allows DOS to access all logical drives before cyl 1023 and
other systems (W98, NT, Linux) will access all logical drives. The
major restriction here is that no logical drive can span cyl 1023. This
idea works because systems that use CHS stop when the null EBR is
encountered but systems that use LBA bypass this EBR and continue along
the chain.

If the last partition in any extended partition is not a FAT
partition, each disk cannot contain more than one primary FAT
partition. If this rule is not followed, data damage can occur.

If the last partition in any extended partition is not a FAT
partition, all extended partitions should be of the same type. If one
disk has an extended partition type 0F, all extended partition on all
disks in the system must be type 0F. Damage can occur if this rule is
not followed.

These are manifestations of the bug I am reporting. But they only apply
to W95/W98/ME and not to NT4 or NT5 or Linux or even FreeDOS. I haven't
tested with W95 or ME (but have noted your comments about the
commonality of the restrictions).

It seems odd that one sub-family of Windows is different from the rest
of the world. Do you know any good reasons for preserving this
difference ? I assume there must be some sense behind it as MS has
never offered a fix.

-- Steven

On Wed, 23 Feb 2005 14:44:35 +1000, Steven wrote:

Yes, this can be a hassle. However, it is possible to have a 0x05
partition exceeding cylinder 1024 that works correctly if you write a
null EBR to cylinder 1023 and set the LBA continuation key in the
previous EBR to point to cyl 1024 (or wherever the next logical drive
is). This allows DOS to access all logical drives before cyl 1023 and
other systems (W98, NT, Linux) will access all logical drives. The
major restriction here is that no logical drive can span cyl 1023. This
idea works because systems that use CHS stop when the null EBR is
encountered but systems that use LBA bypass this EBR and continue along
the chain.

I assume you need type 05 for DOS 6 or OS/2.

OK, nice, although I cannot right now follow the entire significance
of this. I just remember that the type of the extended partition both
influences the way DOS/Windows follows partition tables, and if
extended interrupt 13h is used to access the partitions. The
principles are different between pure DOS 7.x and Windows 95/98/ME,
but both DOS and Windows require that the rules mentioned are
followed.

These are manifestations of the bug I am reporting. But they only apply
to W95/W98/ME and not to NT4 or NT5 or Linux or even FreeDOS. I haven't
tested with W95 or ME (but have noted your comments about the
commonality of the restrictions).

It seems odd that one sub-family of Windows is different from the rest
of the world. Do you know any good reasons for preserving this
difference ? I assume there must be some sense behind it as MS has
never offered a fix.

The idea was that type 0F should replace type 05 in never operating
systems versions so type 05 partitions would be compatible with
previous tools and operating systems. I however do not remember what
Windows NT did.

Linux partitioning tools previously caused a tremendous amount of data
loss by creating extended partitions type 05, but nowhere near the
amount of data lost each day due to the Windows 2000 128 GB bug. (The
need to set a registry key, even if service pack 4 is installed).

Regarding the DOS/Windows bugs, I assume nobody at Microsoft know
about them.
--
Svend Olaf

Thanks.

"Steven" wrote in message
...
On Wed, 23 Feb 2005 17:04:07 -0000, "SFB - KB3MM"
wrote:

What's the EBR?

I think it stands for extended boot record. One of these precedes each
logical drive in the extended partition and it normally contains an
entry describing the logical drive and a second entry referencing the
next section in the extended partition.

It's like an MBR (master boot record) in its layout (4 entry partition
table) but it doesn't contain any boot code.

-- Steven

On Wed, 23 Feb 2005 17:04:07 -0000, "SFB - KB3MM"
wrote:

What's the EBR?

I think it stands for extended boot record. One of these precedes each
logical drive in the extended partition and it normally contains an
entry describing the logical drive and a second entry referencing the
next section in the extended partition.

It's like an MBR (master boot record) in its layout (4 entry partition
table) but it doesn't contain any boot code.

-- Steven

On Wed, 23 Feb 2005 20:02:19 GMT, (Svend
Olaf Mikkelsen) wrote:

I assume you need type 05 for DOS 6 or OS/2.

Yes, quite right. I still use systems that have DOS.

Regarding the DOS/Windows bugs, I assume nobody at Microsoft know
about them.

If there isn't a fix I think it is safe to assume there won't be one
now. IO.SYS only needs a one byte change (offset 3A01 was 75 now EB) to
fix the problem.

-- Steven