Jump to content

Patched IO.SYS for 9x/ME


jaclaz

Recommended Posts

The patched io.sys (w98.zip) downloaded from this is the one from kb 311561.

The official microsoft patch gives two files (winboot.98g, winboot.98s), which are identical to the bit. So the above changes will work on both 98 and 98se. It works also without alteration on Tihiy's reduced version of IO.SYS (eg ionologo.sys).

This patch of io.sys is in different locations to the w3xstart patch.

Edited by os2fan2
Link to comment
Share on other sites

  • 2 months later...

The patched io.sys (w98.zip) downloaded from this is the one from kb 311561.

The official microsoft patch gives two files (winboot.98g, winboot.98s), which are identical to the bit. So the above changes will work on both 98 and 98se.

That's true. On the other hand, the patched io.sys (wme.zip) for Win ME is based on the original retail Win ME io.sys (110080 bytes 06/08/2000 05:00 PM) because they have the same size and just 82 differences between them (hence it's a patch), and not on the Win ME version of KB 311561 (110080 bytes 11/29/2001 09:29 AM), which has also the same size but 105963 differences from the file provided by Steven (hence they are completely different files, one cannot be a patch of the other). And no patched version of winboot.ebd (the bootable diskette version of io.sys, necessary to be able to use the "Real DOS-Mode Patch for Win ME" on it and make Win ME more bearable :angel ). Edited by dencorso
Link to comment
Share on other sites

  • 6 months later...
The patched io.sys (w98.zip) downloaded from this is the one from kb 311561.

It might be identical but I doubt it. KB 311561 talks about hard error detection whereas my change fixes a software error that doubled the start key of a partition.

The patched IO.SYS relies totally on the LBA keys in the partition records even for CHS partitions. Perhaps this break from the specifications caused the drive letter problem reported above.

I can't really add any mention for Win98FE in my page because I've never tested it.

Cheers,

Edited by phelum
Link to comment
Share on other sites

The patched io.sys (w98.zip) downloaded from this is the one from kb 311561.
It might be identical but I doubt it.
Welcome to MSFN, phelum!

You misunderstood the sense of os2fan2's statement: She meant that the patched file you offer is based in the IO.SYS file from KB311561 (or, in other words, that you patched the KB311561 Win 98SE IO.SYS). This was of importance for her point because, inside the hotfix KB311561, there are two versions of IO.SYS, one meant to be used in 98SE, and the other for 98FE, but both those two files are in fact identical. Hence she concluded that your patched file must work OK also with Win 98FE.

Edited by dencorso
Link to comment
Share on other sites

You misunderstood the sense of os2fan2's statement: She meant that the patched file you offer is based in the IO.SYS file from KB311561 (or, in other words, that you patched the KB311561 Win 98SE IO.SYS).

Thanks for the update and the welcome. Yes, misunderstanding is one of my acquired skills.

I'm glad that the patch has helped someone. I can't see why the key calcs were wrong in the first place but I did worry that the patch might break some existing disk setups. I'm still using this IO.SYS in multi-boot (DOS, W98, W2k) systems that I support.

Cheers,

Link to comment
Share on other sites

  • 11 months later...

BTW, if you get phantom drive enumeration or other LBA problems

in W9X, you might want to try my revised patch for V7.10 'IO.SYS'

(based on original patch by Steven Saunderson), available at :

http://jds.com-t.com/general.html

@jds: You say in your read.me:

However, one of Steven's changes were causing me other LBA problems, and since I didn't agree with it, I reversed it.

I've determined that the change you reverted is (quoting Steven Saunderson's original w98bug.txt):

* Offset 2072 was 04 now 00 (erroneous set of LBA flag for next par[tition]).

Would you please elaborate on what problems did that particular change have, and why do you consider it a misfix?

Sorry again for the delayed reply.

Anyway, the misfix is as follows ... When an LBA extended partition is defined, all logical partitions within in should/must use LBA addressing, even if they're not explicitly defined as LBA types. With the above-mentioned change, IO.SYS will look only at the type ID of the logical partition itself, ignoring the type ID (and hence addressing mode) of the extended partition that contains it. If the logical partition in question is not wholely within the 7.8G CHS limit, disaster (due to wrap-around)!

Joe.

We were talking about other matters, elsewhere, and this interesting development took place:

jds found a problem with phelum's patch and reversed one of the code modifications, to catter for the case of CHS logical partitions inside LBA extended partitions. His patcher for the Win 98 FE or SE versions of IO.SYS from KB311561 is findable at his site.

Link to comment
Share on other sites

We were talking about other matters, elsewhere, and this interesting development took place:

jds found a problem with phelum's patch and reversed one of the code modifications, to catter for the case of CHS logical partitions inside LBA extended partitions. His patcher for the Win 98 FE or SE versions of IO.SYS from KB311561 is findable at his site.

I can see that my patch has had an unwanted side-effect. I didn't hit a problem because my extended partitions are all type 05 whether CHS or LBA. I need this type because NT4 doesn't recognise type 0F. I put a dummy partition at cylinder 1023 so systems that use CHS don't see anything after. NT systems always use LBA so they continue down the chain and find subsequent partitions. Win98SE does find FAT32 partitons after cylinder 1023.

Thanks for the update to my patch and the interest in it.

Cheers,

Steven Saunderson

Edited by phelum
Link to comment
Share on other sites

We were talking about other matters, elsewhere, and this interesting development took place:

jds found a problem with phelum's patch and reversed one of the code modifications, to catter for the case of CHS logical partitions inside LBA extended partitions. His patcher for the Win 98 FE or SE versions of IO.SYS from KB311561 is findable at his site.

I can see that my patch has had an unwanted side-effect. I didn't hit a problem because my extended partitions are all type 05 whether CHS or LBA. I need this type because NT4 doesn't recognise type 0F. I put a dummy partition at cylinder 1023 so systems that use CHS don't see anything after. NT systems always use LBA so they continue down the chain and find subsequent partitions. Win98SE does find FAT32 partitons after cylinder 1023.

Thanks for the update to my patch and the interest in it.

Cheers,

Steven Saunderson

Can you tell me under what conditions does the Partition Start Sector become doubled without your Patch? I have observed a bug that causes spurious Partition Start Sector settings, but they are not doubled. I have developed a fix that corrects the problem. I recently ran some tests and found that your Patch did not fix the Bug I identified.

Link to comment
Share on other sites

Can you tell me under what conditions does the Partition Start Sector become doubled without your Patch? I have observed a bug that causes spurious Partition Start Sector settings, but they are not doubled. I have developed a fix that corrects the problem. I recently ran some tests and found that your Patch did not fix the Bug I identified.

My hard drive contained an extended partition (type 05) that was about 30GB. This partition contained CHS accessible volumes before cylinder 1023 and others (NTFS and FAT32) from cylinder 1024 onwards. There was a FAT32 volume before cylinder 1023 and I would get a phantom drive in Win98 if I set this volume's type to 0C.

A simple test to show the problem is to create an extended partition (type 05) on a drive and add a type 0C (FAT32 LBA) volume. IO.SYS will double the start key whereas the 32-bit disk code in Win98 gets it right.

I realise that type 05 partitions shouldn't exceed cylinder 1023 but I had to use 05 not 0F for NT4 compatibility. Also, all LBA keys must be correct. I didn't see this as a problem because NT always uses LBA keys and my partitioning program ensured they were correct. But, this might cause problems in setups that rely/use CHS only.

The recent comment that an LBA extended partition should contain only LBA volumes might explain why IO.SYS works the way it does.

Cheers,

Steven Saunderson

Link to comment
Share on other sites

Can you tell me under what conditions does the Partition Start Sector become doubled without your Patch? I have observed a bug that causes spurious Partition Start Sector settings, but they are not doubled. I have developed a fix that corrects the problem. I recently ran some tests and found that your Patch did not fix the Bug I identified.

My hard drive contained an extended partition (type 05) that was about 30GB. This partition contained CHS accessible volumes before cylinder 1023 and others (NTFS and FAT32) from cylinder 1024 onwards. There was a FAT32 volume before cylinder 1023 and I would get a phantom drive in Win98 if I set this volume's type to 0C.

A simple test to show the problem is to create an extended partition (type 05) on a drive and add a type 0C (FAT32 LBA) volume. IO.SYS will double the start key whereas the 32-bit disk code in Win98 gets it right.

I realise that type 05 partitions shouldn't exceed cylinder 1023 but I had to use 05 not 0F for NT4 compatibility. Also, all LBA keys must be correct. I didn't see this as a problem because NT always uses LBA keys and my partitioning program ensured they were correct. But, this might cause problems in setups that rely/use CHS only.

The recent comment that an LBA extended partition should contain only LBA volumes might explain why IO.SYS works the way it does.

Cheers,

Steven Saunderson

Microsoft considers LBA the preferred access mode. Since a type '0F' Partition requires use of LBA, it is safe to assume that any Logical Partition contained within it can be accessed by LBA, regardless if LBA is specified. FDISK makes this assumption, so your Patch at +2072 breaks this. JDS removed this part of your Patch.

Without the +2072 Patch, your 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.

Without the +206C Patch, the value of using a Type '05' Partition with LBA Logical Partitions is severely diminshed. Besides needing your +3A01 Patch, you will be unable to define Partitions that start above 8GB. Type '05' Partitions were meant to be CHS only and there may ber even more issues.

Basically what you have done is make a workaround for a problem that is basically a Windows NT problem not a DOS problem.

Windows 98 has different code so it handles these nonstandard partitions differently, so you get the duplicate mounts.

I think you would get much better results if you fix the problem in Windows NT instead. Since it can handle LBA, the modification should be relatively simple.

The problem I found does not require CHS Partitions or non-standard Partitions, only the presence of NON-DOS Partitions, such as NTFS.

Link to comment
Share on other sites

Basically what you have done is make a workaround for a problem that is basically a Windows NT problem not a DOS problem.

Windows 98 has different code so it handles these nonstandard partitions differently, so you get the duplicate mounts.

I think you would get much better results if you fix the problem in Windows NT instead. Since it can handle LBA, the modification should be relatively simple.

Your suggestion of patching NT4 so it recognises type 0F partitions sounds good but I don't know where I'd start. The good thing about my workaround is that I can have a type 05 partition and that CHS only systems (e.g. DOS) can access volumes before cylinder 1024. NT4 and above and the 32-bit disk code in Win9x can access the entire partition. So, there seems to be good support for type 05 partitions that exceed cylinder 1024. The only problem with this non-standard and yet very accessible arrangement is the Win9x IO.SYS.

I don't think it's fair to talk about an NT problem. NT has always used LBA addressing even for type 05 partitions. Perhaps type 0F wasn't defined back in those days. I think the NT developers did well sticking to type 05 for backwards compatibility and letting it exceed 8.4GB so we could use the new larger drives.

Cheers,

Edited by phelum
Link to comment
Share on other sites

Can you tell me under what conditions does the Partition Start Sector become doubled without your Patch? I have observed a bug that causes spurious Partition Start Sector settings, but they are not doubled. I have developed a fix that corrects the problem. I recently ran some tests and found that your Patch did not fix the Bug I identified.

My hard drive contained an extended partition (type 05) that was about 30GB. This partition contained CHS accessible volumes before cylinder 1023 and others (NTFS and FAT32) from cylinder 1024 onwards. There was a FAT32 volume before cylinder 1023 and I would get a phantom drive in Win98 if I set this volume's type to 0C.

A simple test to show the problem is to create an extended partition (type 05) on a drive and add a type 0C (FAT32 LBA) volume. IO.SYS will double the start key whereas the 32-bit disk code in Win98 gets it right.

I realise that type 05 partitions shouldn't exceed cylinder 1023 but I had to use 05 not 0F for NT4 compatibility. Also, all LBA keys must be correct. I didn't see this as a problem because NT always uses LBA keys and my partitioning program ensured they were correct. But, this might cause problems in setups that rely/use CHS only.

The recent comment that an LBA extended partition should contain only LBA volumes might explain why IO.SYS works the way it does.

Cheers,

Steven Saunderson

Microsoft considers LBA the preferred access mode. Since a type '0F' Partition requires use of LBA, it is safe to assume that any Logical Partition contained within it can be accessed by LBA, regardless if LBA is specified. FDISK makes this assumption, so your Patch at +2072 breaks this. JDS removed this part of your Patch.

Without the +2072 Patch, your 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.

Without the +206C Patch, the value of using a Type '05' Partition with LBA Logical Partitions is severely diminshed. Besides needing your +3A01 Patch, you will be unable to define Partitions that start above 8GB. Type '05' Partitions were meant to be CHS only and there may ber even more issues.

Basically what you have done is make a workaround for a problem that is basically a Windows NT problem not a DOS problem.

Windows 98 has different code so it handles these nonstandard partitions differently, so you get the duplicate mounts.

I think you would get much better results if you fix the problem in Windows NT instead. Since it can handle LBA, the modification should be relatively simple.

The problem I found does not require CHS Partitions or non-standard Partitions, only the presence of NON-DOS Partitions, such as NTFS.

I think you are being grossly unfair to Steven.

His work fixes a definite problem with MS-DOS 7.XX / MSW 9X, whereby drives are enumerated incorrectly by IO.SYS. I'm sure that any attempt in MSW to write to the phantom drive letters so produced, will corrupt the drive.

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". Wouldn't IO.SYS detect machines without LBA support and consequently use CHS addressing? If there is a genuine problem, simply don't apply these patches to such machines, since these are no use to them anyway.

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.

Joe.

Edited by jds
Link to comment
Share on other sites

Your suggestion of patching NT4 so it recognises type 0F partitions sounds good but I don't know where I'd start. The good thing about my workaround is that I can have a type 05 partition and that CHS only systems (e.g. DOS) can access volumes before cylinder 1024. NT4 and above and the 32-bit disk code in Win9x can access the entire partition. So, there seems to be good support for type 05 partitions that exceed cylinder 1024. The only problem with this non-standard and yet very accessible arrangement is the Win9x IO.SYS.

I don't have a Windows NT setup to test. You obviously have some reverse-engineering experience. I can ptobably give you some suggestions on what to look for. I added Type '0F' support to DOS 6.2 years ago.

The problem with your Patch is that it breaks CHS compatability. With a CHS only BIOS, you cannot access any Extended Partitions whatsoever. With a LBA supported BIOS, Type '05' Partitions are not needed, except to support unpatched Windows NT.

If you can find the doubling bug or any other using a CHS Partition in a Type '05' Wrapper and/or a Partition in a Type '0F' Wrapper, I would be very interested.

I don't think it's fair to talk about an NT problem. NT has always used LBA addressing even for type 05 partitions. Perhaps type 0F wasn't defined back in those days. I think the NT developers did well sticking to type 05 for backwards compatibility and letting it exceed 8.4GB so we could use the new larger drives.

I do think it is a NT issue. I didn't assign 'blame' for it. I didn't blame Microsoft for not putting 48-Bit LBA support into Windows 98, only the stupid way they handled it. I don't know if Type '0F' Partitions existed when NT was developed, but I am sure it was before the last service pack.

I think you are being grossly unfair to Steven.

I was not criticizing his work, just pointing out some issues.

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.

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.

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

Link to comment
Share on other sites

The default for the Ranish Partition Manager is to create 05 extended partitions. I always correct that to 0F by hand, after partitioning a new hdd or pendrive (if and when I create muti-partitioned pendrives for some given test purpose)... I remember, from the times before I adopted Steven's patched IO.SYS having seen the enumeration problem... but its a dim memory and at the time I didn't take notes, so I cannot report apropriately on what was it I saw... Then I changed the identifier to 0F, and that was it.

So, by now, we can reckon two bugs in IO.SYS: the one found by Steven and the one found by RLoew...

Link to comment
Share on other sites

The default for the Ranish Partition Manager is to create 05 extended partitions. I always correct that to 0F by hand, after partitioning a new hdd or pendrive (if and when I create muti-partitioned pendrives for some given test purpose)... I remember, from the times before I adopted Steven's patched IO.SYS having seen the enumeration problem... but its a dim memory and at the time I didn't take notes, so I cannot report apropriately on what was it I saw... Then I changed the identifier to 0F, and that was it.

So, by now, we can reckon two bugs in IO.SYS: the one found by Steven and the one found by RLoew...

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

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