rloew

Awwwwwww RATS! and I would have gotten away with it too... if it hadn't been for those pesky KIDS! Apparently there is a tradeoff. Use my Patch and have unlimited Seek capability over the range 0 to 4GiB-2, and break some programs. Or use COPY2GB which is more limited but has less impact on compatability. I do not know of any Programs that would do multi GigaByte relative Seeks with large files so there may not be a need for the improved functionality. I will keep the Patch on my website and add an advisory. I have no idea why my Patch caused the observed crash with VideoReDo. I would have expected some sort of FIle error or corruption instead. There probably are other bugs in VideoReDO or MSVCR80.

Well rloew, I have bad news and good news... The bad news is... my internet connection stinks... The good news is... I had no crash when starting VideoReDo Plus . Keep up the great work! Correction: Bad news and bad news. Apparently VideoReDo is not compatable with the function extensions I added. The experimental file I posted has my code in it but disabled the function extensions. VideoReDo probably attempts to do a relative seek to a point before the beginning of a file, expecting it to fail. With my extensions, a 32-Bit Seek before the start of a file is now treated as a Seek to a point nearly 4GiB after and does not fail. Unfortunately there is no way to distinguish between these situations without limiting the ability to handle files up to 4GiB. I don't know if it is VideoReDo or MSVCR80 that needs fixing. I don't have either one. I noticed that a number of people downloaded the Experimental File I posted. It was intended as a test only and the Patch is non-functional. Only the current file on my Website is functional.

DOS itself is not the problem. It is more than capable of handling Drives and Partitions of 2TiB (more with Patches). CHKDSK doesn't do much and SCANDISK begins to choke on very large Partitions. I haven't experimented much with DOS USB Drivers, but I suspect there may be issues with them.

Sorry rloew... I'm still experiencing the same crash . See the attached file for a basic picture of the crash message and a Dr. Watson crash log... Try this experimental file.

Hi rloew... I think there may be a bug in your KERNEL32 2GiB Bug Fix Patch... Yesterday, I updated the old COPY2GB KERNEL32.DLL to your version... When I went to use VideoReDo Plus (a video editing app), it kept crashing with an error involving msvcr80.dll... Using Dependency Walker, it showed that msvcr80.dll is linked to KERNEL32.DLL... I switched back to the old COPY2GB KERNEL32.DLL and after a reboot, VideoReDo Plus ran fine... Just thought I'd let you know... Try Downloading it and testing it again. I have updated it. If it still doesn't work please post some more details on the errors.

I don't know what applications use the other Seek Modes other than some of mine but there probably are some. The underlying DLL is the same. The Author of COPY2GB bumped up the Version Number.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files. Also how do FCIV.EXE and CRC.EXE behave, both on 98SE and pure DOS, with your problem file? I have released my KERNEL32 2GiB Bug Fix Patch. This Patch supercedes the COPY2GB Patch as it supports all three Seek Modes unlike COPY2GB that supports only Seek from Beginning of File. It is available free from my website rloew1.no-ip.com in the Prerelease and Beta Section.

Thanks Joe, it's all strange though as since I corrected the time while in BIOS it has been not too bad and currently is about 8 seconds behind, whereas at one time it appeared to be about 5 minutes behind all of a sudden. Setting the time in Windows will set the RTC. System time can lag significantly behind the RTC if the system becomes too busy to update. I have seen this happen often with some programs.

I wonder if deleting the cross linked files would help or make the system cleaner especially as you say they may likely be corrupted? Sometimes one of them would be intact. If you delete them you will lose both. You do need to review all of them to replace or remove the damaged files.

The first 16MB of Physical Memory appears to be critical to some functions such as Ethernet. Some DMA Controllers are also limited to this range. Having a large Registry depletes this resource and causes problems. The Shared Arena is a 1GiB range of Virtual RAM. There is only one Shared Arena but it can be scattered all over Physical RAM. The limitations of SCANDISKW and DEFRAG are due their own coding and possible limitations on 16-Bit Code support in Windows.

The first 16MB of Physical RAM is not the "System Arena" but it appears to be needed during Boot. Try using the /M option with the Free Demo of my RAM Limitation Patch to see if it solves the problem. Do the following steps: 1. Install the Demo using "PATCHM /M". 2. Shutdown immediately. 3. Turn off computer. 4. Install NIC Card. 5. Boot. 6. If Windows boots, do Steps 10 and 11, then do steps 7 and 8. 7. Turn off Computer. 8. Remove NIC Card. 9. Boot. 10. Uninstall RAM Limitation Patch Demo using "PATCHM" 11. Shutdown immediately. the problem is solved

Hmmm ... In that case, I think the following is also required reading : Joe. The amount of available "Shared Arena" does not appear to be an issue. There is normally more than enough space to handle larger Partitions than these Programs can handle. The Registry Size issue is unrelated to this issue and appears to be related to usage of the first 16MiB of Physical RAM.

Using the procedure described above, you could have added the RAM BEFORE running PATCHMEM if you wanted to. The instructions for WININIT were for installing a new Windows 9x System, not Patching an existing one. Your swap file settings should not be a problem. Only if you had more than 3GiB of accessible RAM could there be any possible issues. With the extra RAM, your swap file will get a lot less use.

I don't routinely defragment but the Windows ME Defrag can handle it.

Which version? I don't remember which Version but I believe it was the last version that said it supported Windows 98. This wouldn't concern me much. I am limiting all my FAT32 partitions to 192 GB, which is the maximimum size for a FAT32 partition allowed by PowerQuest PartitionMagic 8, they must have had their reasons. Any FAT32 partition above 192GB =196.600.1MB I consider as potentially risky, some software might not be able to handle it correctly. Your experience with Diskeeper just confirms this personal 192GB rule.By limiting myself to 192GB FAT32 partitions, I also limit the size of HDDs to a max of 1TB, to avoid drive letter overflow. I usually partition my external 1TB HDDs into 4 logical FAT32 partitions of 192GB and the remainder as a logical NTFS partition, with PowerQuest PartitionMagic 8 under Win98SE. The 192GB limit may be related to Windows XP. I have not seen anything in Windows 9x that would limit the use of Partitions to less than 1TiB other than FDISKs 512GiB total Drive limit. I routinely use a 476GB Partition without having any problems. Above 1TiB it gets more complicated, but Windows 98 can support up to 16TiB.

I would not recommend Diskeeper. I tested the Windows 9x compatable Diskeeper a couple of years ago. It totally corrupts partitions larger than approx 200GB. I contacted the Company and they said that as far as they are concerned it doesn't support Windows 9x.

I was able to create 36MB Floppy Images (1024 Cylinders, 2 Heads, 36 Sectors per track) and make Bootable CDs/DVDs. I created a Hard Disk Partition of this size, filled it with the files I wanted and then Imaged it. I wrote my own CD/DVD Burner that allowed me to specify 2.88MB Floppy Emulation instead of Hard Disk Emulation.

I have now tested both the Seagate Go-Flex 3TB USB Drive and the Internal Western Digital 3TB Drive. I have developed a complete Package (TBPLUS) to support these Hard Drives, and larger. It is now available on my website. This should help keep Windows 98 alive for another 15-20 Years.

1. Yes it can be installed from DOS. 2. If you run from DOS, it doesn't matter if the RAM has already been added or not. You can even install Windows 9x into a Computer with 2GB of RAM by installing the Patch from DOS. 3. My Patch sets the Absolute Maximum File Cache to 512MiB by default. There is an Option to set to something else, /C:256 will set it to your chosen MaxFileCache setting. Your VCACHE tweaks are lower and will override mine. If you are happy with them you can keep them.

I am not aware of any CPU or Chipset issues. There are no special requirements for using the Patch. Large Registry and Gigabit Ethernet issues may become worse with more RAM. There is an option in the Patch (/M) that eliminates these issues. The alternative methods do not deal with these issues.

Option 2 limits the RAM available to Windowx 98 to 1.2GB. The two methods accomplish the same thing in two different ways.

The 1TiB limit per Partition is due to a bug in the Windows FileSystem Driver so using SCSI will not help. I wrote a Patch to fix it.

Without specific RAID or AHCI Drivers for your SATA Controller, you will need my SATA Patch for the SATA Drives to work in 32-Bit Mode. This would also provide support for the SATA DVD-ROM.

There is NOT only this thread in the world (or even on MSFN) . If there is even a small possibility that an external USB disk will EVER be connected or booted to a system/OS that doesn't have larger than 128 Gb partition support you risk that you will get a correupted partition. ALWAYS have a first partition (Primary, Active) below the LBA28 limit, to play safe. jaclaz The USB protocol is not affected by the 128GiB issue. So connecting an external USB Drive to an older BIOS will not cause corruption. More likely the older BIOS would not recognize USB Drives at all. Only if the Drive has the potential to be used without it's associated USB enclosure would there be any risk of corruption. Using an arbitrary USB enclosure is another issue as some older Enclosures DID have a 128GiB limit. Using one of these could cause corruption regardless of how new the BIOS is or Windows Drivers used.

Why are you using Compatability Mode? Are you using SATA Drives?