rloew

Oops! I think somehow I had missed your post #19, so I wasn't aware of it. In any case, to avoid confusion, please do give this new product a distinctive name, like FAT Size Limitation Surmounter, or something like it. Your freeware patch fixes a known bug in the filesystem implementation, while this new product you're talking about overcomes what is a filesystem limitation by design, so they're really very different things, if I got it right. However, even if it works well, this is bound to create a situation which is beyond the standard, and I confess I'm wary of such extensions... not to mention a special matching DOS driver would be needed, to allow correct access to those huge files from plain DOS, too. In my original Post, I was describing what it did. I have not yet chosen a Name for it as I have not released it yet. It is not, and never will be, truly compatable with the existing standard. There will always be special considerations when using it. For this reason, I have coded the Hook to only function if the Files are contained within a Path containing a specific Keyword. The current implementation would not be compatable with DOS. So far, I have tested it with Azureus for Upload/Download and Gomplayer for Rendering.

I have never used KernelEx, or examined it's interface, so I don't know if it is compatable. It is not freeware. A Demo Version, for testing, is possible. I am still working on it, but I have already Downloaded a Blu-Ray File larger than 4GiB and skipped around within it with Gomplayer. @M()zart There is nothing to Download as I haven't finished testing. @Dencorso This is a new Product. You were referring to my older Patch for KERNEL32.DLL.

I have written a KERNEL32.DLL Hook that allows what appears to be one large File to be stored in multiple Files. This allows Applications to work with files that appear to be larger than 4GiB. You can Download, UNRAR, etc. a 6GB MKV File as the OP wanted to do and then watch it with a Player. The Applications, of course, must support large Files.

To further this discussion, have you tested any Blu-Ray drives? Since the subject was broached back in my Bootable DVD thread, I have considered experimenting with Blu-Ray drives and Windows 98. I first searched for IDE Blu-Ray drives, and some do exist, but they seem to be extremely rare. So, I decided that I would probably have to use a SATA drive with a SATA to IDE adapter or the SATA patch, depending on the system. I recently purchased one of these drives, but I have not had any time to devote to experimenting or my projects lately. I have a SATA Blu-Ray Writer in my Main Computer. It is connected to SATA Port 5 so it is interfaced through the Second Legacy Port (170H) not the Native Mode SATA Controller. It behaves like any CD or DVD Drive. I haven't tested the Blu-Ray functions yet.

Windows 9x supports SATA CD/DVD drives in the same way it supports SATA Hard Drives. My Patch is needed under the same circumstances. Add-on Card Firmware and/or Third Party Software may or may not support CD/DVD Drives. I just tested my JMicron PCI-E SATA 2 Card with my Patch and it works.

When it comes to PCI SATA cards, I think they will always be SATA-1, and (for the moment) if you stick with a 2-port SATA card for a win-98 system then it will work fine with the drivers that are publicly available. (my 4-port PCI sata controller does work under win-98, but only in PIO mode - not DMA/UDMA mode - I'm still working on fixing that). The Rocket RAID 1720 claims to be a SATA 2 PCI Card. My Patch should be able to handle your 4-Port SATA Controller properly. My Patch supports the JMicron PCI-E SATA 2 Cards I have tested. A short PCI-E Slot is not needed, you can put an X1 or X4 in a long slot. As older motherboards get harder to find a greater percentage of Windows 9x users will want solutions. Yes and Yes. The Computer I am writing this on has both sizes of PCI-E Slots and Motherboard Based SATA 2 Controllers. It is currently running on 4 2TB SATA Hard Drives. The Rocket 620 PCI-E SATA 3 is or was included with the Western Digital 3TB Hard Drives. Unfortunately, they used an AHCI only Controller. This causes Windows 9x to crash before any driver can be installed, so even Compatability Mode doesn't work.

So far I have used SATA 1.0 and 2.0 Controllers and Drives without problems. The only SATA 3.0 Card I have has an AHCI only Controller, which cannot be used with Windows 9x.

Revisions? Please be more specific.

I have developed Patches and INF Files that provide support for SATA Drives without any problems with all of the Motherboards I have tested. Most add-on SATA//E-SATA cards work including PCI-E Cards that have no Windows 9x Drivers.

Disabling Autoscan will disable all future Scans, leaving you at risk for future corruption. The safest bet is to run the Surface Scan once. Start it and go to bed. If you are sure there are no Read/Write errors, you can hexedit to reset the flags (both FATs).

If Windows thinks that a Read/Write Error occurred on a Partition, it will set a flag in the Partition to run SCANDISK with Surface Scan. The flag is not cleared if only the basic scan is done. You will need to complete a Surface Scan to clear the flag.

I assumed that. But with all of the numbers you put in that one Paragraph in your last post, it was unclear how my recommendation would be interpreted. For testing purposes, you can use anything from 44000 to at least 393216 for MaxFileCache with MaxPhysPage=40000 and I doubt it will make any difference except for Performance.

I did not suggest 131072 as a recommended setting. I suggested it as a safe setting, for testing purposes, with up to 3GiB of RAM to avoid the possibility that it would be completely ignored if it is below the internally calculated Minimum. The optimum setting depends on how you use your Computer. If you work with mostly large files, you are better off with higher settings. If you work with very large Directories of small files, you are better off with lower settings.

The ATA Commands do not have addresses because the Hard Drives don't need to know where the Data Transfer Area is. The Addresses are sent to the DMA Controller on the Chipset or HDC Card.

Actually ... there's a 2G bug in there to deal with, before worrying about 4G! : Joe. Technically it is not a bug. It is "By Design". To work with files larger than 2GB, you need to set a flag on an "Extended Open" Call. A small TSR probably could be used to force the flag.

The DMA Resources you are looking at are the numbered DMA Ports used by the standard DMA Controllers. Devices such as the Hard Drive Controllers have their own DMA Controllers and do not use the numbered DMA Ports.

Windows 9x allows you to use 64-Bit Seek arguments to make the API consistent with NT Versions. Unicode File functions are "supported" also, but contain only stubs that do nothing. SetFilePointer will return an error if the argument is outside the 32-Bit limit.

I just tested it on one of my Computers and it did not work. If you use MaxPhysPage=40000 then MaxFileCache must be at least 43282, maybe slightly more. 131072 is enough unless you have more than 3GiB of RAM. The Minimum File Cache can be found at HKEY_DYN_DATA\PerfStats\StatData VCACHE\cMinPages. Multiply the Hex Value by 4 to get the number of KB.

The DLL files I'm sure have overhead. But what I'm saying is the LIB is *literally* the same code of the DLL. You DO NOT need the DLL if you link the program with the equivalent lib. If you don't believe me, then explain what this does and why, especially since the same claim is made there. http://www.tucows.com/preview/218911 With that tool, you can make a LIB that has the Functionality of a DLL. It is not the same as the LIB Files suppliend with MSVC. As I said before, you cannot make LIBs out of core System DLLs. Your system will not boot without KERNEL32.DLL present.

I think MaxFileCache=16384 is too low. Windows will ignore a MaxFileCache that is below it's internally generated MinFileCache. I would use at least 131072.

Is the black box you all are seeing similar to the one I complained about here? It always comes up for a second and then disappears on my system, doesn't remain to cause problems, but I thought the two issues may be related. No. It is not very big, but it is permanent. It is a Forum Menu with 7 entries and they are active. It appears just below the "Sign Out" Option near the upper left corner. I am using IE6 SP1.

Giving win-9x the ability to read/write files larger than 4gb first requires a change to FAT32 to allow for storage of files larger than 4 gb. And I agree that in the end it might not be possible for win-9x to utilize such a modified version of FAT32. But I wonder if, say, Win-XP or the various public domain versions of Linux / Unix might be able to be modified to use the modified FAT32? Any reason why not? I've already done Patches to Windows XP FAT Filesystems, such as adding support for 256 and 512 Sector Clusters. So it probably is possible. Doesn't help anyone in this subforum though. How come the LIB is roughly the same size as the DLL? All the other LIB files I've found from Microsoft are functional code libraries linked INTO the EXE (using the .H file as a guide) and not simple interfaces. Why would that case be any different. The copy of KERNEL32.LIB I have is 177KB, less than half the size of KERNEL32.DLL. I would think that the LIB FIles with the same base name as System DLLs are Interfaces as well. KERNEL32.LIB might actually code some of the purely User Mode Code provided in KERNEL32.DLL, but I doubt that it could handle any Code that interfaces the KERNEL or requires internal System tables.

I have been seeing the black box for a while now. When I am Posting, I Home My Cursor, enter several blank lines so I can see and then write. I have noticed that it is not necessary to remove the extra lines before Posting.

The fact remains that there is nothing fundamental about the way clusters are chained under FAT32 that limits files to 4 gb. It's only the relatively trivial fact that there are only 4 bytes specified for the file size in the file table that is the limiting factor. Programs like winrar and vlc must obviously have their own internal file-pointers that are larger than 4 bytes, and those programs don't seem to have any problem interacting with win-98's file I/O functions. Windows 98, like NT, has a 64-Bit SetFilePointer Call, but in 9x it is restricted to 32-Bits. I don't know why someone didn't take the FAT32 filespec and find *ONE* extra byte somewhere in the file table entries to use as the 5'th byte of the file-size parameter. Having 40 bits to code the file-size (instead of 32) would have allowed for a file-size up to 1tb. They could have called it "FAT40", and by and large it would have been 100% backwards compatible with FAT32. Making FAT40 would not be very difficult, but it would be useless in Windows 9x without reworking a significant amount of the I/O Subsystem.

And actually impossible because Microsoft isn't open sourcing the win9x source, and therefore no one generally knows how things are linked in all the code or the programs. So all would need reviewed. And you'd still break programs because some programs link the libraries into their program (e.g. Kernel32.lib) and don't call the DLLs. KERNEL32.LIB is an Interface to KERNEL32.DLL, not a replacement, so Programs using KERNEL32.LIB would not be affected differently.