rloew

@Den: Your Superfloppy Image seems OK but it is not quite "Blank". It has three clusters marked BAD and some sort of Signature near the end. It, of course, cannot be used on a CD for Floppy Emulation. Any reason for the 32K sized clusters? It should be 2K: http://support.microsoft.com/kb/140365/en-us and it really should be FAT16. Or am I missing something? jaclaz A: and B: are assumed to be FAT12. You cannot use FAT16 or FAT32 without problems. A FAT12 Partition is limited to 4087 Clusters so using 2K Clusters would greatly exceed this number. I originally thought that the distinction between FAT12 and FAT16 was the Number of Sectors being the 16-Bit Value at Offset 0x13 vs. the 32-Bit Value at Offset 0x1C in the Boot Sector. I now know that this is not true. A separate test is performed to get the Number of Sectors from the appropriate location. Either one can be used with FAT12 or FAT16 if the Partiiton is less than 32MiB. The distinction between FAT12 and FAT16 is based on the number of Clusters available on the Partiition. Oddly enough, DOS and Windows 9x use different limits so it is possible to create a Partition that looks like FAT12 to one and FAT16 to the other. SuperFloppies and CD Floppy Images have no MBR, so there is no Partition Type Code.

0x03 allows up to 36MB 0x02 allows up to 18MB 0x01 allows up to 15MB Thread not yet in existence.

The Bootable part of a CD can be made up to 36MB when emulating a Floppy (A:) or any size when emulating a Hard Disk (C:).

Hi; Thanks for taking the time to reply... Under Windows ME, no apparent change...and Everest reported the usual 1024 meg installed...1023 meg System Under 98se ....patch caused everything to report identical Windows ME including in Everest...(both system property sheet and Msinfo32 reported 1024 meg) Thanks Jake This confirms what I said before. By fragmenting memory, Windows 98 lost enough space, plus possible rounding down, in the reporting function, that it lost the 2MB. I would have to try one of my oldest versions of the Patch, before I fixed the fragmentation problem, to see if it makes a difference and if it gets worse as the amount of RAM increases.

In Windows 98, install my Demo Patch, reboot, note the result and immediately uninstall and reboot. In Windows ME, install my Demo Patch in Safe Mode, reboot, note the result and immediately uninstall and reboot.

Your Motherboard can't be very recent. It only reserved 20K (BFFFB000-C0000000). Compare that with my MA785: Memory Range 00000000 - bfdf0000 START = 00000000 LENGTH = 0009f800 TYPE = Memory START = 000f0000 LENGTH = 00010000 TYPE = Reserved START = fec00000 LENGTH = 01400000 TYPE = Reserved START = e0000000 LENGTH = 10000000 TYPE = Reserved START = 0009f800 LENGTH = 00000800 TYPE = Reserved START = bfe00000 LENGTH = 00100000 TYPE = Reserved START = 00100000 LENGTH = bfcf0000 TYPE = Memory START = bfdf3000 LENGTH = 0000d000 TYPE = ACPI Reclaim START = bfdf0000 LENGTH = 00003000 TYPE = ACPI NVS START = 1:00000000 LENGTH = 3:40000000 TYPE = Memory It reserves 2MB + 64K. The SMM Memory (BFF00000-C0000000) is not even listed. I used my BIOSMEM Program to create this report. It works with DOS and Windows 9x. It shows both the E801H and E820H results from INT 15H.

1160 GiB is not the limit how much Windows 98 can report, it is the limit of how much RAM it can USE without Patching. My Patch does not fix the report generator. The 2MiB deviation triger49 reported is most likely due to the fragmentation of memory mapping I mentioned before. If there is any question, he can try the Demo of my Patch. His motherboard is not new enough to have the 2MiB+ of reserved space. I have only seen it in my GA-MA785 Motherboard. Your 2GiB deviation is due to the use of MaxPhysPage to limit what Windows uses. RAMDisks have the same result as they limit what Windows sees. The report shows how much RAM Windows can use.

I believe it is related to the sloppy mapping of Physical Memory done by Windows 98 during Startup. It disappears when my RAM Limitation Patch is run. Windows ME uses a better algorithm. In newer Motherboards, 1 or 2MB can disappear because the BIOS reserves the space for SMM Code and/or USB Emulation.

The license is per Computer. A discount is available if you have several. You will definitely need it for the Computer with a 15MB Registry. Otherwise, after you fix your more immediate problem, you are likely to get VFAT errors again.

Did you use the /M Option when you installed my Demo Patch? I have tested it with an 18MB SYSTEM.DAT successfully. Try disabling the Ethernet Driver, especially if it is Gigabit capable.

All Windows Versions use DOS or BIOS Calls during bootup until the Protected Mode Disk Driver is loaded so the BIOS must be able to access any and all Files that are used before the Protected Mode Driver is loaded. I have a DDO that can supplement the BIOS up to the ATA Limit of 128PiB.

I fixed a bug in the Demo. Do not use the older one, it is not safe. Use the newer one. You can replace the DLLHOOK.INI while the System is running and then Reboot.

A 5GiB Demo is now available for Download.

I have posted the description on my Website. I am preparing a Demo that can be used for testing.

Neither recognizes the GPT format. GPT Partition scanning code would have to be added. It would be easier to replicate the GPT Partitions into an MBR replacing the dummy bridge MBR normally used in GPT Drives. and GPT based partitions require 64bit operating systems! they won't work on 32bit OSes speaking about the 2TB hard drive limit, FAT32 and NTFS can support up to 2TB volumes and no greater than that The 2TiB Partition limit can be increased by using larger Sectors, either actual or simulated by translation software. I have done it both ways using 3TB Hard Drives .

Basically what I was saying. Unfortunately, it appears that no possible configuration insures total compatability. Patching DOS and Windows 9x may help. Special MBR Code and/or a DDO may be needed.

Not so rare. Anybody's XMS RAMDisk will do.

The Windows 9x MSDN Library Documentation does not mention any limit. I traced the GetPrivateProfileString API Call. It definitely thunks down to 16-Bit Code. Running the GetPrivateProfileString API Call with a Destination Buffer size >64K Fails.

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. I will be releasing this Software soon. I have decided to call it the "Large File Emulator" Package. It is now Windows Explorer compatable and works with 7-ZIP.

I did not try to Import anything, but I did create a new Registry successfully. It just takes a long time. As I noted, make sure you use SMARTDRV or you will be waiting days. If it fails, there may be other issues, not just size.

Neither recognizes the GPT format. GPT Partition scanning code would have to be added. It would be easier to replicate the GPT Partitions into an MBR replacing the dummy bridge MBR normally used in GPT Drives.

It can be downloaded using GenuineCheck from Windows 98.

Do the MS 'scanreg' and 'regedit' DOS tools work properly for you with such large registries? I've found (per above) that 'regedit' does not. As for 'scanreg', it seems happy to backup, restore and "vanilla test" large registries, although I haven't been brave enough to try "scanreg /fix" since my registry has grown beyond the 8M mark that is mentioned earlier in this thread. Joe. Haven't tried SCANREG, but REGEDIT (DOS) does work. Extracting and rebuilding the Registry took two hours with SMARTDRV enabled. Without SMARTDRV plan on two DAYS. EMM386 and any XMS TSR's, if any, come first. The Registry appears to be next. The VMM32 Modules follow. The /M Option disrupts this allocation, so that the Registry and VMM Modules are placed above the 16MB range.

There is no 16MB limitation on the Registry size. I just tested an 18MB Registry. The 16MB limit occurs when the Registry and/or Gigabit Ethernet Drivers take up too much of the lowest 16MB of Physical RAM. I added the /M Patch to my RAM Limitation Patch to insure that this did not happen regardless of Registry Size or type of Ethernet.

Windows 9x does not support 4KiB Sectors. I have written a Patch as part of my TBPLUS package to support 4KiB Sectors. This is needed if you want to use the USB 3TB Drives. With 4KiB Sectors, the limit is 16TiB per Partition. DOS 7 can be Patched to support 32KiB Sectors allowing 128TiB Partitions. I have also developed an extended MBR format that allows Drives to support 512TiB with 512B Sectors, 8PiB with 4KiB Sectors. This is required to use Internal 3TB Hard Drives. All 2TB Drives use 512B Sectors externally and can be used with Windows 9X. Western Digital pioneered the use of 4KiB Sectors Internally. These "Advanced Format" Drives can be used, but will run slowly if accesses to the Drive are not aligned on 4KiB Boundaries. Partitions have to be specifically Formatted to ensure alignment.