Peter it's a little bit difficult to me to explain, cause english is not my native language but i 'll try.
It is nice that you make expiriments with memory, as your program, use it in a way that performance is very critical.
It 's impossible to me to answer to the above comments, because we 'll get lost in details.
You can't just look in the task manager properties, to see what the memory management of windows have done with memory, because you see just numbers, but you don't know from where (which application) this data comes.
It is more easy for me to explain, how the os acts, when an application requires memory from the system.
All this conversation is important, if we use a 32 bit os (it doens't matter which one). At 64bit we don't have remarkable limitations (we have but, the limitations come from hardware).
Let' s take the following example, that we have a system with 32 bit processor and 4gb of physical memory. I use this example, cause it contains all the others circumstances like 2gb etc...
A 32-bit processor uses 32 bits, to refer to the location of each byte of memory. This means 2^32, about 4.2 billion unique locations. Let's say 4 GB. Those are all the possible addresses of memory, that the cpu can use. So above this number the cpu just can't see those locations and can't use them.
Let's go now to the OS side, in the above example.
It is built in a way, that every single application that request memory, has it's own VIRTUAL 3gb memory space.
This means, that every application acts like there is ALWAYS* 3 gb of (VM) memory to occupy, independently from the fact that for sure this space doesn't exist in physical memory. So this application starts to PAGE it's data, in a continious virtual space, until it get's all the data to that space.
*The only limitation to this come from the OS, which have the "central'' management of memory and can stop this procedure, (paging) if the application allocates so much space. OS manages all applications paging procedure, in a way that the available PHYSICAL memory & the SWAP file doesn't run out of space.
This can happen, when the os prefetching the most used programms OR when an application requires much space in physical memory like xxengine process.
The 4 gb of our example are devided by the os, to 2gb kernel mode space (os kernel, bios, shadow memory, agp aperure size, etc...) and 2 gb for ALL applications space. (this can be changed with some tricks to 1/3).
As i said to another post this virtual memory is a mix of space in physical memory and hard disk. If an application requests the vm data,
then a procedure take place and this addresses are translated to physical memory addresses, so that the application CAN USE them.
While this data are not translated into physical address space, only OS knows about them and no application can use them.
So for this translation if we have the swap file disabled, this operation takes much shorter because the hard disk doesn't participate.
This is the benefit.
So if a process from one application that is not in use , allocates about 1gb in virtual memory and you start a 1,8gb wav (1+1,8=2,8 that is bigger than 2gb max for apps) the os will translate, this 1,8gb to physical memory and at the some time it will release the data of the old application so that this 1,8 will fit.For sure this requires cpu assistance and will create clicks and pops.
On the above paragraph i said that 2gb can be translated in the best case, because in 32 bit windows this physical space of memory is the maximum that all the applications (user mode) can allocate.
I hope that the above are clear to understand because it is not so easy to explain.
PS: You will never come up with critical errors for OS, because when the physical memory running low, the operating system will release some space for the process that need this space. Don't forget that kernel modules will always have availiable memory in the 2gb kernel space.