The nonsensical 32-bits
I must make note of this, however unlikely, in the case that I might stupidly put more than 4GB of memory into a 32-bit version of windows. An interesting issue at work arose where a 32-bit server with 8GB of memory was reporting 'out of memory' errors in applications even when there was at least 5GB of remaining free memory. As it turns out, even if you put in that much memory, applications are, by default, only allowed to make use of a combined 2GB of memory without tweaking boot options.
While we have yet to test a solution to this problem, I didn't want to lose track of these important gems in the sand-pit that is MSDN.
1. Kernel address space consequences of the /3GB switch.
2. Driver may not be loaded with the /3GB switch (Also talks of the /USERVA switch).
3. How PAE x86 Works. Especially make note of "Application Windowing Extensions (AWE)" in this article.
The current theory is that we can adjust the system to allocate more than the standard 2GB of application address space by using these special kernel switches. This is yet to be confirmed, but seems plausible. The major concern is how much the allocation can expand. This could mean we still limited to a maximum of 4GB total combined application and kernel space, meaning that any more than 4GB in a 32-bit Windows computer becomes totally useless. These documents all appear to imagine that the computer user is setting up a system with 4GB of memory and the technical aspects are worded as if the 4GB limit was the only thing of concern, nothing more. I'd be curious to know if I were to set the /3GB flag and one of /USERVA=6000 (6GB addressing space, leaving 3GB for kernel) if the system would still operate.
While we have yet to test a solution to this problem, I didn't want to lose track of these important gems in the sand-pit that is MSDN.
1. Kernel address space consequences of the /3GB switch.
2. Driver may not be loaded with the /3GB switch (Also talks of the /USERVA switch).
3. How PAE x86 Works. Especially make note of "Application Windowing Extensions (AWE)" in this article.
The current theory is that we can adjust the system to allocate more than the standard 2GB of application address space by using these special kernel switches. This is yet to be confirmed, but seems plausible. The major concern is how much the allocation can expand. This could mean we still limited to a maximum of 4GB total combined application and kernel space, meaning that any more than 4GB in a 32-bit Windows computer becomes totally useless. These documents all appear to imagine that the computer user is setting up a system with 4GB of memory and the technical aspects are worded as if the 4GB limit was the only thing of concern, nothing more. I'd be curious to know if I were to set the /3GB flag and one of /USERVA=6000 (6GB addressing space, leaving 3GB for kernel) if the system would still operate.