Jump to content

Patched IO.SYS for 9x/ME


jaclaz

Recommended Posts

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.

I think so, too, as I have been using this sytem to multiboot many OSes for many months without problems, including running several OSes concurrently in virtual machines using the raw disk. Your confirmation that I should be safe is appreciated none the less :=)

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.

I assure you I have one phantom drive - I can actually see the erroneous parameters in a debugger, fortunately DOS refuses to read/write from the phantom - and MS DOS stopping enumerating partitions, as soon as the extended partition which contains my first Linux extended is changed to type 0F instead of 05. It may be dependent on the particular layout of the disk in unspecified ways which you did not reproduce but it is completely reproducible.(Untested Hypothesis : might it be related to my primary type 0C FAT32 partition overlapping cylinder 1023 ?)

Sure Windows 9x later does attempt its own reenumeration but 1: it does not remove the fake or phantom entry from the volumes table, and 2. it still fails to find all the partitions afterwards, though it does add one of the primaries that DOS missed. Bizarre, but that is Micros?ft !

Anyway the bug is totally absent IFF interior extended partitions are all marked type 05. Hence my above suggestion, which I am reiterating.

Link to comment
Share on other sites


- 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).

One of Steven's patches introduces a bug, so all three patches is not the way to go.

As for the "206C" patch in isolation, I think that's the one (if used in isolation) that's applicable for Non-Int-13x (Non-LBA) BIOSes only. (Edit: Actually, it's the patch at 3A01 that may be applied in isolation with such old BIOSes, so I'm not sure why you chose to apply the "206C" patch in isolation.) You should be applying two patches (206C and 3A01), per my version of Steven's patches.

Joe.

Edited by jds
Link to comment
Share on other sites

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.

I think so, too, as I have been using this sytem to multiboot many OSes for many months without problems, including running several OSes concurrently in virtual machines using the raw disk. Your confirmation that I should be safe is appreciated none the less :=)

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.

I assure you I have one phantom drive - I can actually see the erroneous parameters in a debugger, fortunately DOS refuses to read/write from the phantom - and MS DOS stopping enumerating partitions, as soon as the extended partition which contains my first Linux extended is changed to type 0F instead of 05. It may be dependent on the particular layout of the disk in unspecified ways which you did not reproduce but it is completely reproducible.(Untested Hypothesis : might it be related to my primary type 0C FAT32 partition overlapping cylinder 1023 ?)

Sure Windows 9x later does attempt its own reenumeration but 1: it does not remove the fake or phantom entry from the volumes table, and 2. it still fails to find all the partitions afterwards, though it does add one of the primaries that DOS missed. Bizarre, but that is Micros?ft !

Anyway the bug is totally absent IFF interior extended partitions are all marked type 05. Hence my above suggestion, which I am reiterating.

Not so bizarre.

Since you were modifying an interior Extended Partition, not the last one, I didn't consider the last Extended Partition issue we already know about. My IO.SYS has been patched to fix this. Since DOS stopped enumerating Partitions after the modified Linux Partition, it became the last Extended Partition that DOS saw. This triggered the bug. The Phantom Partition you see is the Second Primary Partition misplaced. Windows correctly mounted it as you saw. The first and third Primaries were not affected.

I agree that the Extended Partition Chains must be Type 5, at least until I can Patch it.

I don't think crossing Cylinder 1023 should make any difference.

I posted a Patch for the Last Extended Partition bug on this forum in the Thread "Phantom Drive Letter" last year.

Edited by rloew
Link to comment
Share on other sites

Not so bizarre.

Since you were modifying an interior Extended Partition, not the last one, I didn't consider the last Extended Partition issue we already know about. My IO.SYS has been patched to fix this. Since DOS stopped enumerating Partitions after the modified Linux Partition, it became the last Extended Partition that DOS saw. This triggered the bug. The Phantom Partition you see is the Second Primary Partition misplaced. Windows correctly mounted it as you saw. The first and third Primaries were not affected.

I was not all that clear while posting around 3 am : that Phantom thing appeared, even though the last partition that IO.SYS found in the extended 0F chain would be a recognisable FAT type, one or more levels "below" the Ext2 and Linux swap. Oh, well, I'm not so sure any more if I've hit a "new" bug or a "new case" of an old bug, or nothing new at all. Sorry ! It doesn't matter if everybody observes :

I agree that the Extended Partition Chains must be Type 5, at least until I can Patch it.

I posted a Patch for the Last Extended Partition bug on this forum in the Thread "Phantom Drive Letter" last year.

Will heed... Many thanks

(edit): Ooooh! With your Patch applied I am unable to bring back Phantoms, however hard I try :-)

Very nice, indeed it should be obligatory!

Edited by Czerno
Link to comment
Share on other sites

Not so bizarre.

Since you were modifying an interior Extended Partition, not the last one, I didn't consider the last Extended Partition issue we already know about. My IO.SYS has been patched to fix this. Since DOS stopped enumerating Partitions after the modified Linux Partition, it became the last Extended Partition that DOS saw. This triggered the bug. The Phantom Partition you see is the Second Primary Partition misplaced. Windows correctly mounted it as you saw. The first and third Primaries were not affected.

I was not all that clear while posting around 3 am : that Phantom thing appeared, even though the last partition that IO.SYS found in the extended 0F chain would be a recognisable FAT type, one or more levels "below" the Ext2 and Linux swap. Oh, well, I'm not so sure any more if I've hit a "new" bug or a "new case" of an old bug, or nothing new at all. Sorry ! It doesn't matter if everybody observes :

I already knew that. Even though the actual last Partition was a FAT Partition, DOS stopped enumerating after the Linux Partition, so it became the "Last" Partition as far as the "Phantom Bug" was concerned. The "Phantom Bug" is an old issue, but the Type 0FH Enumeration Problem was new, at least to me.

Update:

I have determined that a Type 0FH Extended Chain Record is treated as an Initial Extended Partition Record rather than a Chained Partition. They have different formats and the Initial Extended Partition Record resets the Start of Extended Partitions value used to define the Partition Offsets. Since the MBR documentation does not distinguish between the Formats of these two types of Extended Partitions, and all other OSes treat them the same, I have designed a Patch for IO.SYS to treat the Type 5 and 0FH Extended Chain Partitions the same.

Edited by rloew
Link to comment
Share on other sites

Mr Loew,

Would it be safe to combine your IO.SYS patches with Steven's patches (or more specifically, the two patches at 206C and 3A01)?

BTW, for anyone interested, the best description I've found on hard drive partitioning is : http://technet.microsoft.com/en-us/library/cc977219.aspx (note, references to MS-DOS appear to be v6 or earlier).

Joe.

Link to comment
Share on other sites

Mr Loew,

Would it be safe to combine your IO.SYS patches with Steven's patches (or more specifically, the two patches at 206C and 3A01)?

BTW, for anyone interested, the best description I've found on hard drive partitioning is : http://technet.microsoft.com/en-us/library/cc977219.aspx (note, references to MS-DOS appear to be v6 or earlier).

Joe.

I believe the Patched IO.SYS that I posted last year can be combined with his Patches. A more robust Patch I made later, made his Patches unnecessary.

Link to comment
Share on other sites

I believe the Patched IO.SYS that I posted last year can be combined with his Patches. A more robust Patch I made later, made his Patches unnecessary.

Thanks, Mr Loew.

The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version?

Joe.

Link to comment
Share on other sites

I believe the Patched IO.SYS that I posted last year can be combined with his Patches. A more robust Patch I made later, made his Patches unnecessary.

Thanks, Mr Loew.

The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version?

Joe.

The original one. I have only posted one version.

Link to comment
Share on other sites

I believe the Patched IO.SYS that I posted last year can be combined with his Patches.

I confirm it. I'm using RLoew's original patch, combined with the pair of Steven's patches Joe recommends. Since the latter are both one byte patches, what I did was to apply RLoew's patcher to the KB311561 IO.SYS, and then add the 0x206C and the 0x3A01 patches by hand. It works great. :yes:

Link to comment
Share on other sites

I believe the Patched IO.SYS that I posted last year can be combined with his Patches.

I confirm it. I'm using RLoew's original patch, combined with the pair of Steven's patches Joe recommends. Since the latter are both one byte patches, what I did was to apply RLoew's patcher to the KB311561 IO.SYS, and then add the 0x206C and the 0x3A01 patches by hand. It works great. :yes:

Can you share the file with the combined patches.

Link to comment
Share on other sites

I have determined that a Type 0FH Extended Chain Record is treated as an Initial Extended Partition Record rather than a Chained Partition. They have different formats and the Initial Extended Partition Record resets the Start of Extended Partitions value used to define the Partition Offsets. Since the MBR documentation does not distinguish between the Formats of these two types of Extended Partitions, and all other OSes treat them the same, I have designed a Patch for IO.SYS to treat the Type 5 and 0FH Extended Chain Partitions the same.

Can you clarify what you mean by "different formats"? Do you mean the interpretation of the Relative Sector field?

BTW, I do recall reading some MS documentation stating that the partition ID for chained EBRs should always be 05, not 0F, the latter to be used only in the MBR, to point to the first EBR (if using LBA addressing, of course).

I believe the Patched IO.SYS that I posted last year can be combined with his Patches. A more robust Patch I made later, made his Patches unnecessary.

Thanks, Mr Loew.

The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version?

Joe.

The original one. I have only posted one version.

Would you mind if I made available, a "combined" patch incorporating this (with appropriate attribution, of course) and my version of Steven's patch?

Can you share the file with the combined patches.

You can simply run my version of Steven's patch, then Mr Loew's. Alternatively, you can do the reverse. Same result.

Joe.

Edited by jds
Link to comment
Share on other sites

I have determined that a Type 0FH Extended Chain Record is treated as an Initial Extended Partition Record rather than a Chained Partition. They have different formats and the Initial Extended Partition Record resets the Start of Extended Partitions value used to define the Partition Offsets. Since the MBR documentation does not distinguish between the Formats of these two types of Extended Partitions, and all other OSes treat them the same, I have designed a Patch for IO.SYS to treat the Type 5 and 0FH Extended Chain Partitions the same.

Can you clarify what you mean by "different formats"? Do you mean the interpretation of the Relative Sector field?

Correct. The Relative Sector Field of a Chained Record is supposed to contain the offset relative to the First Extended Partition. DOS expects the Absolute Starting Sector in all Type 0FH Records when it should only for the first. In addition, it resets it's copy of the First Extended Partitions Starting Sector, so any later Type 5 Partition would have to be offset from the last Type 0FH Partition rather than the first.

BTW, I do recall reading some MS documentation stating that the partition ID for chained EBRs should always be 05, not 0F, the latter to be used only in the MBR, to point to the first EBR (if using LBA addressing, of course).

I didn't find it, but it is obvious that Microsoft assumed it when they wrote the DOS code.

I believe the Patched IO.SYS that I posted last year can be combined with his Patches. A more robust Patch I made later, made his Patches unnecessary.

Thanks, Mr Loew.

The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version?

Joe.

The original one. I have only posted one version.

Would you mind if I made available, a "combined" patch incorporating this (with appropriate attribution, of course) and my version of Steven's patch?

Go ahead.

Can you share the file with the combined patches.

You can simply run my version of Steven's patch, then Mr Loew's. Alternatively, you can do the reverse. Same result.

Joe.

The Patches are non-overlapping so there are no issues.

Link to comment
Share on other sites

  • 2 weeks later...

I believe the Patched IO.SYS that I posted last year can be combined with his Patches. A more robust Patch I made later, made his Patches unnecessary.

Thanks, Mr Loew.

The one that Den reminded us of here, dated 2010/06/29, is that the original version, or the "more robust" version?

Joe.

The original one. I have only posted one version.

Would you mind if I made available, a "combined" patch incorporating this (with appropriate attribution, of course) and my version of Steven's patch?

Go ahead.

Thank you, Mr Loew.

(I'll put this together and make it available when time permits.)

Joe.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...