Most of the responses to the question seem to be "sort of" correct but missing important parts of the overall picture. Further, a complete answer to the question is going to be subject to the operating system the given application is running under as the specifics are going to be heavily dependant on OS implementation.
I can't speak for Unix systems, but on the Windows side, it's complicated and messy:
PAE (Physical Address Extensions)
Client editions of Windows do not support PAE while server editions do. If you want to physically address more than 4GB of RAM you need PAE. Realistically, you're unlikely to be able to address even 4GB under non-PAE x86 due to reserved memory ranges from hardware taking a chunk.
Funfact 1: As for why PAE isn't supported on client editions, this isn't a licensing problem (you can buy x64 editions for the same price that have massively increased RAM limits), but rather, Microsoft playing it safe with driver compatibility. Apparently, during testing a non-trivial number of drivers were found that made assumptions that don't hold under PAE and thus broke horribly. Things like using the high bit of a 32-bit pointer for data storage. Rather than risk a tsunami of bluescreens caused by poorly written drivers (which people would blame MS for out of naivety) the decision was made to simply not support PAE on client editions. Server editions do as there's the reasonable expectation that servers should be running higher quality drivers.
Funfact 2: Technically, PAE is supported on client editions, as it's required for hardware DEP support, so it's more a hard limit on addressable physical memory than it is a lack of support for PAE itself.
AWE (Address Windowing Extensions)
This is a Windows-specific capability (unlike PAE, which is a hardware capability provided by modern CPUs) which allows a process to address more memory than it has virtual address space. Further, it works hand-in-hand with PAE as you by definition need PAE support in order for the OS to address memory higher than 4GB in the first place. However, in order to use AWE, the application has to be explicitly written to utilise it as the usage of AWE requires the application itself to take a far more active role in managing its memory. AWE support is indicated via a flag in the PE header of the application binary. Needless to say, a tiny minority of applications have this support. The only one I could name right now would be Microsoft's SQL Server.
4GT (4-Gigabyte Tuning)
This is one other Windows-specific capability that isn't really related to a discussion on 4GB limitations but inevitably will be raised regardless. While PAE provides for the OS to address more than 4GB of physical memory, and AWE provides for an application to address more memory than in its virtual address space, neither of these features increase the amount of addressable memory at any given time in an application (ie. AWE allows you to change your view of memory, but not address more than 2GB of memory simultaneously). A Windows process in 32-bit has a 2GB virtual address space, with the remaining 2GB mapped to the kernel address space. 4GT, in contrast to PAE and AWE does allow you to modify the address space available to a user-mode application. By providing the appropriate bootloader parameter you can modify the usermode/kernelmode split to skew it up to a maximum of 3GB/1GB user/kernel-mode respectively. This used to be done quite a lot on large Terminal Servers for example, or to optimise database servers, however, the ramifications of doing so need to be carefully understood. You are reducing the amount of memory available to the kernel, and so, memory hungry drivers may now fail to load, or worse, outright crash the system if they haven't been coded to properly handle low memory conditions.
EDIT: I forgot to mention, that like AWE, an application won't even use the increased address space 4GT provides unless it is marked as capable in its PE Header. Merely enabling the setting won't get you anything unless your application supports this capability. Firefox, as an example, is large address aware and being 32-bit, can thus address up to 3GB instead of 2GB. While on 32-bit systems this capability is not likely used (how many 32-bit Windows users have modified their bootloader parameters to support 4GT?) it is fully used on 64-bit Windows and can use the full 3GB address space out of the box. And god knows Firefox needs it...
In summary, in the age of x64, I tend to view all of the above as far more trouble than it's worth. The virtual address space of a Windows 64-bit process is currently 8TB. Windows 7 Professional and up give you 192GB of physical memory, while Windows Server 2008 R2 Enterprise and up give you up to 2TB. So if at all possible, avoid 32-bit, 64-bit is the solution; PAE, AWE & 4GT were only ever workarounds.
If any of the above is incorrect, please correct me, as it's been a while since I studied much of the above, and if anyone can shed more light on the Unix situation, I'd be interested (in a very nerdy way).
> Client editions of Windows do not support PAE while server editions do.
That is not correct, client editions fully support PAE.
> As for why PAE isn't supported on client editions
It is supported (and enabled), the limits are implemented separately and independently.
> this isn't a licensing problem (you can buy x64 editions for the same price that have massively increased RAM limits)
Windows 7 Home Basic x64 will only make 8GB RAM available, Premium will restrict to 16GB, professional and up will allow up to 192GB. Meanwhile Server 2008 R2 Enterprise and Datacenter allow 2TB. These are very much licensing restrictions, as is Windows 7 Starter (x86)'s 2GB limit.
> but rather, Microsoft playing it safe with driver compatibility.
That is the excuse they give for it, yes. It just happens to make no sense when applied to the x64 limits I quoted above, to Starter's 2GB limit (and Vista Starter's even lower 1GB) or to e.g. Windows Server 2008 R2 Foundation's 8GB limit (2008 R2 only runs on x64 and Itanium so 32b isn't even remotely a factor)
> so it's more a hard limit on addressable physical memory
It's not "hard", since it's merely based on the licensing mode of the kernel. It can even be hacked out.
I can't speak for Unix systems, but on the Windows side, it's complicated and messy:
PAE (Physical Address Extensions)
Client editions of Windows do not support PAE while server editions do. If you want to physically address more than 4GB of RAM you need PAE. Realistically, you're unlikely to be able to address even 4GB under non-PAE x86 due to reserved memory ranges from hardware taking a chunk.
Funfact 1: As for why PAE isn't supported on client editions, this isn't a licensing problem (you can buy x64 editions for the same price that have massively increased RAM limits), but rather, Microsoft playing it safe with driver compatibility. Apparently, during testing a non-trivial number of drivers were found that made assumptions that don't hold under PAE and thus broke horribly. Things like using the high bit of a 32-bit pointer for data storage. Rather than risk a tsunami of bluescreens caused by poorly written drivers (which people would blame MS for out of naivety) the decision was made to simply not support PAE on client editions. Server editions do as there's the reasonable expectation that servers should be running higher quality drivers.
Funfact 2: Technically, PAE is supported on client editions, as it's required for hardware DEP support, so it's more a hard limit on addressable physical memory than it is a lack of support for PAE itself.
AWE (Address Windowing Extensions)
This is a Windows-specific capability (unlike PAE, which is a hardware capability provided by modern CPUs) which allows a process to address more memory than it has virtual address space. Further, it works hand-in-hand with PAE as you by definition need PAE support in order for the OS to address memory higher than 4GB in the first place. However, in order to use AWE, the application has to be explicitly written to utilise it as the usage of AWE requires the application itself to take a far more active role in managing its memory. AWE support is indicated via a flag in the PE header of the application binary. Needless to say, a tiny minority of applications have this support. The only one I could name right now would be Microsoft's SQL Server.
4GT (4-Gigabyte Tuning)
This is one other Windows-specific capability that isn't really related to a discussion on 4GB limitations but inevitably will be raised regardless. While PAE provides for the OS to address more than 4GB of physical memory, and AWE provides for an application to address more memory than in its virtual address space, neither of these features increase the amount of addressable memory at any given time in an application (ie. AWE allows you to change your view of memory, but not address more than 2GB of memory simultaneously). A Windows process in 32-bit has a 2GB virtual address space, with the remaining 2GB mapped to the kernel address space. 4GT, in contrast to PAE and AWE does allow you to modify the address space available to a user-mode application. By providing the appropriate bootloader parameter you can modify the usermode/kernelmode split to skew it up to a maximum of 3GB/1GB user/kernel-mode respectively. This used to be done quite a lot on large Terminal Servers for example, or to optimise database servers, however, the ramifications of doing so need to be carefully understood. You are reducing the amount of memory available to the kernel, and so, memory hungry drivers may now fail to load, or worse, outright crash the system if they haven't been coded to properly handle low memory conditions.
EDIT: I forgot to mention, that like AWE, an application won't even use the increased address space 4GT provides unless it is marked as capable in its PE Header. Merely enabling the setting won't get you anything unless your application supports this capability. Firefox, as an example, is large address aware and being 32-bit, can thus address up to 3GB instead of 2GB. While on 32-bit systems this capability is not likely used (how many 32-bit Windows users have modified their bootloader parameters to support 4GT?) it is fully used on 64-bit Windows and can use the full 3GB address space out of the box. And god knows Firefox needs it...
In summary, in the age of x64, I tend to view all of the above as far more trouble than it's worth. The virtual address space of a Windows 64-bit process is currently 8TB. Windows 7 Professional and up give you 192GB of physical memory, while Windows Server 2008 R2 Enterprise and up give you up to 2TB. So if at all possible, avoid 32-bit, 64-bit is the solution; PAE, AWE & 4GT were only ever workarounds.
If any of the above is incorrect, please correct me, as it's been a while since I studied much of the above, and if anyone can shed more light on the Unix situation, I'd be interested (in a very nerdy way).