Windows uses memory addresses above 2gb for virtualized io operations.

If ram is there, there are issues.

The BEST solution is to not have that much installed.

Hi there! It's possible to load an older MS-DOS 6.2x himem.sys in config.sys or install something like QEMM 9+Helix Multimedia Cloaking.
Both have solutions have 64MB limit, I think. So Windows 98SE doesn't see more than 64MB of XMS memory to begin with.
Alternatively, someone could patch MS-DOS 7.1 himem.sys to be capped at 256MB?

Edit: Is it possible to desolder individual RAM chips on memory sticks of modern PCs?
Without breaking them, I mean. Being able to downgrade them with a hot air station would be interesting.

wierd_w wrote on 2025-06-03, 18:48:

Windows uses memory addresses above 2gb for virtualized io operations.

If ram is there, there are issues.

The BEST solution is to not have that much installed.

I agree the best solution for only windows 98 is to just have 2 gb. But since I’m looking to boot it alongside winxp or win7, it would be great to have 4 or more Gb of RAM in the system. There’s no way to force win98 to ignore memory addresses beyond 2 gb? I mean, to force it to use memory addresses in the same way as the scenario where there’s less than 2 gb installed

Is there a reason you need 4GB in Windows XP?

What sort of system are you running hardware-wise?

Shponglefan wrote on 2025-06-03, 19:10:

Is there a reason you need 4GB in Windows XP?

My father's work PC had 8GB in 2009.
He dual-booted Windows XP and Windows 7 64-Bit, on an SSD! ^^
Going beyond 2GB caused another performance boost on XP.
The OS saw 3.25GB, I think.

On my PC, a VIA C7D motherboard, about 3.5GB were available same time on XP.
It was my multimedia PC and daily driver. Had an S3 chrome card (PCIe) with 64MB RAM or so.
Maybe 128MB model, but with AGP aperture size reduced to 16-64MB in BIOS Setup..
It supported hardware- deinterlacing. Just beautiful watching DVDs with Power DVD 6! 😁

Shponglefan wrote on 2025-06-03, 19:10:

Is there a reason you need 4GB in Windows XP?

What sort of system are you running hardware-wise?

Sorry i was not very clear in my OP - my bad. Ideally I’m trying to use win 7 or maybe even win 10 in that system. It’s an EX58 motherboard with Xeon W3680 processor. It has two GPU slots so one houses an old era gpu and the other slot has new GPU. I’m hoping to be able to run mid 2010’s games. So I’m figuring 2 gb RAM won’t cut it for those

xtreger wrote on 2025-06-03, 19:20:

Sorry i was not very clear in my OP - my bad. Ideally I’m trying to use win 7 or maybe even win 10 in that system. It’s an EX58 motherboard with Xeon W3680 processor. It has two GPU slots so one houses an old era gpu and the other slot has new GPU. I’m hoping to be able to run mid 2010’s games. So I’m figuring 2 gb RAM won’t cut it for those

That makes sense. I was going to say that 2GB should be plenty up to mid-2000's. But if you're aiming into mid 2010's, then I'd probably go at least 8GB (for Win 7).

Rloew’s utilizes for Windows 98 tend to be the best way to deal with a modern machine running 98

https://rloewelectronics.com/distribute/PATCH … ARCHIVE/PRO5.1/

I add the following line to SYSTEM.INI under [386Enh]:

MaxPhysPage=70000

This will limit your RAM in Windows 9x to about 1.7GB. Keep in mind that your video card's memory needs some space, too, so you have to make Windows 98 use a bit less than 2GB.

This lets all of my Windows 9x installs run stably on my retro rocket with 8GB of installed RAM.

I created a Ramdisk, this one allows you to allocate from the top down.
RAMdrive for DOS/Win3.1

I find the Ramdisk is useful as a "scratch disk" while unzipping files and the like

xmsdsk also lets you allocate from the top with the /t argument.

Jo22 wrote on 2025-06-03, 19:08:

Edit: Is it possible to desolder individual RAM chips on memory sticks of modern PCs?
Without breaking them, I mean. Being able to downgrade them with a hot air station would be interesting.

Depends on how modern it is
If it is DDR 1-2-3+, then the quantity is determined not by recalculating the memory during POST.
But by reading the size from the SPD.
https://www.techpowerup.com/forums/threads/sp … orys-spd.20349/

I815 - depending on BIOS.
If it finds SPD, it does not count.
Without SPD - direct count.
Earlier chipsets - count.

Sorry for the late reply

rmay635703 wrote on 2025-06-03, 20:41:

Rloew’s utilizes for Windows 98 tend to be the best way to deal with a modern machine running 98

https://rloewelectronics.com/distribute/PATCH … ARCHIVE/PRO5.1/

I used LIMITMEM by RLoew, same result of FPS slowdown.

fosterwj03 wrote on 2025-06-04, 00:54:

I add the following line to SYSTEM.INI under [386Enh]: […]
Show full quote

I add the following line to SYSTEM.INI under [386Enh]:

MaxPhysPage=70000

This will limit your RAM in Windows 9x to about 1.7GB. Keep in mind that your video card's memory needs some space, too, so you have to make Windows 98 use a bit less than 2GB.

This lets all of my Windows 9x installs run stably on my retro rocket with 8GB of installed RAM.

Thanks, but for me this still gives that FPS slowdown. On your end, does this MaxPhysPage approach give you identical performance as if you only had 2 GB RAM installed in your system? Possible for you to test it out in your system if you get the time?

shevalier wrote on 2025-06-04, 05:19:

Depends on how modern it is If it is DDR 1-2-3+, then the quantity is determined not by recalculating the memory during POST. Bu […]
Show full quote

Jo22 wrote on 2025-06-03, 19:08:

Edit: Is it possible to desolder individual RAM chips on memory sticks of modern PCs?
Without breaking them, I mean. Being able to downgrade them with a hot air station would be interesting.

Depends on how modern it is
If it is DDR 1-2-3+, then the quantity is determined not by recalculating the memory during POST.
But by reading the size from the SPD.
https://www.techpowerup.com/forums/threads/sp … orys-spd.20349/

I815 - depending on BIOS.
If it finds SPD, it does not count.
Without SPD - direct count.
Earlier chipsets - count.

You seem to know about the technical side of this. Is it by chance possible to adjust any BIOS settings so that it's equivalent to using 2 Gb RAM, even though I may have more than 2 Gb installed? For your reference, the motherboard I'm using is GA-EX58-UD4. The advanced DRAM settings for it are mentioned on pg 43 onwards here: https://theretroweb.com/motherboard/manual/mo … 64612693978.pdf. If it's okay with you and if you get time, could you check it out once? Maybe there's some BIOS setting that can help with limited RAM detection? Asking because no matter what approach I use - LIMITMEM, MaxPhysPage, etc. - it always leads to degraded performance

I dont know the actual realities involved, but it sounds like what's needed is an 'XMS Killer' that reprograms the MMU before windows starts.

would need the xmm to respect a max xms sizebefore hand, reads this size (from the int15h method), then decapitates the address space above that to be unmapped to anything, using the mmu, just before windows starts.

wierd_w wrote on 2025-06-04, 15:10:

I dont know the actual realities involved, but it sounds like what's needed is an 'XMS Killer' that reprograms the MMU before windows starts.

would need the xmm to respect a max xms sizebefore hand, reads this size (from the int15h method), then decapitates the address space above that to be unmapped to anything, using the mmu, just before windows starts.

I searched online based on what you said, and found XMGR.SYS : https://home.mnet-online.de/willybilly/fdhelp … d/base/xmgr.htm. The trouble is that its documentation and usage is going above my head. Is it the kind of tool that does what you mentioned? i.e. completely shutting off visibility to memory beyond 2 Gb?

xtreger wrote on 2025-06-04, 15:40:

wierd_w wrote on 2025-06-04, 15:10:

I dont know the actual realities involved, but it sounds like what's needed is an 'XMS Killer' that reprograms the MMU before windows starts.

would need the xmm to respect a max xms sizebefore hand, reads this size (from the int15h method), then decapitates the address space above that to be unmapped to anything, using the mmu, just before windows starts.

I searched online based on what you said, and found XMGR.SYS : https://home.mnet-online.de/willybilly/fdhelp … d/base/xmgr.htm. The trouble is that its documentation and usage is going above my head. Is it the kind of tool that does what you mentioned? i.e. completely shutting off visibility to memory beyond 2 Gb?

No, this looks like an alternative to himem.sys or Himemx/jemmex.exe

What I suggest probably does not already exist, but would be fairly straight forward to write.

It would require:

1)An XMM (himem.sys, et al) be loaded
2) this XMM is able to limit the managed XMS size arbitrarily (himemx, qemm.sys, et al)
3) this XMM reports the available XMS size via int15h

What it would do:

1) call int15h to get max serviced XMS.
2) calculate the physical 32bit flat mode address of the end of that space.
3) instruct the MMU to unmap everything above that (maybe with exception via command line argument, so we dont blindly clobber AGP/PCI/PCIe crossbars, or ramdisks serviced by isolinux+memdisk, et al.)
4) exit

(With obvious error handling on error, naturally)

to my knowledge, no such tool exists.

wierd_w wrote on 2025-06-04, 16:20:

No, this looks like an alternative to himem.sys or Himemx/jemmex.exe […]
Show full quote

xtreger wrote on 2025-06-04, 15:40:

wierd_w wrote on 2025-06-04, 15:10:

I dont know the actual realities involved, but it sounds like what's needed is an 'XMS Killer' that reprograms the MMU before windows starts.

would need the xmm to respect a max xms sizebefore hand, reads this size (from the int15h method), then decapitates the address space above that to be unmapped to anything, using the mmu, just before windows starts.

I searched online based on what you said, and found XMGR.SYS : https://home.mnet-online.de/willybilly/fdhelp … d/base/xmgr.htm. The trouble is that its documentation and usage is going above my head. Is it the kind of tool that does what you mentioned? i.e. completely shutting off visibility to memory beyond 2 Gb?

No, this looks like an alternative to himem.sys or Himemx/jemmex.exe

What I suggest probably does not already exist, but would be fairly straight forward to write.

It would require:

1)An XMM (himem.sys, et al) be loaded
2) this XMM is able to limit the managed XMS size arbitrarily (himemx, qemm.sys, et al)
3) this XMM reports the available XMS size via int15h

What it would do:

1) call int15h to get max serviced XMS.
2) calculate the physical 32bit flat mode address of the end of that space.
3) instruct the MMU to unmap everything above that (maybe with exception via command line argument, so we dont blindly clobber AGP/PCI/PCIe crossbars, or ramdisks serviced by isolinux+memdisk, et al.)
4) exit

(With obvious error handling on error, naturally)

to my knowledge, no such tool exists.

Hm well the above technical terms are alien to me. One thing though - I found this link as well: https://forum.ru-board.com/topic.cgi?forum=62 … 0&start=1220#19

The third method is to limit the amount of memory reported to Windows by the HIMEM.SYS driver. It can be called the most reliable, since it allows you to "hide" excess memory from Windows, as if you removed extra strips from the system unit and, accordingly, eliminate all possible conflicts and glitches. Actually, the HIMEM.SYS driver itself cannot be modified, or no one has done it yet, so alternative drivers with similar functionality are used instead. I know Win9x Memory Burn Driver aka BURNMEM [?] by SweetLow (it differs from the others in that it performs the necessary tweaks at the BIOS level, even before loading HIMEM.SYS), XMGR Special Build 512 Mb Limit aka LIMEM [?] by MERCURY127 (there is already a new version ) and HimemX by Japheth (with IO.SYS Patch for SafeMode by xrayer ). They allow you to set any memory size, which can help when working with memory greater than 1 GB. This method is also recommended for use during the initial installation of Windows (see point 3 in the next post).

The above post seems to suggest maybe one of the above tools could work? What do you think?

If used in conjunction with himem.sys, it would limit what himem.sys manages, but would not call the mmu to unmap what's there.

Very simple:

Add RLOEW's limitmem to config.sys as the first line.