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 th...