Given a 64bit systems running 32bit code, shouldnt all 32bit applications neccesarily use the same 4GB of RAM?

Question

ASSUMING x86-64 ARCHITECTURE, RAM > 4GB, AND 64bit WINDOWS 10

Given that any memory location used by a 32bit compatible application can only address memory locations within the first 4GB of RAM(4 byte addresses), wouldnt that mean that every 32bit application would need to run on the same 4GB of RAM in a 64bit system with more than 4GB of RAM. If there is some scheme to make it so the same 32bit memory locations map to different 64bit memory locations to allow for more than 4GB of RAM usage by the collective 32bit applications(i.e mapping the different sections of RAM for the 4GB of addressable memory in each 32bit application, such that with 8GB of total RAM for example, one application occupies the first 4GB and the other the next 4GB-mapping the 32bit addresses to different sections in the 8GB), how would 32bit applications communicate with each other under such scheme(given equivalent addresses could point to different memory locations)?

Simply: How can 32bit code use more than 4GB of memory in a 64bit computer, and wouldnt all 32bit applications have to share the first 4GB of memory?

Answer 1

If there is some scheme to make it so the same 32bit memory locations map to different 64bit memory locations to allow for more than 4GB of RAM usage by the collective 32bit applications

That's exactly what happens, yes.

how would 32bit applications communicate with each other under such scheme

Not through pointers, obviously. Try writing two 32-bit applications under a 32bit OS, allocating memory in one and trying to read it from the other, and as soon as you try to dereference the pointer in the other application you'll crash with access violation.

In a protected mode OS, each application only has access to the pages it mapped under its own process, and so the fact that each application sees a different view of the 64-bit address space with their own 32-bit address doesn't change anything, they still don't have access to another process' memory.

If you're actually asking for IPC methods (ie, ways to communicate across processes), they are widely varied and OS-dependent, anywhere from shared memory (named memory mapped files backed by your page file), sockets, named pipes, named mailslots, named mutexes (if you're sharing synchronization), shared disk files, windowing messages, etc.

Answer 2

Virtual memory solves the problem of letting multiple identical address spaces map to different physical memory.

32-bit processes use 32-bit virtual addresses, but the OS still uses 64-bit page tables that map those virtual addresses to anywhere in 52-bit physical address space.

(Real CPUs typically have a smaller physical address space than that, but it's the same size regardless of which sub-mode of long mode they're in. See Why in 64bit the virtual address are 4 bits short (48bit long) compared with the physical address (52 bit long)? for more, and a diagram of the x86-64 page table format)

The page tables are still 4-level, I think, zero-extending 32-bit addresses to 64-bit. (The same top-level page directory is used by the 64-bit kernel after an interrupt or a sysenter instruction, so it wouldn't work to have 32-bit processes use fewer levels of page tables. But all their addresses have the same high 16 bits, so the page-walk hardware can easily cache the top-level PDE and one of four entries in the level below that.)