spiroyster wrote on 2026-09-14, 18:57:

Windows XP 32-bit limits processes to 2GB unless built with laa (Large Address Aware, which is a compiler flag), in which (as an app) you can access 3GB, no more. If you want/need more within a single process, you have to use file memory mapping, not RAM (which is kinda application version of using a swap file). Swapping, RAM mapping (address translation) etc is all handled by the OS since we have something called protected memory, and have done for a number of decades now.

The PAE was only really useful for server/enterprise grade since it allowed multiple processes (which used say 2GB), not allowing a single process to use > 2GB (3GB with laa), so irrelevant for 'devs' unless they were implementing multiple processes and handling inter-process communication themselves (but each process was still limited to 2GB... or 3GB with laa).

This limitation was lifted for 64-bit windows which are no longer limited to 2GB process (it is an internal OS limitation, you would have to ask MS why they chose this limit for 32-bit Windows).

Mostly correct, and the closest to reality Ive seen.

a normal 32 bit process gets 4Gb virtual address space because 32 bit pointers can address 2³² locations.
By default on 32 bit XP that 4Gb is split between 2Gb user space and 2Gb Kernel space.
So a normal app can only allocate roughly 2Gb.

The /3Gb switch can be used to make that split 3Gb user space 1Gb kernel space however the app also needs LLA support to use it otherwise Windows limits it to 2Gb.

/PAE is often misunderstood, it increases the amount of physical RAM the OS can manage. It does not make 32 bit pointers larger, a process still sees 2Gb normally and 3Gb with the /3Gb switch and LLA.

What /PAE really does is allow that "process" of RAM usage many times over, so app 1 gets 2Gb, app 2 gets 2Gb, app 3 gets 2Gb, app 4 gets 2Gb etc etc. Without /PAE the system is limited to "4Gb"
So the short version is /PAE increases how much RAM Windows can manage, not how much memory a single 32 bit process can directly address. The per process limit is fundamentally an address space issue, not a physical RAM issue.

But all of that doesnt really correct what you said, it irons it out.

I have a Supermicro P8SCi board which supports up to 4 GB of DDR2 RAM, but in practice only 3 GB are available. Because of this it has two 1 GB modules and two 512 GB installed.

And this is using onboard video. Adding e.g. a 1 GB GeForce GT610 drops the available memory down to 2.75 GB.

ETA: the manual has this to say

Question: After I have installed 4 pieces of 1GB Memory, why does the BIOS only detect about 3.15 GB of memory during POST?

Answer: Because the chipset does not support memory remapping, so there is a memory hole located around the 4GB memory address.

Errius wrote on 2026-09-16, 04:54:

I have a Supermicro P8SCi board which supports up to 4 GB of DDR2 RAM, but in practice only 3 GB are available. Because of this it has two 1 GB modules and two 512 GB installed.

And this is using onboard video. Adding e.g. a 1 GB GeForce GT610 drops the available memory down to 2.75 GB.

Thats a platform limitation of the Intel E7221 chipset. It only has a 32bit physical address bus and doesnt support memory remapping, so PCI MMIO takes a bite out of the 4GB address space before the OS even loads. Even a 64bit OS would see the exact same cut off.

ElectroSoldier wrote on 2026-09-16, 18:30:

Errius wrote on 2026-09-16, 04:54:

I have a Supermicro P8SCi board which supports up to 4 GB of DDR2 RAM, but in practice only 3 GB are available. Because of this it has two 1 GB modules and two 512 GB installed.

And this is using onboard video. Adding e.g. a 1 GB GeForce GT610 drops the available memory down to 2.75 GB.

Thats a platform limitation of the Intel E7221 chipset. It only has a 32bit physical address bus and doesnt support memory remapping, so PCI MMIO takes a bite out of the 4GB address space before the OS even loads. Even a 64bit OS would see the exact same cut off.

Which was exactly the problem I was mentioning with XP 64bit, and Intel HDA drivers that expect the BAR to be in 32bit memory space.
The system can have all the address lines in the universe, the driver wont work, because it expects the BAR in 32bit space, which at best, bifurcates the RAM region.

The correct solution is to relocate the BAR, and write drivers that understand where and how to look for it once that is done.

Neither of those was the case back then. Even after 64bit became mainstream, and greater than 4gb was a thing, Neither MS nor driver makers budged. By then, "Those are *LEGACY* things! NOT TOUCHING IT!"

The only option you had was to tell windows to just disconnect ram after a certain size with a kernel boot option. ONLY THEN would sound turn on.

ElectroSoldier wrote on 2026-09-16, 18:30:

Errius wrote on 2026-09-16, 04:54:

I have a Supermicro P8SCi board which supports up to 4 GB of DDR2 RAM, but in practice only 3 GB are available. Because of this it has two 1 GB modules and two 512 GB installed.

And this is using onboard video. Adding e.g. a 1 GB GeForce GT610 drops the available memory down to 2.75 GB.

Thats a platform limitation of the Intel E7221 chipset. It only has a 32bit physical address bus and doesnt support memory remapping, so PCI MMIO takes a bite out of the 4GB address space before the OS even loads. Even a 64bit OS would see the exact same cut off.

I thin the Vaio FE series had the same problem. Not sure which chipset was, maybe Intel 945PM? But on that machine you could even upgrade the CPU from Core solo to Core/Core2 Duo, but not the RAM to 4GB (albeit apparently accepted).

The machine, if filled to 4GB, booted but did many weird things, starting from the invisible (but working) boot menu , progress bar instead of the boot logo in win 7, and other odd things when the OS was started (no matter if the OS was 32 or 64 bit).

The Solutor wrote on 2026-09-16, 23:20:

ElectroSoldier wrote on 2026-09-16, 18:30:

Errius wrote on 2026-09-16, 04:54:

I have a Supermicro P8SCi board which supports up to 4 GB of DDR2 RAM, but in practice only 3 GB are available. Because of this it has two 1 GB modules and two 512 GB installed.

And this is using onboard video. Adding e.g. a 1 GB GeForce GT610 drops the available memory down to 2.75 GB.

Thats a platform limitation of the Intel E7221 chipset. It only has a 32bit physical address bus and doesnt support memory remapping, so PCI MMIO takes a bite out of the 4GB address space before the OS even loads. Even a 64bit OS would see the exact same cut off.

I thin the Vaio FE series had the same problem. Not sure which chipset was, maybe Intel 945PM? But on that machine you could even upgrade the CPU from Core solo to Core/Core2 Duo, but not the RAM to 4GB (albeit apparently accepted).

The machine, if filled to 4GB, booted but did many weird things, starting from the invisible (but working) boot menu , progress bar instead of the boot logo in win 7, and other odd things when the OS was started (no matter if the OS was 32 or 64 bit).

It could be.
I dont know that machine so I couldnt say for sure without looking it up but I can tell you one thing, having read so much online over the years what people put down to an OS problem to do with memory is often a platform problem.
Not always of course, it can be a mix of factors but back then the motherboard manufacturers didnt help the situation at all in the way the implemented some of the features on their platforms. The the other manufacturers, such as sound cards and video cards too didnt help either and it all lead to Microsoft ending PAE support on XP after SP2 because it was being put down to a Windows problem

ElectroSoldier wrote on Yesterday, 18:09:

It could be.

I remembered correctly, apparently

https://forum-en.msi.com/index.php?threads/94 … 11/#post-933739

Not always of course, it can be a mix of factors but back then the motherboard manufacturers didnt help the situation at all in the way the implemented some of the features on their platforms. The the other manufacturers, such as sound cards and video cards too didnt help either and it all lead to Microsoft ending PAE support on XP after SP2 because it was being put down to a Windows problem

I use PAE and 32 bit OSes currently even on Win 10 to this day. PAE is artificially disabled by a kernel policy, the same kind of policies that disables AERO in win 7 Starter, that limits the number of SMB connections on non server SKUs, that blocks the official WMC on non WMC SKUs, and other dozens of features/behaviors.

That said some brands were quick to disable the PAE support on SKUs, so if you are an unlucky Intel user with an integrated VGA, PAE is a no go, unless you use the XP drivers in Win7, or the basic display driver in newer Windows, ATI/AMD is usually problem free, Nvidia disabled the PAE support in drivers after 333.11 (may 2014).

Taking in account that Win 6.0 had official updates until January 2026, removing the PAE support in 2014 and even earlier in Intel case was a pretty petty move.

The Solutor wrote on Yesterday, 22:35:

Taking in account that Win 6.0 had official updates until January 2026, removing the PAE support in 2014 and even earlier in Intel case was a pretty petty move.

Last NT 6.1 Win32 updates were rolled in October 2024. That was POS Ready 7 end of life.

I think PAE was still supported on Windows XP branch.

The Serpent Rider wrote on Today, 04:08:

Last NT 6.1 Win32 updates were rolled in October 2024. That was POS Ready 7 end of life.

The Last update for nt 6.1 is KB5073699 (Jan 2026, just like NT 6.0)

I think PAE was still supported on Windows XP branch.

It was supported in SP0 when practically no one had ever seen 4GB together on client machines, they disabled it in SP1 or SP2 (not sure which one of the two).

PAE was left in place in servers, obviously.

The Solutor wrote on Today, 05:25:

The Last update for nt 6.1 is KB5073699 (Jan 2026, just like NT 6.0)

Server 2008 R2 never had 32-bit version. Last 32-bit branch was POS Ready 7.

It was supported in SP0 when practically no one had ever seen 4GB together on client machines, they disabled it in SP1 or SP2 (not sure which one of the two).

I meant Nvidia drivers. Some enthusiasts use(d) patched SP3 with PAE on modern(ish) hardware.

The Serpent Rider wrote on Today, 05:32:

Server 2008 R2 never had 32-bit version. Last 32-bit branch was POS Ready 7.

I meant that the support for 6.0 and 6.1 ended at the same time, then, yes x86 flavor of 6.0 ended to be more updated than 6.1,6.2,6.3 and many flavours of 10

I meant Nvidia drivers.

Yes but you get a nice black screen in PAE, the last working in PAE mode is the one I mentioned above

Some enthusiasts use(d) patched SP3 with PAE on modern(ish) hardware.

Yes it's what most people do (me included), from XP to Win10

But there is also the way of switching the SKU to Server, it doesn't patch anything, so is somewhat more elegant, but on NT6+ you get the limit raised just to 4G, while with PAEpatch there are various flavours that range from 8GB to unlimited

What's so special about x86 XP? Why not go with x64 XP?

UCyborg wrote on Today, 09:46:

What's so special about x86 XP? Why not go with x64 XP?

Well XP64 has its own set of issues and compatibility quirks, so its really choose your poison and decide which set of quirks you want to deal with.

UCyborg wrote on Today, 09:46:

What's so special about x86 XP? Why not go with x64 XP?

Drivers

UCyborg wrote on Today, 09:46:

What's so special about x86 XP? Why not go with x64 XP?

XP is a special case where XP 64 is definitely better than XP 32, and is not because 32 v.s. 64, but because XP64 is another OS, just like Win8 and Win8.1 are not the same thing.

For the record that misunderstanding made, at the time, most user to think they absolutely needed a 64Bit OS (I was fooled as well).

In reality XP52 (Server 2003 x86 switched to XP) Is as good as XP 64, while being faster and lighter.

The same is applicable to all 32 v.s. 64 following Windows releases.

64 bit makes sense in few cases, heavy math, compression, multimedia transcoding (if done by the CPU) and alike.

There 64 bit matter, in anything else 64 bit means (roughly) 1.6x larger binaries, memory transfers, storage used and so on

Also a 32bit Windows OS can run 16 bit binaries natively, while 64bit does not (requires tricks or virtualization), which isn't a secondary detail for people interested in retrocomputing.

That said XP52/XP64/2003 aren't updated since 2013, while XP51 has updates available until 2019.

In short is a complicate choice.

Trashbytes wrote on Today, 10:47:

UCyborg wrote on Today, 09:46:

What's so special about x86 XP? Why not go with x64 XP?

Well XP64 has its own set of issues and compatibility quirks, so its really choose your poison and decide which set of quirks you want to deal with.

IIRC at one point with Win2003 SP2 nVidia drivers would BSOD shortly after startup due to "mismanaging system PTEs". This issue affected both x86 and x64 (including XPx64), and the workaround at that time was downgrade videoprt.sys with that of SP1.

And there was another thread about XPx64, that some games would not enable EAX unless you limit your RAM entirely to below 4GB boundary via /MAXMEM=4096 (you'll end up with less than 4GB available due to memory hole).

There were also a number of dumb SW that refused to start if didn't find the SP3, which does not exist in 5.2

Also the update to have the NLA support in RDP is available for 5.1 but not 5.2, the client part is solvable using the (manually unpacked) XP updates, but the server side i think there isn't a solution, not one I know.