[rloew]

dencorso, on 10 May 2010 - 04:34 PM, said:

rloew, on 10 May 2010 - 01:20 PM, said:

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.

Quote

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]

jds, on 09 May 2010 - 08:42 AM, said:

rloew said:

Quote

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.

Quote

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.

Quote

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.

This post has been edited by jds: 22 September 2011 - 03:04 AM

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

This post has been edited by Czerno: 21 September 2011 - 08:06 AM

[rloew]

Czerno, on 21 September 2011 - 05:51 AM, said:

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.

Quote

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.

[Czerno]

rloew, on 21 September 2011 - 03:37 PM, said:

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 :=)

Quote

Quote

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.

[jds]

Czerno, on 21 September 2011 - 05:51 AM, said:

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

This post has been edited by jds: 21 September 2011 - 09:35 PM

[rloew]

Czerno, on 21 September 2011 - 07:29 PM, said:

rloew, on 21 September 2011 - 03:37 PM, said:

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 :=)

Quote

Quote

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.

This post has been edited by rloew: 21 September 2011 - 08:48 PM

[dencorso]

rloew, on 21 September 2011 - 08:33 PM, said:

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

Here's a direct download link to IOSYS.ZIP, from RLoew's original post in the Phantom Drive Letter thread.

[Czerno]

rloew, on 21 September 2011 - 08:33 PM, said:

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 :

Quote

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

Quote

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!

This post has been edited by Czerno: 22 September 2011 - 04:37 AM

[rloew]

Czerno, on 22 September 2011 - 03:35 AM, said:

rloew, on 21 September 2011 - 08:33 PM, said:

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.

This post has been edited by rloew: 22 September 2011 - 03:57 PM

[jds]

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.micro...y/cc977219.aspx (note, references to MS-DOS appear to be v6 or earlier).

Joe.

[rloew]

jds, on 22 September 2011 - 09:16 PM, said:

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.micro...y/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.

[jds]

rloew, on 22 September 2011 - 09:48 PM, said:

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.

[rloew]

jds, on 22 September 2011 - 10:45 PM, said:

rloew, on 22 September 2011 - 09:48 PM, said:

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.

[dencorso]

rloew, on 22 September 2011 - 09:48 PM, said:

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.

[PROBLEMCHYLD]

dencorso, on 22 September 2011 - 11:53 PM, said:

rloew, on 22 September 2011 - 09:48 PM, said:

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.

Can you share the file with the combined patches.

[jds]

rloew, on 22 September 2011 - 10:05 AM, said:

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

rloew, on 22 September 2011 - 11:11 PM, said:

jds, on 22 September 2011 - 10:45 PM, said:

rloew, on 22 September 2011 - 09:48 PM, said:

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?

PROBLEMCHYLD, on 23 September 2011 - 12:56 AM, said:

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.

This post has been edited by jds: 23 September 2011 - 02:24 AM

[rloew]

jds, on 23 September 2011 - 02:22 AM, said:

rloew, on 22 September 2011 - 10:05 AM, said:

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.

Quote

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.

Quote

rloew, on 22 September 2011 - 11:11 PM, said:

jds, on 22 September 2011 - 10:45 PM, said:

rloew, on 22 September 2011 - 09:48 PM, said:

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.

Quote

PROBLEMCHYLD, on 23 September 2011 - 12:56 AM, said:

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.

[jds]

rloew, on 23 September 2011 - 11:43 AM, said:

Quote

rloew, on 22 September 2011 - 11:11 PM, said:

jds, on 22 September 2011 - 10:45 PM, said:

rloew, on 22 September 2011 - 09:48 PM, said:

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.