rloew

Well, a total address space absolute limit of 4 GiB for 9x/ME makes sense to me. Of course, if a workaround is found, I'd like to be aware of it, so keep us posted about your research. BTW, if you want to revise and update the info for the RLoew(7) machine (or any others), do PM me. As it appears now on the list, the swap file ramdisk has less than 1 GiB allocated to it, but that, of course, is due to your letting Win98SE/ME see 3327 MiB, in the reported configuration. Moreover, I understand you have at least one machine dual-booting Win 95, now, and that would be an interesting addition to the list. Extending the 4GiB limit would not help much. The limit would only increase to between 5GiB and 5.6GiB (32-Bit RAM + 2GiB). There is no need to change my entry. I didn't change it. I haven't thought about the memory size in a while so I just assumed it was 3GiB/1Gib. The Multiboot of Windows 95 and Windows 95C is on the same machine but is only temporary and requires locking out the main drive. I finally resolved the SATA Problem for Windows 95C so I could put a permanant Partition for it if I want. I have room for 62 bootable Partitions.

Well, thanks for the heads up. But I'm quite stisfied with the current settings I'm using, and don't intend to change them. I do find my 1.5 GiB ramdisk quite useful. It was not a recommended change. I have a similar setup as yours on one machine myself. The point was that if Windows itself has access to 3GiB of RAM it will only use up to 1GiB of Swap. Your RAMDisk reduced Windows RAM allowing more Swap to be used. This is why I only allocated 1Gib for the RAMDisk I put the Swap File in on my 8GiB RAM Machine. I made one attempt to extend this limit but it failed, so further research is needed.

Yes, you are quite correct and I've edited my previous post. I've had an XMSDSK RAM drive of over 800MB working properly with 1GB total RAM, as mentioned in an earlier post. I don't know whether people with lots of installed RAM (> 1GB) have given up using XMSDSK because of problems they may have had. To avoid these, MaxFileCache must be defined in [vcache] section of System.ini and, very importantly, run ScanDisk with Thorough test to make sure all the clusters on the RAM drive are actually there. If you are using the standard HIMEM.SYS and create a large XMS RAMDisk, the problem will appear immediately. If you use the alternative HIMEMX.EXE instead, the RAMDisk will only use the System Arena space as it fills up so you may not see any problems until you have written hundreds of megabytes into it. To clarify my earlier Post about RAM + Swap limited to 4GiB. Total RAM refers to the amount of Physical RAM that Windows recognizes. If you have a RAMDisk or limited Memory with MaxPhysPage, Total RAM is less than Physical RAM. @Dencorso. If you remove your RAMDisk so Windows sees 3GiB of RAM, you will only be able to use 1GiB of Swap.

There are a few limitations in Windows 9x relating to Swap Space: Total RAM + Total Swap is limited to 4GiB. Swap Space appears to be limited to 2GiB. XMS RAMDisks take up System Arena Space as does the File Cache. Exceeding a few hundred Megabytes is likely to crash unless you lower your MaxFileCache Setting. A 1GiB XMS RAMDisk is impossible. I have written a set of Non-XMS RAMDisks that do not have this limitation. One Version can use 64-Bit Memory, so it is not limited to 4GiB.

Try the following line in your AUTOEXEC.BAT file: REGEDIT C:\myfile.reg

Changing the Partition currently designated G:\ to NTFS wil cause the Drive Letters after it to shift downward. If you need to preserver the Lettering of the other Partitions, you can delete the cuirrent G:\ Partition and replace it with a tiny FAT Partition and the remainder with a NTFS Partition.

@RLoew: Would you please be so kind as to compare Petr's Ndis.VxD 4.0.1114 with the original 4.0.1113 and give us your expert evaluation about the advantages, if any, offered by Petr's patched file? The patched file is downloadable from Petr's original post, quoted above. The two versions are nearly identical. A Processor speed check is coded slightly differently, but the results are equivalent. You can stick with the official 1113 Version.

I wish I had taken a screenshot of the error when I saw it before, now I am unable to reproduce it. Everything seems to be working fine now.. that's good of course, but I don't know what was going on before. EDIT: I can now also confirm testing of the UDF driver on Windows 95B, everything still works perfectly! I can post a screenshot of the Windows 95 missing data, but there is no disagreement since Windows 95C does appear to work OK at least most of the time. If a reproduceable problem is found I can test further. The Control Panel for my main Website is up so I have added the Windows 95x UDF Driver to it.

Is it maybe the issue "Windows Explorer Reports 4 GB of Files as 0 Bytes" (KB158045), or related to it? BTW, there is also the Copy2GB+ issue (this thread), mentioned in KB318293, which was tackled initially by LLXX, then eventually solved fully by the "Anonymous Patcher"... it's not clear to me whether that issue also exists in Win 95 (most probably) and whether a port of the existing patch to kernel32.dll v. 4.10.0.2225 (available renumbered as v. 4.10.0.2226) to 95 is viable and/or necessary. I consider this patched kernel32.dll a *must* for all 98SE (and the corresponding 4.90.0.3001 for ME) installations, for it unleashes the full 4 GiB capacity of FAT to 98SE (and ME), which are otherwise actually limited to 2 GiB only (although it's controversial whether the corresponding patch is really needed for ME). This particular issue is related to the implementations of _llseek and SetFilePointer. On rereading the thread I pointed to above, I've found out there is also a patched kernell32.dll for 98FE, which I had completely forgotten about. @RLoew: Thanks a lot for releasing the UDF patch as freeware! You do rock! I did some further testing. In Windows 95C, everything was reported correctly. In Windows 95, the capacity of the DVD was correctly displayed as 4.36GiB but the longer Byte Count was replaced by dashes. The Explorer has the correct data but the Programmer didn't bother writing a 64-Bit Binary to Decimal converter. Since Windows 95 doesn't recognize FAT32, there was no need to show numbers over 2.1 Billion. Only my 256 Sector Cluster Patch would push the limit over 4GiB.

Yes, himem.sys was in my config.sys. I downloaded something called "Free Fdisk" (Author: Brian E. Reifsnyder) version 1.2.1. I could only find it on archive.org: http://web.archive.org/web/20060110183341/ffdisk.webaps.de/fdisk121.zip It correctly identified the 750 gb drive and printed it's size correctly on the screen (no funny math or misplaced numbers). I used it to delete and then re-create a single primary FAT32 partition on the 750 gb drive using the max-drive-space option. After re-booting back into DOS, I ran format.com (win-98 version) and this time format used 32kb cluster size and the drive ended up with 22.9 million clusters. Norton Disk Doctor (NDD32.exe) still crashes with a blue-screen error (Fatal Exception 0E) even when invoked with /NOLBA command-line switch. I'm pretty sure I've seen NDD run on drives with more than 22.9 million clusters, so this result was not expected. However, Windows-ME version of scandisk (scandskw.exe / dskmaint.dll v4.90.3000) did perform a standard drive test without any issues or error messages (there were no files on the drive - not sure if this makes any difference or not). It seems that format.com will use and give priority to any cluster-size setting that already exists in the FAT boot sector, perhaps even expecting this value to already be set at runtime (perhaps format.com does not actually set the sectors-per-cluster value in the FAT boot sector). So I think this shows that format.com will work with drives at least up to 700/750 gb (depending how you define gb) and that Win-me scandisk is also compatible with a single volume of that size (22.9 million clusters). Any or all versions of Microsoft-supplied fdisk.exe are definitely limited to a max drive size of somewhere between 500 to 750 gb (most likely 512gb). Free Fdisk version 1.2.1 is a suggested alternative for drives larger than 512 gb. FORMAT.COM assumes that the Boot Sector is correct and will not change it if valid. Only by zeroing it out were you able to force FORMAT.COM to create a new one based on Microsoft's algorithm. You have confirmed what I said in my earlier post.

I never said the FSD (File System Driver) was simple, just simpler than the rewrite of the User API. Kernel32 itself limits SetFilePointer Calls to 32 Bits even though the specification for the Call is 64 Bits. Bypassing the limit check still results in truncation. If I recall correctly the internal file tables only support 32 bit positioning information.

I tested rloew's PTCHCDFS on Windows 95 C with CDFS.VXD 4.00.1113, the file is patched correctly, but I discovered a few minutes ago that if the DVD contains >4GB worth of files, the "Used space:" and "Capacity:" byte counts on the General Properties tab only show as "---". If the DVD has <4GB worth of files, the byte count shows up correctly. I have not used this patch yet on Windows 98, so I do not have a reference, but I assume this is not a problem in 98. The CDFS Patch works fine on Windows 98. It could be the Explorer not recognizing the output from the modified CDFS. The UDF Package is now available on my Website

Cluster size is not defined by Partitioning a Hard Drive. It is set during Formatting. I have never used Ranish, so it may be doing both. If possible, have Ranish blank the Partition rather than formatting it, then try FORMAT.COM.

I was able to Patch UDF.VXD 4.10.2223 using the same method.

After not finding it on Microsoft's Website, I checked www.mdgx.com and got it early this morning. Since it is the only one publicly distributed (unless you count 3001), I will see if it can be modified as well.

FORMAT.COM may be relying on the existing Cluster size when it reformats. 16KiB Clusters is not the recommended Cluster size. Another possibility is that it is using the truncated value of 60GB to decide the Cluster size.

Wonderful! That's great news! You do rock, RLoew! BTW, which one? 4.10.1998, 4.10.2222 or 4.10.2223 (Q310695)? I used 4.10.1998 which would have been the closest to Windows 95. I haven't tried the others. The link you had for 4.10.2223 was for 4.90.3001.

It would not be a rewrite of the "whole" OS, but a significant rewrite of the FileSystem API code (KERNEL32.DLL and possibly IOS.VXD) to add >4GiB File support. Adding ExFat would be somewhat simpler but would have limited functionality, similar to NTFS on Windows 9X.

I have found a way to modify the Windows 98 UDF Driver to work with Windows 95 and 95C. This should solve the problem.

Installing a new Filesystem will not be sufficient. The System APIs do not support >4GB, in particular SetFilePointer.

If your AUTOEXEC.BAT File is empty, you can just delete it.

I tested both Windows 95 and Windows 95C using a DVD I burned with my own burner. It contained ISO9660 and Joliet Filesystems. The Long and Short Filenames worked fine.

I have seen some problems with SCANDISK when using FAT16 on A:.

4078 is based on the standards. DOS and Windows computes the number of available Clusters then tests it against a threshold. If below, assume FAT12. If above, assume FAT16. To complicate things further, DOS and Windows do not even use the same threshold. DOS uses 4086 and Windows uses 4085. A partition could be interpreted as FAT12 by DOS and FAT16 by Windows. FAT16/FAT32 discrimination is even worse. DOS uses 65526 as a threeshold, Windows tests the 16-Bit # of Sectors per FAT field.

So this gives 4MB clusters? Yes. 256 Sectors per Cluster. 16K Bytes per Sector. This works only for DOS. I have not made a Large Sector Patch for Windows, just the 256 Sector Patch. So the current limit for modded Windows 9X is 512MB for FAT12.