This thread has provided a number of learning moments for moi.

>>>The bigger 32 bit versions of Windows....address more than 4gb of RAM <<<

I think this provides a bit more insight: http://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspx

"""  Physical Address Extension (PAE) is a processor feature that enables x86 processors to access more than 4 GB of physical memory on capable versions of Windows.

PAE does not change the amount of virtual address space available to a process. Each PROCESS running in 32-bit Windows is still limited to a 4 GB virtual address space. """

Some more info: http://superuser.com/questions/52275/help-enabling-pae-on-windows-7-32-bit

And this is interesting:
http://www.unawave.de/windows-7-tipps/32-bit-ram-barrier.html?lang=EN

We live in a time of magic and miracles. Be amazed, be very amazed.

J

jm24

PAE does not change the amount of virtual address space available to a process. Each PROCESS running in 32-bit Windows is still limited to a 4 GB virtual address space. """

But remember Sonar 32 and all the plug in running in it act as a single 32 bit process. Even if you get this working you are not buying your self that much extra memory. You will be in the identical position as you would be running 32 bit Sonar on a 64 bit OS.
 
Its probably easier to run a 64 bit OS and install both 64 and 32 bit versions of Sonar. There are only a small handful of plugins that refuse to be bridged if you add JBridge, But if you have a few that won't bridge or you are depending on 32 bit DX plugins you can use the 32 bit version of Sonar.

Then again, how does 32bit windows address other memory in the system; CPU cache, L1 &L2, Harddrive cache, pagefile and the ramdisk also being discussed. I suppose if this is so, a 32bit XP can only use a total of 4GB of any kind of memory at once, then some type of off loading has to take place, thus slowing down the system especially when a big application demands it.

The CPU cache is totally separate from main memory. It has its own address bus, its own data bus, and does not take any address space away from main memory. However, many other devices do map into the main address space, even if they do not physically occupy main memory. A memory address can be used, for example, to send commands to a controller. The controller doesn't actually use any of the main RAM, but the memory address is spoken for and cannot be used for anything else. The controller could in fact have any amount of RAM on board and it would not subtract any capacity from the system unless it was designed that way. Of course, placing a 4GB video card into the main memory's address space would indeed make the entire system unusable under 32-but Windows. But fortunately they don't work that way - only a small subset of the video adapter's memory is mapped to the system memory.

well, from what I can see when i open the task bar while mixing in sonar, as i add more plugin's (waves, urs, sonitus) i see the ram usage of sonar's process go up, so i doubt there are seperate processes for plugin's so that means that if windows only addresses 2gb per process or application, even if i was able to let windows see more than 4gb id still be stuck right?

Correct. Plugins normally run within the address space of the host. The exceptions are when you use BitBridge, Jbridge, Rewire or hardware coprocessors such as a UAD-2 or PowerCore.

I guess it would be possible to map the system page file to a ram disk. Would that be advantageous? (If so, I would think that would be common practice.)

That would indeed be pretty cool, if it worked. But given that the page file is the overflow area for when you've run out of RAM, it would be counterproductive to move it into said RAM.

Ramdisks were useful back in the day when hard drives were small and slow, and when floppies were often part of the picture. Today, I cannot think of a single good use for them.