wierd_w wrote on 2026-09-25, 16:52:
The LAA flag would allow a ramdisk to actually be 3gb in size. Many allowed you to overtly specify nonpaged pool as the source pool for the allocation. With PAE and LAA turned on, that will work as described. Not a good use, but not impossible.
To use 3gb RAM inside a process context, you need LAA, which if you didnt have PAE (and thus drivers and pals in a context that has virtual addresses free, LIKE THEY NEED), that could cause all manner of problems.
'Not seeing the ram' generally means you dont have PAE turned on / it's not supported...
Careful here youre mixing up **physical addressing** (PAE) with **virtual addressing** (LAA and the /3Gb switch). They operate at completely different layers of the memory manager
1. **PAE expands physical addressing, not virtual space**
On 32bit x86, virtual address space is fundamentally locked to 4 Gb 2³². PAE changes page tables from 2level (32bit) to 3level (36bit) so the CPU can point those 4 Gb virtual windows at a larger 64 Gb physical pool. It does not give drivers or processes more *virtual* address space.
2. **The /3Gb switch actually squeezes drivers, making crashes worse**
By default, the 4 Gb virtual space is split 2Gb User and 2Gb Kernel. When you enable the /3GbB switch in boot.ini so an LAA flagged .exe can address 3Gb of virtual memory, the kernel space is compressed from 2Gb down to just **1Gb**. This severely restricts the kernels System Page Table Entries and pool memory. Running /3Gb on 32bit XP was notorious for starving graphics and network drivers of virtual address space, which is why Microsoft later introduced the /USERVA switch to claw back 100–300 Mb for the kernel.
3. **You cant allocate a 3Gb RAM disk from the non paged pool**
On 32bit WinXP, the Non-Paged Pool has an absolute hard architectural cap of 256 Mb (and with /3Gb enabled, it often shrinks to 128Mb). If any RAM disk driver tried to allocate 3Gb out of the non-paged pool, the kernel would instantly bugcheck with 0x00000041 (MUST_SUCCEED_EMPTY_ALLOCATION) or 0x0000003F. The third party RAM disks that used the "invisible" RAM (like Gavotte) did not use OS pool allocations they used custom AWE drivers or mapped directly to \Device\PhysicalMemory to grab the physical frames above the BIOS MMIO hole that the XP HAL refused to manage.
4. **XP SP2 already had PAE enabled**
On any machine with an Athlon 64 or P4 with the NX/XD bit, XP SP2 enabled PAE automatically to enforce hardware DEP. The reason systems still only showed 3.25Gb wasnt because PAE was missing it was because the client HAL code in XP SP2 explicitly clamped physical memory mapping at 4.0 GB 0xFFFFFFFF, leaving the RAM overlapping the PCI MMIO hole completely unmapped.
The Solutor wrote on 2026-09-25, 17:08:
Gavotte Ramdisk is one of the few programs that can take advantage of the unused RAM in machines with PAE disabled, I dont think it has limits other than the unused ram size.
This is 100% backwards. Gavotte Ramdisk **strictly requires PAE to be enabled** to touch the unmanaged RAM above the 3.25 Gb/4Gb line. It is physically impossible for it to work with PAE disabled.
Here is the actual technical reality.
The 32bit hardware wall.
When PAE is disabled, the CPU runs in legacy 2level paging. Page Table Entries are strictly 32 bits wide. The highest address a 32bit pointer can express is 0xFFFFFFFF 4.0 Gb. The chipset remaps the RAM hidden by the MMIO hole *above* the 4 GB line starting at 0x1_0000_0000. If PAE is off, the CPUs MMU has no 36bit addressing capability those physical addresses are electrically unreachable by any driver or code on the machine.
How Gavotte actually accessed that memory.
Gavotte’s driver explicitly included a "UsePAE"=dword:00000001 registry flag. It worked because Windows XP SP2/SP3 already had PAE active under the hood for hardware DEP. While the XP HAL clamped the OS memory manager from handing out physical addresses above 4Gb, the CPU was still running in 3level PAE mode. Gavotte took advantage of this by bypassing the OS memory allocator and mapping those high physical frames directly using 36bit physical addresses.
If you actually disable PAE in boot.ini, Gavotte cannot touch that unmanaged RAM at all. It will either fail to initialize or allocate its disk space out of your visible 3.25Gb pool, reducing your usable system memory even further.
darry wrote on Yesterday, 12:59:
I feel quity similarly. In some ways, it feels like either the world (some people in it at least) is unintentionally"gaslighting" me or my memories actually are wrong about some rather significant things.
On the flip side, some people, including very vocals ones, seem to be unable to grasp and accept that the world has not stood still and that new approaches, a better understanding of how things work(ed) and the resulting new software tools (including patches), that are recent developments, actually make it possible to do things today with old hardware/software (or old software combined with new hardware) that appeared unfeasible or even impossible years or decades ago.
You summed it up perfectly, darry.
Most peoples mental model of XP was frozen in amber around 2005. Back then, standard consumer knowledge was whatever was printed on the back of the OEM box: "32bit = 4Gb ceiling, you need 64bit for more." Because that simple rule of thumb worked for 99% of home users, and so it hardened into dogma.
What gets lost is the distinction between **architectural capability** and **consumer defaults**
1. **The Architecture** The NT kernel and x86 CPUs were handling 36bit physical addressing 64Gb via PAE long before consumer multi gigabyte rigs were common.
2. **The Clamp** Microsoft clamped XP to 4Gb in the HAL specifically as a safety net against poorly written consumer DMA drivers once hardware DEP turned PAE on by default.
3. **Modern Retro Engineering** Todays community has disassembled the kernel, removed the licensing clamp, patched ACPI routing, and paired XP with modern UEFI CSM layers and modern memory controllers.
When people see 32bit XP running on a Ryzen with 64 GB of RAM, they call "fake" because they mistake Microsofts 2004 driver safety bumper for an unbendable law of computer science. Its wild seeing twenty years of reverse engineering dismissed simply because it contradicts a half remembered forum post from 2004!
Which is why the argument in this thread is so confusing to me. The 4Gb clamp applied to XP was a emergency operation by Microsoft to fix all the broken drivers, or more accurately to stop the broken drivers from crashing systems when they are used. Which might be hard to understand for most people because at the end of the day the devices with these "broken" drivers work, the drivers drive the devices right, so whats the problem?
Those broken drivesr became a problem after Microsoft had to enable PAE by default in XP SP2m to control the virus problem which was at epidemic proportions at the time.
Now its common, and infact usual for computers to sit behind a home router that blocks access to worms like MSBlast.exe, but back then as you may remember most people connected directly to the internet via a USB ADSL modem which didnt block worms like Blaster. So they had to enable PAE to use No Execute Bit.
Then once XP became retro and the PAE patch came up it was like magic... Late XP drivers with early XP RAM sizes but this time the RAM was plentyful... Driver problems are still there on the cheap slop of course but stick with the cherry picking of drivers as solutor said and you shouldnt have a problem.
Yes I know the situation now in the retro community is what it is given the hardware we have now and the patches we have now is what it is but thats not what Im talking about. What started the conversation is what it was like back then with RAM usage. How it was much lower back then compared to now and given the prices now we need to make a move back to that.
My "Ultimate XP" system is based on a i7-5775C, with a nvidia Titan Xp (Pascal) with 32Gb of system RAM. All of which is fully used by XP including the VRAM. So I know what can be done now. That isnt in dispute by me at all.
