Windows x86 can use up to 3.5GB of RAM directly. The area above (up to 4GB) is used by PCI devices and for the linear framebuffers of graphics cards.

It's similar to the upper memory area (UMA) between 640K and 1MB on old DOS PCs.
Another place is the region between 15-16MB on 286 machines, as this place marks the end of ISA address space.
Some 16Bit ISA graphics cards use this for their linear framebuffers. Some older BIOS even have an option for this region ("memory hole at 15-16MB").

Some server versions of Windows x86 do also support a bit more than 4GB of memory.
This is possible since the Pentium Pro, which introduced an 36bit address bus.

But even these special editions have to use tricks to use more memory, because 32bit device drivers still use the region above 3.5GB.
Do do so, they use techniques similar to Expanded Memory (EMS) from the old DOS times.

But I'm speaking under correction. I'm not a server person, maybe something isn't correct what I said.

Well, one explanation is that it doesn't try to map all VRAM into the 4 GB address range (it doesn't need nearly that much to use it as a desktop, and it can be remapped dynamically with an EMS-like paging system to use all memory for graphics).

Another explanation could be in this:
Modern versions of 32-bit Windows can make use of the Physical Address Extension (PAE) introduced in the Pentium Pro: https://en.wikipedia.org/wiki/Physical_Address_Extension
So you aren't actually limited to a 32-bit address space, you have a 36-bit address space.
While 32-bit OSes are technically limiting the system to 4 GB for compatibility (drivers and certain apps tended to crash because they were never designed to operate with more than 4 GB physical address space), perhaps they aren't limiting some of the OS internals, so it might be doing some kind of virtual memory trick there.

KT7AGuy wrote:

In the future, I'm planning on someday building a WinXP box with a GTX 750 Ti. I was under the impression that the 2gb cards would limit my system memory to 2gb, so I was thinking I would need to buy one of the gimped 1gb Zotac models. Perhaps this is not really the case?

I understood that the amount of RAM on a video card (aside from onboard video cards) is generally irrelevant to the amount of RAM accessible to the operating system. After all, the operating system cannot address the video card RAM directly, right? Such a limitation would also imply that a 2 GB card in a system with less than 2 GB of RAM would somehow be completely unbootable.

As per the Wikiperdia article that Scali referred to, the 4 GB limit on Microsoft's 32-bit operating systems is actually a hard limit imposed by Microsoft.
As a matter of fact, up to Windows XP SP1, there was no limit and one could actually install Windows XP (32-bit) on a PC with more than 4 GB of RAM and the OS would be able to address all the memory (of course, back in 2002, anything above 2 GB of RAM on a desktop PC was very uncommon).

Provided you have a CPU and chipset that supports PAE, it is possible for a 32-bit operating system to address up to 64 GB of RAM.
However, in order to remove the hard limit on a 32-bit Windows OS (like Vista, 7, etc.) you need to "patch" the kernel (there are utilities online that allows you to that, and I found one online that works great for me - it even allows me to "dual boot" between the patched and non patched kernel).

I currently have 4 GB of RAM installed in my PC on which I'm running Windows 7 (32-bit).
Like KT7AGuy, my PC is also only able to access a maximum of 3.25 GB of RAM.
However, after patching my kernel, I was then able to address the full 4 GB of RAM.

Most of my applications runs fine with the patched kernel. However, I have one DVD writer utility that refuses to work properly if I boot up with the patched kernel.
Despite the above "workaround", my own opinion is that, if you have more than 4 GB of RAM on your PC, then rather install a 64-bit edition of Windows.

Jorpho wrote:

After all, the operating system cannot address the video card RAM directly, right?

It can, but generally you only need to map one framebuffer, texture, or whatever else into the address space at a time.
DirectDraw does exactly that, by the way. You can get a pointer directly to a part of videomemory, even the frontbuffer, and draw on it. Pretty much the same as how CGA/EGA/VGA work in DOS.

the width of the mapping window is to be subtracted from total address space, not memory space; mostly cards will directly map 128-768 mb only, one just doesnt need more, also this is on some systems kinda wasteful; bigger window->less window panning, but then in many scenarios a 64mb window would suffice anyway and in the given example you could prolly have some 3,7-3,8 gb accessible space; also im not entirely sure that except for pae there is anything that saves that mapped region for us to use as system memory, i believe its rightfully lost due to rigid driver code for example;

jesolo wrote:

Provided you have a CPU and chipset that supports PAE, it is possible for a 32-bit operating system to address up to 64 GB of RAM.
However, in order to remove the hard limit on a 32-bit Windows OS (like Vista, 7, etc.) you need to "patch" the kernel (there are utilities online that allows you to that, and I found one online that works great for me - it even allows me to "dual boot" between the patched and non patched kernel).

The patch is only required for consumer OSes.
The server/workstation/enterprise OSes had stricter driver qualification requirements, and as such, drivers for these OSes are also required to work with the full 64 GB of address space. So these OSes also don't have the strict 4 GB limit. As you can see, 2000 Advanced Server had a limit of 8 GB, and the Server Enterprise/Datacenter editions can do the full 64 GB.

32 bit OSes can support 2^32 (4GB) system RAM. As others have mentioned, Microsoft reserves that .75GB in their OSes for other things. I know in the linux world, Physical Address Extensions (PAE) have been used for years to let a 32-bit OS use as much memory as you put in (I believe it's up to 64GB, but I think it's up to the kernel being used). I've also read that 32-bit Windows OSes *do* support PAE, but for some reason they are still limited. I think it's an intentional limitation by MS to "encourage" users to upgrade to 64-bit OSes. Interestingly, MS removes this limitation on their server OSes (I think Windows Server 2003 was the last version to have a 32-bit version, so that's the last OS that is relevant to this discussion).

This article describes a way to patch the Windows kernel to bypass this limitation. I've never tried it and I'm not entirely comfortable trying it on a Windows OS, but if you feel like trying you can knock yourself out. 😀

Scali wrote:

jesolo wrote:

Provided you have a CPU and chipset that supports PAE, it is possible for a 32-bit operating system to address up to 64 GB of RAM.
However, in order to remove the hard limit on a 32-bit Windows OS (like Vista, 7, etc.) you need to "patch" the kernel (there are utilities online that allows you to that, and I found one online that works great for me - it even allows me to "dual boot" between the patched and non patched kernel).

The patch is only required for consumer OSes.
The server/workstation/enterprise OSes had stricter driver qualification requirements, and as such, drivers for these OSes are also required to work with the full 64 GB of address space. So these OSes also don't have the strict 4 GB limit. As you can see, 2000 Advanced Server had a limit of 8 GB, and the Server Enterprise/Datacenter editions can do the full 64 GB.

Correct, I should have stated that I was specfically referring to the consumer OSes

clueless1 wrote:

32 bit OSes can support 2^32 (4GB) system RAM. As others have mentioned, Microsoft reserves that .75GB in their OSes for other things. I know in the linux world, Physical Address Extensions (PAE) have been used for years to let a 32-bit OS use as much memory as you put in (I believe it's up to 64GB, but I think it's up to the kernel being used). I've also read that 32-bit Windows OSes *do* support PAE, but for some reason they are still limited. I think it's an intentional limitation by MS to "encourage" users to upgrade to 64-bit OSes. Interestingly, MS removes this limitation on their server OSes (I think Windows Server 2003 was the last version to have a 32-bit version, so that's the last OS that is relevant to this discussion).

This article describes a way to patch the Windows kernel to bypass this limitation. I've never tried it and I'm not entirely comfortable trying it on a Windows OS, but if you feel like trying you can knock yourself out. 😀

I've done it and there is no major risk, since you can easily fall back to your original kernel, should something not work properly,
Here's a link to the utility that I used (it's called PatchPae2): https://wj32.org/wp/

As an interesting aside... in a PAE-enabled 32-bit OS, it is possible for each process to get an address space of considerably more than 2 GB. There is a special 'LARGE' flag in the PE header of the executable that can be set to allow the OS to do this.
64-bit OSes make use of this feature, allowing them to map a full 4 GB virtual address space to each process (since you have a 64-bit address space anyway, you can map kernel, hardware, drivers and other stuff well outside this 4 GB-region, so it doesn't take away any address space from the application at all).

My 2 cents :
1) Win XP/7 x86 can use up to 3,5GB of RAM without any patches.
2) A PCI-e GPU will map all of it's VRAM to 256MB physical adress space (at least I did not encounter a GPU that does less/more with PCI-e slot).
VRAM capacity is irrelevant (due to Virtual Adresses) : LINK.
3GB VRAM + 4GB RAM in Win XP x86 and it's Task Maneger shows "3668764kB" as usable RAM capacity (under "Pamięć Fizyczna" field).
I know, it must be "Black Magic" to some people when 3GB VRAM + 4GB RAM = ~6,5GB usable in total with Win XP 32-bit (no PAE patches) 😉
3) "Usable RAM" is highly dependant on hardware and BIOS configuration of PC.
Memory Hole/Memory Remap will help in adressing over 3GB+ mark with x86 Win OS'es.
Additional controllers/cards on the other hand, may add to memory reserved adress pool, because they simply need those adresses to work properly.
BIOS assignes adress space (most of the time) and if it get's it "wrong", user will lose some of the usable adress space in OS.

Little sidenote here - 32-bit only CPU (ie. without 64-bit support), can adress up to 3583MB (or ~3,5GB) of RAM, check attachments to this post for proof 😀 (again - without any kernel patches).

It's worth mentioning that PAE isn't a panacea that invalidates the need for a proper 64-bit OS that runs the CPU in long mode.

Applications need to be PAE-aware to have a commit size larger than 4GB, and this is typically only infrastructure type software like an RDBMS.

SquallStrife wrote:

It's worth mentioning that PAE isn't a panacea that invalidates the need for a proper 64-bit OS that runs the CPU in long mode.

Applications need to be PAE-aware to have a commit size larger than 4GB, and this is typically only infrastructure type software like an RDBMS.

Yes, PAE works somewhat like the 16-bit segmented model, except now your 'segments' are 4 GB each.
So you need to do complex pointer arithmetic to get beyond 4 GB. This is also slower than the native 64-bit pointers of course.
Then again, at the time (we're talking 1995) PAE filled a need for x86-based systems, before a 64-bit architecture was available.

my XP SP3 install shows 2.99GB on system properties, 3136124KB physical on task manager
out of 8GB and with a 1GB Radeon

but also I have a 4GB ramdisk running with the pagefile

I never really bothered looking into it, because I know the OS have this artificial restrictions, so I just use a x64 Windows if I need more ram

SquallStrife wrote:

It's worth mentioning that PAE isn't a panacea that invalidates the need for a proper 64-bit OS that runs the CPU in long mode.

Applications need to be PAE-aware to have a commit size larger than 4GB, and this is typically only infrastructure type software like an RDBMS.

But you can run multiple Processes using each 2 or 4Gb ?

matze79 wrote:

But you can run multiple Processes using each 2 or 4Gb ?

Yes, that is possible. Each process can have 2 GB (standard) or up to 4 GB (LARGEADDRESSAWARE) address space, just like in a 64-bit OS.

Scali wrote:

Yes, PAE works somewhat like the 16-bit segmented model, except now your 'segments' are 4 GB each.
So you need to do complex pointer arithmetic to get beyond 4 GB. This is also slower than the native 64-bit pointers of course.
Then again, at the time (we're talking 1995) PAE filled a need for x86-based systems, before a 64-bit architecture was available.

64 bit architectures existed. They were called DEC Alpha, Sun Ultrasparc, SGI MIPS, and IBM POWER.

gdjacobs wrote:

64 bit architectures existed. They were called DEC Alpha, Sun Ultrasparc, SGI MIPS, and IBM POWER.

Yes, obviously, but I specifically said "x86-based systems".