Patched IO.SYS for 9x/ME

[rloew]

I am still trying to determine the effect of the +3A01 Patch. It is supposed to fix the doubling of the Partition Start Sector.

I setup the suggested Type '0C' Partition within a Type '05' Partition.

The +3A01 Patch alone does not correct the problem. The +206C Patch corrects the problem, with or without, the +3A01 Patch.

So far I haven't seen a reason for the +3A01 Patch as the +206C Patch seems sufficient for the intended purpose.

@Phellum: Is there any configuration that requires the +3A01 Patch?

[dencorso]

I'll take this oportunity to ask a rather complex question, so, please, bear with me:

For Extended Partition Boot Records (EBRs), is the Partition-Type Descriptor (entry offset 4) of the Second Partition Table Entry (when it exists) always "05", or should it follow the actual Partition-Type Descriptor (be it "05" or "0F") of the Extended Partiton it exists in?

In other words, if I have a "0F" Extended Partition, there will be a daisy-chain of EBRs inside it, with two entries per boot record (except for the last one): the descriptor for the first entry corresponds to the type of the Logical Partition that follows, but the second entry (which is just a pointer to the next EBR) should be of type "0F" or "05"?

It seems to me they're always "05", regardless... Or is it irrelevant whether it's "0F" or "05", in this case?

I know this question is not quite on-topic, but I figured this was the nearer to on-topic it'll ever be (unless I opened a thread just for it, which I think is not warranted).

[jds]

I'll take this oportunity to ask a rather complex question, so, please, bear with me:

For Extended Partition Boot Records (EBRs), is the Partition-Type Descriptor (entry offset 4) of the Second Partition Table Entry (when it exists) always "05", or should it follow the actual Partition-Type Descriptor (be it "05" or "0F") of the Extended Partiton it exists in?

In other words, if I have a "0F" Extended Partition, there will be a daisy-chain of EBRs inside it, with two entries per boot record (except for the last one): the descriptor for the first entry corresponds to the type of the Logical Partition that follows, but the second entry (which is just a pointer to the next EBR) should be of type "0F" or "05"?

It seems to me they're always "05", regardless... Or is it irrelevant whether it's "0F" or "05", in this case?

I know this question is not quite on-topic, but I figured this was the nearer to on-topic it'll ever be (unless I opened a thread just for it, which I think is not warranted).

The MS tools (ie. FDISK) always use the standard "05" extended partition ID following (chained from) the MBR "0F" LBA extended partition ID.

Joe.

[jds]

His work fixes a definite problem with MS-DOS 7.XX / MSW 9X, whereby drives are enumerated incorrectly by IO.SYS.

I agree, but it may apply only to people also using Windows NT who need to use non-standard Type '05' Partitions.

No, as I don't use NT. The problems of LBA partitions being addressed as CHS and phantom enumeration occurred for me with W9X (98SE, to be precise).

I'm sure that any attempt in MSW to write to the phantom drive letters so produced, will corrupt the drive.

Possibly, although writing is more likely to fail before damage occurs. Formatting or using SCANDISK is another story.

I'm not sure of your assertion that the "Patch at +206C now causes all Logical Partitions to be set for LBA access. This would be a problem in any machine that does not support LBA".

I set it up and tested it before I posted.

Wouldn't IO.SYS detect machines without LBA support and consequently use CHS addressing?

No. It ignores any LBA Partitions. It may even abort scanning, although I have not comfirmed this.

I see what you mean. On such systems, all extended partitions might be ignored due to the patch. I'll try this out when time permits.

If there is a genuine problem, simply don't apply these patches to such machines, since these are no use to them anyway.

Then the Patch would only be of value to users of unmodified Windows NT as others have no need for Type '05' Partitions.

I use a variety of machines with partitions (primary and logical) over the 1024 cylinder boundary (FAT16 and FAT32). With the two selected of Stevens patches, I can do so safely (in DOS or MSW), regardless how they've been defined.

No. There is an unrelated bug in IO.SYS that he didn't Patch. I have not evaluated the impact of the third Patch (+3A01).

Joe.

[rloew]

His work fixes a definite problem with MS-DOS 7.XX / MSW 9X, whereby drives are enumerated incorrectly by IO.SYS.

I agree, but it may apply only to people also using Windows NT who need to use non-standard Type '05' Partitions.

No, as I don't use NT. The problems of LBA partitions being addressed as CHS and phantom enumeration occurred for me with W9X (98SE, to be precise).

Windows NT users are the only ones that NEED to use Non-Standard Type '05' Partitions. Apparently a lot of people HAVE Non-Standard Type '05' Partitions.

Apparently some Partitioning tools are creating them. Some Versions of Ranish Partition Manager do this, as noted by Dencorso above. I downloaded and ran Ranish Partition Manager Version 2.4.0, but it created Type '0F' Partitions by default.

[dencorso]

RLoew, do test RPM 2.44, too, please. Despite the caveats, it's the most used version, in my experience, and it's perfectly reliable, AFAIK. Older versions than 2.40 still float around the net, and they do use "05" as the default.

One scenario is the following, for any version, if I'm not mistaken: it will create nonstandard extended partitions if you ask it to create an extended partition early in the disk (it'll default to "05"), and then define a logical partition, quick format it, and select it again, press <insert> to get the format menu and select FAT LBA... It'll create the "0C" logical partittion but won't correct the type of the container extended partition to "0F". I know this is somewhat contrived, however, but...

There are additional issues with using LBA Partitions within Type '05' Partitions but they are also bypassed by the +206C Patch.

Also, could you please elaborate on the above quote, please?

The MS tools (ie. FDISK) always use the standard "05" extended partition ID following (chained from) the MBR "0F" LBA extended partition ID.

Thanks, Joe! So it actually is as I thought it was.

[rloew]

RLoew, do test RPM 2.44, too, please. Despite the caveats, it's the most used version, in my experience, and it's perfectly reliable, AFAIK. Older versions than 2.40 still float around the net, and they do use "05" as the default.

Version 2.37 only seemed to recognize 8GB and was totally confused with most of my Partitions.

Version 2.44 did not work for me. It created a MBR but none of the Partitions I created were placed in the MBR.

Version 2.40 insisted on starting Partitions on Head 81. This is totally incompatable with CHS Logical Partitions.

One scenario is the following, for any version, if I'm not mistaken: it will create nonstandard extended partitions if you ask it to create an extended partition early in the disk (it'll default to "05"), and then define a logical partition, quick format it, and select it again, press <insert> to get the format menu and select FAT LBA... It'll create the "0C" logical partittion but won't correct the type of the container extended partition to "0F". I know this is somewhat contrived, however, but...

You can always reset the Partition Type from '0F' to '05'. It doesn't do any checks. The default behavior is OK.

There are additional issues with using LBA Partitions within Type '05' Partitions but they are also bypassed by the +206C Patch.

Also, could you please elaborate on the above quote, please?

Logical Partitions starting above 8GB are not accessible within a Type '05' Partition.

[dencorso]

Version 2.37 only seemed to recognize 8GB and was totally confused with most of my Partitions.

Version 2.44 did not work for me. It created a MBR but none of the Partitions I created were placed in the MBR.

Version 2.40 insisted on starting Partitions on Head 81. This is totally incompatable with CHS Logical Partitions.

Did you use a SATA HDD? I've seen the problem you mention for 2.44 only with SATA HDDs...

And yes, 2.40 likes Head 81, as it helps use the drive more fully and works OK with LBA. But you can always reset by hand any of the values it offers by any other you want. RPM is powerful and very dangerous for the casual user...

Logical Partitions starting above 8GB are not accessible within a Type '05' Partition.

Thanks!

[rloew]

Did you use a SATA HDD? I've seen the problem you mention for 2.44 only with SATA HDDs...

Yes. I'm not sure why this would happen as I was in DOS and the INT 13 Interface should hide the type of drive.

And yes, 2.40 likes Head 81, as it helps use the drive more fully and works OK with LBA. But you can always reset by hand any of the values it offers by any other you want. RPM is powerful and very dangerous for the casual user...

How does using Head 81 more fully utilize the Hard Drive?

BIOSes typically only report an integral number of Cylinders when reporting the Drive size.

Edited May 10, 2010 by rloew

[dencorso]

How does using Head 81 more fully utilize the Hard Drive?

BIOSes typically only report an integral number of Cylinders when reporting the Drive size.

Yes, but not an exact multiple of #cyls * 255 * 63... and this results in just 80 heads on the last cylinder, for all HDDs I've ever seen. Let me give an example:

Here's a 80 GB Seagate Barracuda 7200.7 ST380011A, partitioned by the book, with the last head-challenged cylinder also turned to an unconventional partition (from which it was possible to boot DOS 7.10!). It has 78150586 KiB of total usable space ( = 74.53 GiB):

Ranish Partition Manager       Version 2.43 (beta) by Muthu   Apr 09, 2002

HD 2 (129) 76,319M [  9,729 cyls x 255 heads x 63 sects = 156,301,488 sects ]

                   File                Starting         Ending      Partition
   # Type Row   System Type         Cyl Head Sect    Cyl Head Sect  Size [KB]

   0  MBR     Master Boot Record      0    0    1      0    0    1          0 
   1          Unused                  0    0    2      0    0   63         31 
   2 *Pri  1  FAT-32 (0B)             0    1    1    882  254   63  7,092,666 
   3  Pri  3  Extended LBA (0F)     883    0    1  9,728  254   63 71,055,495 
   4  +-Log   Win FAT-32 LBA (0C)   883    1    1  2,139  254   63 10,096,821 
   5  +-Ext   Auxiliary (05)      2,140    0    1  3,384  254   63 10,000,462 
   6  +-Log   Win FAT-32 LBA (0C) 2,140    1    1  3,384  254   63 10,000,431 
   7  +-Ext   Auxiliary (05)      3,385    0    1  5,873  254   63 19,992,892 
   8  +-Log   Win FAT-32 LBA (0C) 3,385    1    1  5,873  254   63 19,992,861 
   9  +-Ext   Auxiliary (05)      5,874    0    1  9,728  254   63 30,965,287 
  10  +-Log   Win FAT-32 LBA (0C) 5,874    1    1  9,728  254   63 30,965,256 
  11  Pri  2  FAT-16 LBA (0E)     9,729    0    1  9,729   80   63      2,551 

And here's the same 80 GB Seagate Barracuda 7200.7 ST380011A, partitioned by using head 81... It has 78150617 KiB of total usable space (still = 74.53 GiB ...), that means 31 KiB recovered from space otherwise used in partitioning structures (I know it's not a lot, but, not so long ago, it meant 22 "1.44 MB" floppies! ):

Ranish Partition Manager       Version 2.43 (beta) by Muthu   Apr 09, 2002

HD 2 (129) 76,319M [  9,729 cyls x 255 heads x 63 sects = 156,301,488 sects ]

                   File               Starting         Ending      Partition
  # Type Row   System Type         Cyl Head Sect    Cyl Head Sect  Size [KB]

   0  MBR    Master Boot Record      0    0    1      0    0    1          0 
   1         Unused                  0    0    2      0    0   63         31 
   2 *Pri  1 Win FAT-32 LBA (0C)     0    1    1  1,256   80   63 10,091,340 
   3  Pri  2 Extended LBA (0F)   1,256   81    1  9,729   80   63 68,059,372 
   4  +-Log  Win FAT-32 LBA (0C) 1,256   82    1  3,757   80   63 20,089,251 
   5  +-Ext  Auxiliary (05)      3,757   81    1  5,013   80   63 10,088,820 
   6  +-Log  Win FAT-32 LBA (0C) 3,757   82    1  5,013   80   63 10,088,788 
   7  +-Ext  Auxiliary (05)      5,013   81    1  9,729   80   63 37,881,270 
   8  +-Log  Win FAT-32 LBA (0C) 5,013   82    1  9,729   80   63 37,881,238 

The above are the output of RPM's <part -d 2 -p> command, somewhat edited for more clarity (and the colors, the result of the code tag's fancy). Of course, since it's really a full LBA setup, this geometry (retranslated from LBA to CHS by RPM) is ficticious in any case, corresponding to the real internal geometry of the HDD in no obvious way, but it illustrates nicely my point. All this was done with RPM 2.43, which is not very popular, but is my favorite (and, if I'm not mistaken, also has the same problems as 2.44 with its settings sticking in SATA).

[rloew]

How does using Head 81 more fully utilize the Hard Drive?

BIOSes typically only report an integral number of Cylinders when reporting the Drive size.

Yes, but not an exact multiple of #cyls * 255 * 63... and this results in just 80 heads on the last cylinder, for all HDDs I've ever seen.

I confirmed your statement on the Drive I used. I have seen at least one BIOS that always truncates the size to a Cylinder Boundary.

I tried another Hard Drive. Ranish then decided it liked Head 47 Sector 30.

Here's a 80 GB Seagate Barracuda 7200.7 ST380011A, partitioned by the book, with the last head-challenged cylinder also turned to an unconventional partition (from which it was possible to boot DOS 7.10!). It has 78150586 KiB of total usable space ( = 74.53 GiB):

To be CHS compatable, all of the Type '05' Partitions in the Chain must start on a Cylinder Boundary. The Logical Partition typically starts one track later. I don't think this is a requirement. The Partition need not end on any particular boundary, so having all Partitions on Cylinder Boundaries will not waste space, if the last one takes the partial Cylinder. The first one MUST end on a Cylinder Boundary, otherwise the BIOS may miscompute the Geometry of the Drive. Using Ranish, I got my BIOS to think there were only 240 Heads per Cylinder. Phelum's Patch will not bypass Geometry discrpancies on CHS Primary Partitions.

I tried to install Windows NT 4 on my Test Computer. It crashed during loading. I looked at some of the files for Partition checking.

So far I found only one piece of code. It did recognize Type '0F' Partitions but did not recognize '0B', '0C', or '0E'.

[jds]

I'm sure that any attempt in MSW to write to the phantom drive letters so produced, will corrupt the drive.

Possibly, although writing is more likely to fail before damage occurs. Formatting or using SCANDISK is another story.

I'm not sure of your assertion that the "Patch at +206C now causes all Logical Partitions to be set for LBA access. This would be a problem in any machine that does not support LBA".

I set it up and tested it before I posted.

Wouldn't IO.SYS detect machines without LBA support and consequently use CHS addressing?

No. It ignores any LBA Partitions. It may even abort scanning, although I have not comfirmed this.

I see what you mean. On such systems, all extended partitions might be ignored due to the patch. I'll try this out when time permits.

Joe.

Well, I've done some testing on an old 386SX (no LBA / Extended Int $13 support), and I can confirm that indeed the +206C patch has the effect of ignoring any extended/logical partitions. For this test, I simply created a boot floppy using the patched 'IO.SYS'. So, such old systems do not suffer from the 'IO.SYS' LBA bugs, do not benefit from the patches, and cannot see any extended/logical partitions if the +206C patch in particular is applied.

Consequently, I have updated my 'IO.SYS' patch package to detect when it is being applied to such old systems lacking Extended Int $13 support, in which case it simply reports this fact and exits. I have also included a limited patch that only addresses the phantom drive enumeration bug, in case that's of any interest, as this can be used with systems old and new. Perhaps useful for use on boot floppies? If you've got a new system, you really need the full patch, if you've got an old (ancient) system, then none of these LBA bugs are relevant anyway.

Again, see http://jds.com-t.com/general.html if you'd like to download.

(Edit : Defunct URL. See below.)

BTW, I also tested for the reported "can't access partitions that start beyond the 7.8G boundary" bug with the (fully) patched 'IO.SYS' and didn't encounter any problems. Although I didn't repeat this test with the unpatched 'IO.SYS' (since that would have been courting disaster), this suggests that the +206C patch may also fix this problem.

Joe.

Edited September 22, 2011 by jds

[jds]

Just an update ... the 'com-t.com' host seems to have become defunct.

So, the IO.SYS patch can now be downloaded here :

http://jds.atbhost.net/general.html

http://www.geocities.ws/j_ds_au/general.html

Joe.

[Czerno]

Hi! Although this thread is old, the findings in it cannot imho be considered 100% accurate or definitive.

My experience FWIW is reported here, trying to make it short but as accurate & to the point as possible

I have Win 98 SE w/ 80 GBytes hard disk (PATA) and a reasonably modern BIOS (i.e. LBA32 capable). I'm using the MS IO.SYS version from 2001 that is mentioned in the thread.

Have many partitions, including 3 primaries (FAT12, FAT16 and FAT32, the last one has the "boot" flag - usually- and is the "system" partition for Windows 98 - and Win 2k Pro as well. This part crosses the so-called 8 Gig limit.

Then an extended-LBA (type 0), containing a second FAT 32, followed by a Linux Ext2, then Linux Swap, followed by several of each Ext2, NTFS and DOS FAT partitions - not counting Ranish part manager 2.43 at the very end of the disk which is not covered by the extended partitions chain.

I used to experience the phantom drive symptom in MS-DOS and Wiindows 98.

What I found over years of experimenting (on and off...) in relation with this thread's subj

To start I always make sure the last partition in the chain of extended ones is a FAT-type known to MS-DOS.

This in itself however has never prevented the bug.

The only method which cures (not just works around) the IO.SYS volume enumeration bug for this system is making sure all extended "container" partitions (except for the most exterior one) are type 05 (NOT type 0F ! )

- Changing the type of any interior extended to 05 from 0Fh immediately and repeatably restores the bug.

- Steven "Phelum" 's patches have had NO effect whatsoever on this bug within my system (neither the three of them together, nor the "206C" patch in isolation).

I'm not saying Steven's patch(es) are useless for everybody, just that they're not needed or helpful on my system

Sincerely hoping this feedback can help anybody who wished to have another look at this bug (I haven't even tried to disassemble IO.SYS). I would appreciate R.Loew's comment in particular, whether he thinks I am secure from the unspecified (other?) bug(s) he is aware of (and considering I have no use for LBA 48).

As a final note, other DOSes (i.e. non-MS) which are FAT32 and LBA-aware have no problems enumerating and mounting all my FAT partitions, whatever combination of 05/0F types internal extended partitions are given. Nor have Linux or even MS Windows 2000 SP4 any problems! However for MS-DOS (and Windows 9x) compatibility my advice based on this experience is to have all extended containers typed 05 except of course the priamry extended LBA which must be type 0Fh

Edited September 21, 2011 by Czerno

[rloew]

Sincerely hoping this feedback can help anybody who wished to have another look at this bug (I haven't even tried to disassemble IO.SYS). I would appreciate R.Loew's comment in particular, whether he thinks I am secure from the unspecified (other?) bug(s) he is aware of (and considering I have no use for LBA 48).

I have found and Patched a number of bugs including those observed by Phellum and the Last Extended Partition (on the Last Drive) issue you observed above. I think you will be OK with what you have.

As a final note, other DOSes (i.e. non-MS) which are FAT32 and LBA-aware have no problems enumerating and mounting all my FAT partitions, whatever combination of 05/0F types internal extended partitions are given. Nor have Linux or even MS Windows 2000 SP4 any problems! However for MS-DOS (and Windows 9x) compatibility my advice based on this experience is to have all extended containers typed 05 except of course the priamry extended LBA which must be type 0Fh

I never looked into this issue until just now. Using Type 0FH Extended Chain Records doesn't produce Ghost Partitions. These are the actual Partition(s), just with unexpected Letter(s).

MS DOS 7 does not appear to follow the Type 0FH Chain Records, so the Partitions are not mounted in DOS. Windows 9x rescans and does mount them. If you have multiple Primary Partitions or more than one Hard Drive, Windows is likely to mount them in a different order than DOS should have.