What is the maximum amount of memory any single process on Windows can address

Any process running under Windows gets a Virtual Address Space of 4 GB, no matter how much RAM is actually installed on the computer.
Actually, this is essentially the same for all operating systems running on 32 bit hardware that implement Virtual memory.
The only way to increase the size of the virtual address space beyond 4 GB is by using 64 bit hardware with an operating system and application built for that hardware.
In the normal, default Windows OS configuration, 2 GB of this address space are allocated to the process's private use and the other 2 GB are allocated to shared and operating system use.
The nub of it is, that no matter how much physical RAM is in the computer,the amount of memory available in the application's private part of thevirtual address space in 32 bit Windows implementations is limited to:
1. 2 GB - without the /3GB switch - this is the normal, default maximumprivate virtual address space or
2. 3GB with the /3GB switch AND a special application modification (more details below) or 3. any physical RAM not used by the OS and other applications by modifyingthe application to use the AWE (Address Windowing Extensions) API

More on address & memory allocation:
There seems to be a lot of confusion in the industry about what's commonly called the Windows “4GB memory limit.” When talking about performance tuning and server sizing, people are quick to mention the fact that an application on a 32-bit Windows system can only access 4GB of memory. But what exactly does this mean?
By definition, a 32-bit processor uses 32 bits to refer to the location of each byte of memory. 2^32 = 4.2 billion, which means a memory address that's 32 bits long can only refer to 4.2 billion unique locations (i.e. 4 GB).
In the 32-bit Windows world, each application has its own “virtual” 4GB memory space. (This means that each application functions as if it has a flat 4GB of memory, and the system's memory manager keeps track of memory mapping, which applications are using which memory, page file management, and so on.)
This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space.
This can cause problems in Terminal Server environments. On Terminal Servers with a lot of users running a lot of applications, quite a bit of information from all the users has to be crammed into the shared 2GB of kernel memory. In fact, this is why no Windows 2000-based Terminal Server can support more than about 200 users—the 2GB of kernel memory gets full—even if the server has 16GB of memory and eight 3GHz processors. This is simply an architectural limitation of 32-bit Windows.
Windows 2003 is a little bit better in that it allows you to more finely tune how the 2GB kernel memory space is used. However, you still can't escape the fact that the thousands of processes from hundreds of users will all have to share the common 2GB kernel space.
Using the /3GB (for Windows 2000) or the /4GT (for Windows 2003) boot.ini switches is even worse in Terminal Server environments because those switches change the partition between the application memory space and kernel memory space. These switches gives each application 3GB of memory, which in turn only leaves 1GB for the kernel—a disaster in Terminal Server environments!
People who are unfamiliar with the real meaning behind the 4GB Windows memory limit often point out that certain versions of Windows (such as Enterprise or Datacenter editions) can actually support more than 4GB of physical memory. However, adding more than 4GB of physical memory to a server still doesn't change the fact that it's a 32-bit processor accessing a 32-bit memory space. Even when more than 4GB of memory is present, each process still has the normal 2GB virtual address space, and the kernel address space is still 2GB, just as on a normal non-PAE system.
However, systems booted /PAE can support up to 64GB physical memory. A 32-bit process can "use" large amounts of memory via AWE (address windowing extension) functions. This means that they must map views of the physical memory they allocate into their 2GB virtual address space. Essentially, they can only use 2GB of memory at a time.