rloew

On your first system, you can try unistalling and reinstalling my Version 6.0 Patch using the "/M" option. This rearranges low RAM and helps solve some issues. As for your 2.5gb system, the lack of drivers is a problem we share. I have two systems that have little support for Windows 9X. I have developed a solution for unsupported SATA controllers but not for anything else. Sometimes you can find related drivers but there are no guarantees. The alternative is to add cards for functions that you need but are not supported such as Ethernet, Audio, Video etc.

That's not good! Any chance of a community patch? We could call it rloew's FDISK Patch. Due to more fundamental limitations, particularly the inability to define a Partition without erasing it, I created my own Partitioning tool called RFDISK. It provides many more features than FDISK including the setup of a Dual-Boot or Multi-Boot system. It is also not limited to 512GiB. It can easily handle 2TiB. An experimental version should support 512TiB.

Generally that would be true but there are exceptions. Sometimes there is no choice as to which FAT type you can use. I used a 4GiB FAT-16 formatted CF card in my camera which does not recognize FAT-32. Crashing is unlikely as the biggest problem seems to be Programs treating the Partition as having zero size. Windows NT supported 4GiB FAT-16 Partitions. Only >4GiB FAT-16 Partitions require Patches. rloew, sorry to hear about AOL retiring hometown - looks like AOL have made a lot of people unhappy... I've been using the updated FDISK for years - care to expand on what's buggy in it? The upgraded FDISK was not adequately debugged. If you use it to create a small Partition in the first 8GiB, it may produce a corrupt entry if an odd number of cylinders are assigned to the partition.

During Windows Installation, the WININIT command is used to merge and compress the core set of VXD files into VMM32.VXD. This is done immediately after the first Reboot. The RAM Limitation Patch is designed to work with the already merged VMM32.VXD file. It will work with the unmerged VXD files but it will be unable to uninstall or update them after Windows has merged them. If you are planning to install 98SESP later, you will need to run WININIT before you install the RAM Limitation Patch. I would recommend the following procedure when installing 98SESP. 1. Complete initial Windows Installation with my Patch Installed if not already done. 2. Boot Windows. 3. Uninstall the RAM Limitation Patch. 4. Install 98SESP but do not reboot, if asked. 5. Reinstall the RAM Limitation Patch. 6. Reboot Computer. If you are forced to reboot between steps 3 and 5 do the following: 1. Boot from a DOS floppy. 2. Reinstall the RAM Limitation Patch. 3. Boot Windows. 4. Uninstall the RAM Limitation Patch if the 98SESP Installation has not been completed. 5. Continue from where you left off making sure you Reinstall the RAM Limitation Patch before shutting down. The Exuberant website says that the 98SESP Patch fixes the 512MB Limitation. This means that it probably sets MAXPHYSPAGE to limit total RAM as well as the MAXFILECACHE setting. After you install their Patch, you should remove both lines from your SYSTEM.INI file. This should give you full access to your 2GB of RAM. EDIT: Confirmed! 98SESP Patch SPUPDATE.INF sets MAXPHYSPAGE and MAXFILECACHE

I have a Patch for Windows ME and 98SE to support SATA Drivers. http://rloew1.no-ip.com

Now that's just showing off! Not until I figure out how to use all the cores in the Triple Core in Windows 9X.

I recently developed a Patch for Windows 98, 98SE and ME that provides support for Integrated Motherboard SATA Controllers. This should resolve the slow reading and writing on your SATA Hard Drive. You can find details on my website: http://rloew1.no-ip.com

SPLIT8MB fragments available Low RAM so that Windows will not put large blocks of data in Low RAM during Real Mode Boot. The /M option on the Windows 98/SE/ME RAM Limitation Patch was intended to replace SPLIT8MB but it appears that some people need SPLIT8MB. Version 6.0 of my RAM Limitation Patch makes the same Patches as Version 5.1 for Windows 98SE when not using the /M option. My other machines have not been updated except for my older GigaByte K8NNXP (RLoew #2) which needed the /M option when I reenabled the RTL8110 Ethernet.

Thanks Rudolph. I'll probably leave the SPLIT8MB file on the system and just REM out the line in autoexec.bat rather than remove it. Then I can easily re-enable it if any problems do appear. You do say that new programs can sometimes over-write your patched files and cause problems to come back, and that will be "belt and braces" should that ever happen! Cheers, Dave. Fortunately, unlike my High Capacity Disk Patch, if the Patch is overwritten, your Computer will not boot but no damage will occur. You can reinstall the Patch from DOS. In an earlier post, you mentioned getting a blank screen when your Registry was within a certain range. I observed similar behavior. There is a narrow range where VFAT initializes properly but the boot does not complete. On occasion I have seen crashes on the VXDs that follow such as VPICD. This has been reported by others in other forums. I suspect that VFAT crashes are the most common symptom because it probably is the first to reserve DMA buffers.

I think only part of the Registry is actually loaded during Boot, so the amount of RAM and the use of Gigabit Ethernet seem to be be much more important.

I wrote SPLIT8MB first, then reworked my Patch. Either works alone on my Computer. I included SPLIT8MB in case the Patch wasn't sufficient. If it is not needed, you can disable SPLIT8MB as it will use up a small amount of RAM.

My Registry never got so big that it caused a problem. Like the Ethernet Driver, the Registry is also placed in Low RAM limiting available DMA space. It would explain why I noticed that the maximum RAM I could use decreased after every update I did to my machine. With everything loaded I could not run even with 1GB of RAM. I didn't think the SPLIT8MB.EXE Program was needed after I added the "Move VXD" Option to my RAM Limitation Patch but with a 14MB Registry you probably need it as well.

Tnere is more involved in making SATA work than the ESDI_506 Driver Registry settings.

AOL terminated their web hosting service so I had to move my website to http://rloew1.no-ip.com. Windows ME SCANDISK and DEFRAG can be used in Windows 98 and have a limit of 1TiB. There is a bug in the Windows 98, SE and ME FileSystems that under some conditions limits a Partition to 1TiB. The standard FDISK can be used in Percentage mode up to 512GiB. I haven't tested the updated version since it is buggy. I have a Partitioning Program that can handle 2TiB. Some Chipset based SATA controllers are recognized by Windows 9X as IDE drives. Windows 9X can support these SATA Controllers but a modified .INF file is required for proper operation. FAT16 partitions up to 4 GiB are supported but some programs will not work properly. With Patches, a FAT16 partition can be uo to 8GiB.

I was unable to match your handle to anyone on my Customer List. All purchasers of Version 3.2 were notified of an update to Version 5.0 in April. Version 5.0 will work with International Versions of Window 9X. If you are using the Demo of Version 3.2, it should only work in Safe Mode, it was designed not to work in Normal Mode. The Patch will work with 3GB but there are more Programs that have problems when you exceed 2GB. If you still have problems with Version 5.0, contact me for further assistance. Rudolph R. Loew

I have done some further research on HIMEMX: HIMEM is recognized by Windows during Windows Startup, so it is hooked, letting Windows take over management of all XMS calls. Any XMS Memory that was allocated before Windows Startup is not included in available Memory for Windows but is mapped into the System Arena so Windows can support the Programs and Drivers that reserved the Memory. Since most RAMDISKs use XMS Memory, they tie up System Arena space. This is why a large XMS based RAMDISK cannot be used because the System Arena runs out of space. HIMEMX is not recognized by Windows so calls to it are executed in Virtual Mode. HIMEMX uses the BIOS Interrupt 15 call to manipulate Extended Memory. Windows hooks this Interrupt so it can manage the Memory. Windows uses the standard XMS calls to take over the Free Memory during Startup. The difference is that Windows does not know about XMS Memory that was Allocated before Startup so it doesn't reserve space in the System Arena for it. This is why there seems to be more space for DOS Boxes etc. The problem is that actually using this Memory invokes the Interrupt 15 call which then causes Windows to allocate Pages to the System Arena to manage it. Reading or Writing a Large RAMDISK quickly fills up the System Arena and leads to a crash. You can setup a large XMS RAMDISK using HIMEMX but your system will crash if you try to fill it up. I also observed a problem combining HIMEMX with EMM386 whenever exceeding approximately 1408MB. EMM386 appears to allocate all of the XMS memory and then release what it doesn't need. Above 1408MB EMM386 does not release approximately twice the amount of Memory above 1408MB, so the available memory actually decreases as the total amount of RAM increases.

What you are suggesting requires copying most of the files to RAM. Copying Long File Names is a problem in DOS. It is much simpler and faster to mirror a Partition from a Hard Disk or a CD directly to the RAMDISK. Since my RAMDISKs are not limited in size, you can mirror the entire Windows Partition to RAMDISK and run entirely from RAM. I have already done this using a CD and XMSDSK to install a small Windows system without using any Hard Drives. This was before I wrote my new RAMDISKs. Owners of Computers with 4GB of RAM could put Windows in the fourth GB and still have the 3GB of working RAM.

I have completed work on a 64-Bit RAMDISK as well as a 32-Bit RAMDISK, neither of which use XMS Memory. Since Windows does not know this memory exists, it doesn't manage it or allocate precious System Arena space for it. I have been able to create and use 2GB RAMDISKs without problems. I haven't as yet determined the difference in behavior between HIMEM.SYS and HIMEMX.SYS, there isn't anything obvious in the source code for HIMEMX.

The 64-Bit RAMDISK was not intended to hold EMule files. It would be more useful as SWAP in a system with 4GB or more of RAM since the RAM above 3 to 3.5GB is not accessible to Windows9X. Windows 9X can support 4GB of combined RAM and SWAP. Some people also want to use RAMDISK to keep system temporaries that they don't want to keep after shutdown. I have completed work on the 64-Bit RAMDISK as well as a 32-Bit RAMDISK that isn't limited to 700MB.

I have seen the same clock problem with Azureus even with 3GB of RAM. I generally don't run it for more than a day at a time without rebooting.

I have run some tests on RAMDISKs and XMSDSK in particular. Conventional RAMDISKs use XMS memory, displacing Windows from said memory. Windows 98SE maps this memory into the System Arena in the last GB of Virtual memory. This memory is also used for File Caching and VMs. The larger the RAMDISK, the less File Cache is available. Looking at the list Dencorso assembled, you can see that the people who used a large XMSDSK in their setup ended up with a much lower setting for MaxFileCache. This limits RAMDISKs to not much more than 512MB so they can't be used to support 2GB of RAM without using MaxPhysPage. Some people have had problems relying on MaxPhysPage to limit memory. XMSDSK has a bug in it that makes it work improperly above 2GB of RAM when the /T option is used. I am working on RAMDISKs that don't use XMS Memory. One should be able to use the 64-Bit Memory in AMD Computers having 4GB or more RAM.

I requested a copy of VMM.VXD in Arabic. It Patched without any problem. Then the extra RAM would probably help. You can test compatabilty with the Demo for 10 Minutes. I am working on a RAMDISK that will utilize the 64-Bit RAM in AMD based Computers with 4GB of RAM or more.

So far, I know only one person who had a system that did not work stably with 2GB or RAM using my Patch. I rewrote my Demo so people could check first. That is approximately where the first memory table overflow occurs. That limit varies slightly with configuration and use of Safe Mode. My Soyo P4VGA has this problem. With 2GB the computer either doesn't boot or fails my memory test program. This has nothing to do with Windows of course. When I said FULL USE, I meant it. I allocated over 3GB of RAM without using Swap. A single Program is limited to 2GB so I needed 2 Programs running. The Patch doesn't set a RAM limit, it eliminates the limitation. My earlier version did patch HIMEM.SYS because there was a problem at 2.9GB of RAM. My current version does not need to patch HIMEM.SYS

It is definitely possible. I have actually used 3647MB of RAM with Windows 98 SE using my Patch. It actually requires at least 2 vxd files to be patched. If you look at my entries in the list at the beginning of this thread, you will notice I am not setting any limit on memory usage.

Arabic should not be a problem. DBCS versions such as Chinese were more of a challenge. Image and Video editing, some mathematical programs, etc. Combinations of programs only increase the need for memory. Where possible, I use 3GB of RAM or more to get additional benefit. I don't know of any Benchmarking program suitable to test this. I haven't used EMule, although I suspect it is more network intensive than memory intensive. Many are only interested in compatability so they often use the workarounds such as MaxPhysPage. Unfortunately these workarounds don't work in Safe Mode.