rloew

I assume drive 3 is an USB Drive. Do you use any Diskeeper products?

VGA Mode will probably work, but I can't guarantee it. The 2GiB of RAM will definitely crash Windows 98 unless you Patch it or limit it.

I'm having this overflow problem with di1000dd.sys as well, and I'm using a Western Digital 750Gb external USB HDD. I've run out of options so I would like to try your suggestion above, but how do I actually modify the file? Thanks in advance, if you can point the way....... You need to use a HEX Editor to modify the file. DEBUG can be used if you don't have any other.

I think that may be because Microsoft intended 4.00.971 to replace 4.00.950 and 4.00.1112 to replace 4.00.1111 not 4.00.950 even if it works. I have seen the same pattern between Windows 98, 98SE and ME where updates of the older Windows have lower Version numbers than updates that came out earlier for the newer Windows. I have seen the exact same file released with two different Version numbers for different Windows.

Ok, so I could re-name it, but there must be some part of the install process or script that is expecting that exact name - no? Something must be expecting the file name "fetndis02.inf" to exist. Where can I change that to "fetndis2.inf", as well as renaming the file to that name? And what is meant by this: "c:\wininst0.400\fetndis02.inf=PRECOPY1.CAB" The error message indicates that as the "destination file". Why is there a reference or inclusion of "=PRECOPY1.CAB" as part of the destination filespec? I assume something you added references the file. Search the files that have been added or changed. Apparently one of the LAYOUT (LAYOUT*.INF) files specifies that a copy of fetndis02.inf is located in the PRECOPY1.CAB. The "=PRECOPY1.CAB" appended to the Error Message indicates an alternative source. Unless PRECOPY1.CAB has been rebuilt, it is not goint to be there.

The first pass of the installer does not support Long File names. All files copied in the first pass must have Short Names and be renamed in the Second or later passes.

Well I'll be flippered! I did something right for a change! Glad ya found your bug! Congrats on the fix!(this post allows reminder of your "fix" module as well, so not a "wasted post"...) Thank you very much for the DIAMOND.EXE Link. I was able to rework my Slipstream Scripts to use it to support Windows 95 for LoneCrusader. I had my 2GB Patch installed when I was testing DIAMOND Batch Scripts, and even the Example Scripts failed. Although it seemed unlikely, the 2GB Patch was the only one that affected File functions, so I removed it and DIAMOND worked. A FILEMON log nailed it.

Run the 48BITLBA.EXE Program from a DOS Box under Windows to verify the Drivers.

The 16KB Cluster limit of RPM is strictly due to choices made by the Author. Any formatter that support 32KB Clusters should work. My RFORMAT Program uses Microsoft's guideline by default but can be manually set from 512 Bytes to 8MiB per Cluster. Setting Cluster size on FAT-16 can be useful. I was able to use a 4GB CF Card in an old Camera by setting 64KiB Clusters.

Your motherboard BIOS may not support more than 128GiB (137GB). Run the 48BITLBA.EXE Program in my High Capacity Disk Patch Demo in DOS, not a DOS Box, to find out.

So, please, do test the new free DR FORMAT v1.0 (see quote above for download link) and report. If it works OK, we now have a DOS only way of doing it. I don't know about some of the other DOSes mentioned, but MS-DOS and Windows 9x definitely will not support 128KB Clusters without my Patches. Windows XP will not support 256 Sector Clusters unless Patched.

Only the same caveat I added before. But now there are no known problem Programs.

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... While testing the DIAMOND.EXE that Submix8c found for LoneCrusader, I discovered that Microsoft routinely does a relative Seek to -1 when creating Temporaries. As I said before, Negative Seeks cannot be distinguished from Seeks below 4GiB without compromising 4GiB Support. But in this case, 4GiB-1 is the only position that is prohibited regardless, so I added a check to fail this particular Seek. This unbroke DIAMOND and probably a number of other Programs that use this method to Check Temporaries and other Files. Anyone using my KERNEL32 Patch should redownload it and replace the file. @whatever420 Please redownload and try VIDEOREDO again.

Didn't have ASPIEHCI.SYS last night. Now I do. Replace Bytes F7 F1 at offset A950 with EB 06 in ASPIEHCI.SYS Again, great work Mr Loew! I hope I'm not being a nuisance here, but whilst you're playing with this stuff, is there any chance you could also look at Adaptec's AFDISK.EXE, which can be found in any of the archives 'aspidos.zip', 'dosdrvr.zip', or 'scsilite.zip' (or the EXE versions of same)? If you try to define/change partitions with this, using the Panasonic USBASPI.SYS driver (don't know if it's OK with ASPIEHCI.SYS and the like, since only the Panasonic driver works for me), it crashes (divide by zero error, if I recall). I suspect AFDISK may be relying on some ASPI parameter or function that USBASPI doesn't provide, but that is pure speculation. Joe. I couldn't find AFDISK.EXE but I observed the same Problem with my RFDISK.EXE Partitioner. DI1000DD.SYS does not properly report an error when attempting to access the Drive after the Drive(s) it mounted. RFDISK, and probably AFDISK, did a divide by zero when DI1000DD.SYS reported a Zero Sector per Track Drive instead of an Invalid Drive. I have fixed RFDISK to handle this better. Patch DI1000DD.SYS by replacing 76 with 72 at offset CE6. This will eliminate the spurious Drive reports.

Didn't have ASPIEHCI.SYS last night. Now I do. Replace Bytes F7 F1 at offset A950 with EB 06 in ASPIEHCI.SYS

I have isolated code that wil cause a Divide Overflow above 507GiB in DI1000DD.SYS. To prevent the Overflow replace the Bytes F7 F1 at Offset 2896 with EB 06. This Mod will cause INT 13 AH=8 to report 1024 Cylinders regardless of the true size.

I believe the divide overflow is due to the Software trying to compute the number of logical Cylinders and getting a number over 65535. This will occur around 507GiB. I have seen this happen with some SATA Drivers. It would probably not be too hard to fix.

WARNING - AHCI Mode SATA is not compatable with Windows 9X. AHCI Mode requires Protected Mode access to Memory. Windows 9X will crash with an IOS Error if any FAT Partitions are present before any Protected Mode Driver can be loaded. If the BIOS is set to AHCI Mode or any Card is present that Boots in AHCI mode, any Drive connected to it must not contain any Partitions recognized by DOS or Windows. Only NTFS, Linux and other Partitions can be present. Compatability mode will not work either. DOS EMM386 will crash even if no Partitions are present on a Drive connected to an AHCI enabled Controller. The Highpoint Rocket 620 HBA (SATA 3) PCI-E Card packaged with the Western Digital 3GB Hard Drive is an AHCI only Card using the Marvell 9125 Controller. It cannot be switched out of AHCI mode so it cannot be used. It also does not support the full 3GB. The JMicron PCI-E AHCI Cards, I have tested, boot in Native Mode and can be used with my Patch. None of the PCI Cards I have tested support AHCI so this is not an issue.

You can't make such a statement without explicitly stating the drive interface being used. Windows 98 clearly is compatible with very large drives and a very large number of clusters - way beyond 4.17 million (the number often quoted incorrectly by Microsoft as the largest number of clusters that DOS scandisk can handle). Windows 98's native 32-bit protected mode driver (ESDI_506.PDR) limits windows 98 to 137 gb IDE drives. If you remove that file and force Windows 98 to use DOS-mode drive access, then the limit will probably be much larger (1 or 2 tb). This is assuming we are talking about a motherboard made during or after 2002 that is LBA-48 compliant. With regard to external USB drives - I'm not sure if ESDI_506.PDR plays any role accessing those drives. Intel's Application Accelerator driver package contains a replacement for ESDI_506.PDR for some chipsets. I wouldn't exactly call that a "3'rd party" solution. I said "Default" which means Motherboard IDE and ESDI_506.PDR enabled. USB Drives do not use ESDI_506.PDR. Support depends upon the USB Controller in the Enclosure. Some older ones did not support more than 137GB. Intel is a third party. That is also wrong in some or in most cases. Motherboards made between 2003 and 2006 that have integrated SATA-I controllers will have Windows-98 drivers for those controllers, meaning that your SATA patch will not be needed. True. But this is 2010 so these Motherboards are going to be getting harder and harder to find. Newer ones do not provide Drivers.

No. The 32-Bit limit is absolute, not Partition size related. The Interrupt 13 Code must support 48 Bits as well as the Windows Driver, and the DOS and Windows Filesystems have to be Patched also.

You can try stripping the SUBSYS specification off of one entry in the INF file and see if it works. Otherwise you will need my SATA Patch.

By Default Windows 98SE supports up to 137GB (128GiB) IDE Drives. If you are using 500GB successfully then you are using either a third party driver or have a Patched Driver. If you want to use SATA Drives without an Adapter you will need my SATA Patch. There is a bug in Windows 98SE that can cause problems if you create a single Partition larger than 1TiB. If you use two or more Partitions then you can use up to 2TiB. Beyond 2TiB you will need my TBPLUS Package and may need another SATA to IDE adapter. Be aware that some Motherboards may choke on drives larger than 548GB.

I have been able to use other Silicon Image SATA cards with my SATA Patch. I don't see why that one would not work unless it is AHCI only. I can't guarantee that the activity LED would work.

I don't think Version bumping is a good idea. Only a single entity should do Version bumping, namely Microsoft, otherwise Version collisions can occur. Also any revisions lead to additional Version numbers being required. Changing QFE to RRL makes more sense and identifies the source of the Update. I will also add a Copyright String with my Patch Version in it as well.

I don't think there are any problems with having an Uncompressed VMM32.VXD file other than taking up more space and possibly a longer boot time. My RAM Patch can be installed but needs to be manually configured.