rloew

Uhh, that's not true. Shared memory is nicely swapped out, and with 64MB or less memory you can easily swap even system DLL pages.Moreover, mapped files reside in shared memory and basically are part of swap; and they are tracked by system, so apps using file mapping can use more than 2GB of virtual memory on 9x... Who cares? I did some experiments and confirmed that the Shared and System Arena Memory Pages CAN be swapped. I stand corrected. Note: Many System DLLs load into Private Memory and are inherently swappable. The Context problem still remains, so if one Application took the Maximum amount of Memory, no other Application could exceed 2GB unless they are using the SAME Memory..

My Patch increases the amount of Physical System RAM available to Windows. It does not affect the Virtual Address assignments between User, Shared and System Memory. By design, the User memory space is limited to 2GB. I have explored the possibility of moving these boundaries, but it appears to be hard coded extensively. It is possible for an Application to allocate Shared or even System Arena space to approach the 4GB limit but there are many issues: 1. This memory would be locked so it could not be swapped out. 2. The memory would not be part of an Application Context so it would be Global to all Applications, so each Application or Instance of an Application would need to allocate different Virtual Addresses. 3. These Arenas are limited System Resources so using them could deplete them. 4. This Memory would not be recovered if the Application exited or crashed before releasing it. My 64-Bit Memory SDK would not get around this issue either since, like my Patch, it provides more Physical RAM not Virtual RAM. The main benefit of the SDK is that an Application could have a lot of RAM that could be accessed by Banking

where can i get it? it would be nice to see my 98se running with 8gb ram I have an 8GB RAM system already running using Windows 98SE. In addition to the setup I described in my last post, I have two additional RAMDISKs using the 4GB not covered by the RAMDISK allocated to the Swap file.

There are two limits in Windows 9X. Total managed memory, System RAM and Swap combined, is limited to 4GB. Swap file is limited to 2GB. If you have 4GB of RAM, part of it is mapped to 32-Bit RAM and part of it is mapped to 64-Bit RAM. The amount depends on the motherboard, graphics device, and sometimes other devices. Assuming it is split into 3GB and 1GB respectively, a fairly common situation, the following combination will maximize memory use without swapping to a hard drive: The RAM Limitation Patch will support the available 3GB of 32-Bit RAM. A 64-Bit RAMDISK, setup to hold the Swap File, will use the remaining 1GB when the 3GB of System RAM is used up. I have written some tools to allow programs to use additional 64-Bit memory, but they would not be very useful unless you have more than 4GB of RAM.

Don't forget the Start and Stop bits in Serial Communications. 110 Baud = 11 Bytes. I don't know about "carved" by hand. I have a couple of 1 Bit (not Byte) Vacuum tube memories in the basement. They were soldered together, possibly by hand.

My RAM Patch allows up to 4GB of 32-Bit System RAM. In practice, motherboards limit this to 3-3.6 GB. Windows 9X can manage a total of 4GB with a maximum Swap File of 2GB. With my Patch you can have the following: System RAM: 3GB Swap File: 1GB Using my 64-Bit RAMDISKS, you can place the Swap File in 64-Bit RAM. Note, my RAMDISKs use PSE not PAE.

It may be of interest to note that the shutdown problem, identified in versions 81.98 and above of the NVIDIA Drivers, appears to depend upon the Graphics Card used. I observed the problem when I installed a 6200 card. I needed to replace at least 4 files with 77.72 versions to avoid the problem. The shutdown problem has not appeared in either of two systems where I installed a FX 5200 Graphics Card, using the 81.98 Drivers.

Bad RAM is the most likely cause. You can also try turning DMA off.

I use Windows 98SE to do development work. The open architecture makes it easier to write and test programs, especially ones that interact with the Kernel. It is also easier to reverse engineer the Kernel. The lack of DRM makes it easier to move a test configuration from machine to machine. Other than browsing or watching Video, I spend most of my time in DOS boxes. I stripped the Compiler and Linker out of Visual Studio so I write and compile C++ Programs from a DOS Box. No more large Project files, just a one line configuration string in the Source file. Security has not been an issue, since I do not make a habit of running questionable downloads. The only malware that got into my system was a Vitro worm that came from an infected XP computer on my LAN. The infected program promptly crashed harmlessly, alerting me to it's presence. I now sell a disinfector on my website to XP users who have a big problem with this worm. Many of the limitations of Windows 9x I have already overcome. I can use up to 4GB of RAM. I am no longer limited to 1GB. I can use Hard drives up to 2TB, SATA as well as IDE. When hard drives larger than 2TB become available, I am ready. I have RAMDisks that use RAM above 4GB. I haven't seen any for XP. These Patches and others significantly close the performance gaps between Windows 9x and XP. I still use my Amiga, and occasionally write code for it. It was way ahead of Windows, so no more cracks about Amigas.

I have placed the ZIP file of my Version 6.2 RAM Limitation Patch Demo on my Website. http://rloew1.no-ip.com The web pages have not been updated yet. The /M option has been restored on the Demo Version.

Seriously? 5 GB of ramdisks? why? in case you decide you want to read an entire uncompressed DVD onto a ram drive? how useful could that really be? I usually avoid car analogies but i cant help but picture a Geo Metro(the 3 cylinder one) with Windows 98 logo spraypainted on the side attempting to pull 5 Railroad cars. 1 GB is for Swap so I can use 4 GB of managed RAM without going to disk. I did not have another use for the 64-Bit RAM at the time so I gave all of it to the RAMDISKs. Of course there is nothing wrong with copying or writing whole DVDs entirely from RAM. My new Memory management software provides another use for the 64-Bit RAM so I intend to take some of the space back. The OS has little to do with how much RAM can be utilized with these tools and has no effect on speed, as that is determined mainly by the Application software. A better car analogy would be a Windows 98 logo spraypainted on a Geo Metro spraypainted on a Railroad Engine pulling 8 Railroad cars.

Bring me that "quad with 16 gig of ram" and I wil put it to good use with Windows 98. I already have an 8GB system with 3GB of System RAM and 5GB of RAMDisks. I recently wrote software to allow programs to Allocate and use 64-Bit RAM. I am working on multicore software as well. All of the RAM related software is available in the Main and Prerelease sections on my website at: rloew1.no-ip.com

I didn't have a problem with 512MB Graphics Cards. I had heard that people were saying it could not be done. I developed a Patch to address a potential issue I saw when experimenting with smaller cards. I had no problem when I bought a 512MB 6200 AGP card. I did have a problem with a 256MB 6200 PCI card. It crashed before I could even install drivers for it so I returned the card since it may have been defective. The 81.98 driver does not appear to preallocate the AGP Aperture, so the VCACHE issue or my new Patch Option may not apply. I am using the card with 2GB of RAM with my RAM Limitation Patch without the new AGP Option.

I have tried a 512MB 8400GS in my ECS 6100SM and Gigabyte MA78GM Computers with the 82.69 Drivers. Both crashed in bootup on the second initialization of NVCORE.VXD. The Motherboard Video on the ECS 6100SM also failed in the same manner, regardless of AGP Aperture size. Tests with a 512MB 6200 show that the VRAM size is not an issue with the 77.72 or 81.98 Drivers, so it is unlikely an issue with the 82.69 Drivers. Unlike my 128MB ATI Radeon card, these drivers do not allocate all of the AGP space at one time. This is the likely cause of problems using 512MB Graphics cards, that other people have reported, since this would exhaust System Arena Memory unless the File Cache is made very small. I also tried reducing File Cache without result. Substituting 81.98 Files seemed to have no effect. Substituting 77.72 Files disabled the Driver, allowing the Computer to boot into 640x480x16 mode.

I don't have a Windows 95 setup so I don't run tests on it. My Patches use Pattern recognition to make changes. This way I avoid having to Patch each possible Version. I ran my CDFS Patch Program on the CDFS.VXD Version 4.0.1111 I extracted from a Windows 95 CD. It Patched the File without any Problems. Since this is the oldest, it should work for the other Windows 95 Versions as well.

If you want to be able to use the RAM above 1GB in your system, you will need my Patch. The alternatives make Windows 9X think there is only 1GB so it doesn't crash. Conventional RAM Disks consume critical resources so you are limited to a few hundred Megabytes or less. I have written a set of RAM Disks that do not have this limitation. In addition, one of them can use the otherwise inaccessible RAM in Machines with 4GB or more of RAM. When installing Windows 9X, three of my Patches need to be installed before Windows goes into Protected mode. This occurs after the first reboot during installation. The Patches are as follows: 1. RAM Limitation Patch 2. High Capacity Disk Patch 3. SATA Patch All of my Software can be found at: http://rloew1.no-ip.com

I doubt that Windows 9X SATA-Raid drivers are available for many of the newer motherboards. I also found that in at least one motherboard, using SATA-Raid mode disabled my Adaptec SCSI Card from booting. I agree that IDE Compatability mode is more complicated. I had to write a Patch and .INF file to make it work properly, but it works on my newest motherboards. I'm not sure what VIA Driver you are using, but the 2003 Miniport Driver has a bug in it. You wouldn't see it since you are using a WD Drive. What .mpd are you referring to? Is it this one:http://downloads.viaarena.com/drivers/RAID...alATA_V220E.zip? If so, can you describe the bug in more detail, please? Why does it depend on the HDD manufacturer to manifest itself? The .MPD file I tested was for IDE. It is named VIA_IDE_MPD_V320B.ZIP on the VIAARENA site. Western Digital, like most Manufacturers did not correctly follow the ATA 48-Bit LBA Standard. VIA made the same incorrect assumption when writing the Driver. It works for most brands. Seagate followed the ATA Standard exactly, leading to an incompatability. Depending on layout, there is a 1 in 8 chance that Windows will specify the last Sector in the 28-Bit LBA range when crossing the boundary. This access will fail. I became aware of this problem in 2004 and corrected the Code in Version 2.1 of my High Capacity Disk Patch. It is documented in the User's Manual for the Full Version of the High Capacity Disk Patch. I also Patched the VIA Miniport Driver to eliminate this Problem. I believe my SATA Patch will work with the LLXX Patch, but I haven't tested it. I only have one nForce4 motherboard so I can't say for sure. My other two Motherboards with integrated SATA needed the Patch. Using a different version of my SATA.INF with my SATA Patch worked with the JMicron SATA Cards which have no Windows 9x Drivers.

You're right! The shutdown issue with the 82.69 drivers is a well-known bug of the driver itself, and cannot be related to your patch in any way, because it happens for many users of that driver, even for older boards with much less RAM. Your beta tester should try the nVidia drivers 77.72. Multibooter says it's the latest bug-free driver for 9x/ME. And he uses it with a nVIDIA 7800 GS OC (256 MiB; AGP 8x). But tell your beta tester not to remove the nVidia drivers with add/remove or unistall, but, instead, using the great freeware Driver Cleaner Pro Version 1.5 (*NOT* Driver Cleaner .NET !!!). Version 1.5 supports Win 9x/ME, despite that not being explicit in the on-site information. The Add/Remove applet or nVidia's own uninstallers don't do quite a perfect job in removing previous nVidia drivers, only Driver Cleaner Pro is able to remove them completely. I consider this the safest way to test nVidia drivers. I did notice shutdown problems with the 81.98 Driver I was using with the GeForce 6200 512MB. After some experimenting, I found I could fix the problem by replacing the following 4 Files with their 77.72 Versions: NVDISP.DRV NVCORE.VXD NVARCH16.DLL NVSVC.EXE

I did some additional tests. DOS SCANDISK will do a surface scan at 122,000,000. A new cosmetic error appear during the Surface Scan when displaying Cluster numbers above 99,999,999. The limitation on Surface scans does not appear to be related to available Extended Memory. I suspect so. Defrag does a Disk Scan before starting to defrag. If the Saved Free Space Count is -1, then DOS will recompute the Free Space. This requires reading an entire FAT, so it takes a while. If the Saved Free Space Count is valid, DOS will use it and complete the Directory listing quickly. Different Formatters may or may not set the Saved Free Space Count properly. I don't see much significance in the 6,291,204 value other than it is only 252 less than 00600000 in Hexadecimal.

I did some preliminary tests. Windows 98 SCANDISK/DEFRAG is limited to less that ~4,000,000 Clusters (~128GiB for Standard Format) Windows ME SCANDISK/DEFRAG is limited to less that ~32,000,000 Clusters (~1TiB for Standard Format) DOS, and Windows 98 appear to handle the design limit of ~256,000,000 Clusters. DOS SCANDISK can check and repair ~256,000,000 Cluster Drives but will not do a Surface Scan at 182,000,000 Clusters. The probable limit is 128,000,000. There appears to be a cosmetic flaw in DOS SCANDISK above ~43,000,000 Clusters.

I doubt that Windows 9X SATA-Raid drivers are available for many of the newer motherboards. I also found that in at least one motherboard, using SATA-Raid mode disabled my Adaptec SCSI Card from booting. I agree that IDE Compatability mode is more complicated. I had to write a Patch and .INF file to make it work properly, but it works on my newest motherboards. I'm not sure what VIA Driver you are using, but the 2003 Miniport Driver has a bug in it. You wouldn't see it since you are using a WD Drive.

The manual is currently online. You don't need to use the Wayback Machine. http://www.lagmonster.org/docs/DOS7/index.html

You're right! The shutdown issue with the 82.69 drivers is a well-known bug of the driver itself, and cannot be related to your patch in any way, because it happens for many users of that driver, even for older boards with much less RAM. Your beta tester should try the nVidia drivers 77.72. Multibooter says it's the latest bug-free driver for 9x/ME. And he uses it with a nVIDIA 7800 GS OC (256 MiB; AGP 8x). But tell your beta tester not to remove the nVidia drivers with add/remove or unistall, but, instead, using the great freeware Driver Cleaner Pro Version 1.5 (*NOT* Driver Cleaner .NET !!!). Version 1.5 supports Win 9x/ME, despite that not being explicit in the on-site information. The Add/Remove applet or nVidia's own uninstallers don't do quite a perfect job in removing previous nVidia drivers, only Driver Cleaner Pro is able to remove them completely. I consider this the safest way to test nVidia drivers. I've used the 81.98 version with a GeForce 6200 without problems so far. Drive Cleaner Pro 1.5 is not currently available through the above link. The only mirror offered has no files to download for it. The publisher's site is not free.

I just finished writing a SDK to allow Programmers to use 64-Bit RAM in their programs. This will provide access to the last ~1GB of RAM on 4GB Systems. On larger systems, such as my 8GB system (see list at start of thread), individual Programs are limited to 2GB, but collectively they could use 5GB. A modified version could be used to access the 32-Bit RAM not used by people who use the MaxPhysPage workaround.

I have a number of generic disk drivers that run on Windows 98 as well as SE. My personal favorite is freely available in the "Prerelease and Beta" section on my website: http://rloew1.no-ip.com After trying several of them on Windows 98, I have determined thay there is s serious problem elsewhere in the USB software. When transferring data from an Internal Hard Drive to a USB Drive, buffers sometimes are damaged and garbage can be written to both the USB Drive and the Internal Hard Drive. This often results in damage to a directory sector and both FAT tables, often resulting in significant data loss. I would not recommend using a USB Drive with Windows 98 until this problem is solved.