rloew

Without my Patch, Windows 98 cannot recognize more than approx. 1.15GB of RAM. If it recognizes more than 1.15GB of RAM it will crash. Setting MaxPhysPage limits what Windows recognizes. You will need my Patch if you want to be able to actually use more than 1.15GB of RAM.

I have not seen a problem with doubling of CD or DVD Drives. I doubt that IO.SYS is responsible. There may be a problem with your Hard Disk Drivers. Try reinstalling them.

For completeness sake, is it possible to get these bugfixes applied to the Windows 95 IO.SYS from Q185301 KB Article HotFix? (I believe that's the last official version for 95, but I'm not at my usual "project machine" so I can't check right now.) It appears to work for both of the Hotfix files as well.

Windows 9x supports more than 512MB or RAM. It can support 768MB without modification. Minor modifications are needed to use 1GB. More substantial modifications are needed to run if more than 1GB of RAM is present. To fully use more than 1GB of RAM requires my Patch.

I have updated my PATCHPAR Program to Patch the Unpacked Windows ME IO.SYS as well. You will need to get the Unpacker from my Website. Let me know if it solves your problem.

I'll fix it. What do you guys think about all modded and patched files having the time and date backdated to July 11, 2006, 12:00:00 AM since this was the day support ended for Win98SE. All modded and patched files comes from here or MDGx site. We will all be using the same version just different time stamps. Then we all would know the exact origins of those files. Just a thought Probably OK for the official versions, but doubtful for non-MS modified files. There are multiple versions of some files after that date such as my IO.SYS Patches. The final release date for your Package would probably be a better choice.

Gmail drops received E-Mails containing certain attachments, such as ZIPs, without warning to either sender or recipient. I have encountered this problem on a few E-Mail services when I deliver my Patches. When sending Patches to new Customers, I follow up with an E-Mail, with NO Attachment, requesting delivery verification. You can fool Gmail by renaming files to Name.JPG and having the recipient rename them back to the original Extension before using.

Please rephrase entry as: Added IO.SYS rloew Full Patch for Partition Offset Bugs

The Patch is complete. You do not need any other Patch. It is recommended that you use the Updated IO.SYS from 311561USA8.EXE as your starting point. It is not truly cumulative as I created a single Patch that solves the issues dealt with by all of the prior patches, so the earlier ones are not present. It is the same as the Hex Editing instructions for the 311561USA8.EXE version only. It will insert slightly different Patches into the original IO.SYS and possibly localized versions as it uses an adaptive algorithm. My previously posted Patch, not the Hex Edit, is obsolete and should not be used.

On Windows 9X: 1. The User API supports 64 Bit File Offsets. 2. The User Mode Interface (KERNEL32.DLL) only supports 32 Bit File Offsets. 3. The Kernel Mode Interface ((IOS) only supports 32 Bit File Offsets. 4. Some FileSystems, such as NTFS, support 64 Bit File Offsets. Because of parts 2 and 3, it is impossible to access more than 4GB of a File through the normal pathway regardless of FileSystem or Network capability. Even my FILE64 Large File Emulator, which is an User Mode Overlay, cannot bridge this gap to an actual >4GB file on a NTFS FileSystem.

The 4KiB Physical Sector Drives are perfectly useable with Windows 9X as long as they are properly Partitioned and Formatted. I have written utilities that can do this.

This is an unrelated problem. Try disabling any DOS CD/DVD Drivers in your CONFIG.SYS File.

The EBD Folder Version is the Updated IO.SYS. Use that one with my Patch. Then use the resulting File to replace the C:\IO.SYS File. @Prozactive: I have never used the 311561USA8.EXE Patch on any system. I just used the File inside, so the registry is not the issue.

I have written a Patching Program that will add the Partition Offset Bug Fix to IO.SYS. This program will work with the original IO.SYS as well as the recommended Updated IO.SYS Version. This version should work with any of the Localized Versions as well. Use the following commands to perform the Patch. C: CD \ REN IO.SYS IO.OLD PATCHPAR IO.OLD IO.SYS

Then I would like to add that it does not need to be the 311561USA8.EXE hotfix, because RLoew's patch also introduces the CORRECT changes to the Io.sys file installed by the 311561POL8.EXE hotfix and probably also by all the other updates for Windows 98SE still available for download at: http://support.microsoft.com/kb/311561 In general, I think the Microsoft wouldn't have released 27 different language versions of this update without a reason (even more so, because, for example, Polish version doesn't have messages translated to Polish language at all). So I recommend preinstalling the 311561 hotfix in the correct language version, and then using the RLoew's patch on the Io.sys file installed this way. The Pad area I used is just above a text block. If the text for a particular language is longer than the English Version than the Patch will fail. Some languages will work but others need a different Patch. When Patching using my Patch, verify that the OLD data shown matches what is in the File. Dencorso's Version of my Patch is locked to the USA Version or exact equivalents. DOS 7 and it's associated Boot Sectors only require that the first four Sectors of IO.SYS be contiguous. It is no longer necessary that IO.SYS start on Cluster 2 or that it be the first entry in the Root Directory.

The KB311561 Update was specified in my Instructions. The original would not have matched the "old" data shown in the second block. A slightly different Patch is needed for the original Version of IO.SYS.

Using a RAMDisk as a Swap file will accomplish nothing unless you have more RAM than Windows recognizes. You would be better off disabling Swap and not using the RAMDisk..

It addresses Partition offset bugs. My Patched KERNEL32.DLL addresses File offsets. "Unique patch script" is not very descriptive and won't reflect the change to IO.SYS after the next update replaces the change notice at the beginning of the Post. I suggest: KERNEL32.DLL 4.10.2225 rloew 2GB Patch Added Patched CDFS.VXD rloew 2GB Patch Added Patched IO.SYS rloew full Partition Patch

BDIFF is a utility I wrote. The syntax is as follows: <- Old Data -> New Data Address offset in File Data in Hex Data in Ascii PROBLEMCHYLD asked for a final version of IO.SYS, presumably for U98SESP3. This was the quickest way to post it. It would not be in U98SESP3, at least not yet. @PROBLEMCHYLD: If you use this new Version,. please change your comment on IO.SYS to reflect the change so there is no confusion.

Forgive me if I sound dense, but...It appears that the IOSYS Zip file first needs applied and then subsequently the above manual patch to correct all known bugs? (sans the Saunderson patches, i.e. ONLY your patches are necessary?) EDIT!!! Just read your above "edit". - Just the above patch covers all "known bugs". Correct? This Patch is "complete". Do not use Saunderson's Patch OR my earlier Patch with it. I wouldn't say "all known bugs" as there are bugs unrelated to the issues addressed here.

I haven't written a Patch Program for it. You need to use a Hex Editor to Patch the File. I previously posted a less comprehensive Patch Program on this forum. Most of the technical discussion on this subject was about Saunderson's earlier Patch. Both Patches were needed to cover all issues. @submix8c: My earlier or current Patch should handle the problem caused by your NTFS Partition.

The following is a BDIFF dump of my full Patch to the KB311561 (2001/12/01) Version of IO.SYS for the various Partition handling bugs I have found: <-000016C0 B3 01 *..* ->000016C0 00 3E *.>* <-000054C2 4D 50 41 44 4D 50 41 44 4D 50 41 44 4D 50 41 44 *MPADMPADMPADMPAD* <-000054D2 4D 50 41 44 4D 50 *MPADMP* ->000054C2 1E 56 57 51 06 1F 8D B5 96 00 B9 4B 00 F3 A5 59 *.VWQ.......K...Y* ->000054D2 5F 5E 1F E9 9D C3 *_^....* This Patch is complete. Unlike the previously posted Patch, Saunderson's Patches are not needed. This Patch does not include Saunderson's controversial change to LBA handling that has caused problems and is not in jds's Version.

Even the original FDISK should work if you create Partitions as a Percentage rather than MegaBytes and say yes to large disk support.

Not so queer. I have a motherboard that does that. It shouldn't be an issue unless the available space becomes smaller than the image being loaded. I would gladly "downgrade" the QUECON queerness condition from 2 to 3 or even 4, provided you: tell us which motherboard it is what are the actual contents of the HPA the motherboard creates (OP reported a FAT12 filesystem - maybe something connected to an emnergency-emergency boot to upgrade or reset the BIOS?) you could provide some more info/insight on the matter (I simply cannot believe that you actually saw this happening and avoided to investigate the behaviour right down to the single byte or bit ) jaclaz It was several years ago so I don't remember the details of the original discovery. I ran some tests and discovered that the Gigabyte MA78GM Motherboard reserves an 0x841 Sector HPA on all Motherboard connected Hard Drives. It contains a BIOS Image in the first Megabyte and a small amount of data in the remaining 32.5K I removed the HPAs but the Motherboard did not restore them. I suspect that it only puts in the HPAs if the Drive is blank or unpartitioned as the OP has been instructed to do.

Not so queer. I have a motherboard that does that. It shouldn't be an issue unless the available space becomes smaller than the image being loaded.