Originally Posted by melgross
64 bit Windows does not run 32 bit apps directly. It runs them in a compatibility window. Most inefficient. There are other problems relating to this.
I remember that this was explicitly true of the Itanium editions of Windows, because the baseline Itamium processor wasn't directly capable of running any x86 code at all without software intervention or emulation.
Apparently when a 32-bit process coexists with 64-bit processes on an x64 edition Windows, the CPU is temporarily sent in and out of 32-bit compatibility mode so that the software doesn't need to know about any architectural differences. That necessarily involves a performance hit. But wouldn't something similar have to happen with 32-bit processes running on any other x64 operating system too?
I was under the impression that the biggest gotcha for most would-be 64-bit Windows users has been the availability of 64-bit kernel drivers for their hardware. A close second problem has been the incompatibility of 64-bit applications with 32-bit libraries and plug-ins, and vice-versa. (This latter limitation is technically true with Mac OS X as well, however Apple and most 3rd party software vendors have generally done a great job of preventing it from being visible to end-users.)
Originally Posted by bassoonx
I enjoyed the first and the second article on 64bit. But this one really confuses me!
1. How can Windows apps get several 4GB (-2GB for Kernel) virtual adress spaces? I thought without PAE, only one 4B adress space is possible.
Each process has its own virtual address space, each of which which may potentially grow to 4 GB. The MMU then keeps track of how each process's individual address space maps into the overall combination of physical RAM and pagefiles.
However, for most applications, the actual usage will be much smaller than that, and portions of each process's virtual address space which are not used, don't actually contribute to the system's total memory usage. Furthermore, the kernel's reserved space in each process is mapped into the identical space in physical memory.
Therefore, if you created two processes, each of which needed 0.5GB of application space, then each process would appear to be occupying 2.5GB of space (its own 0.5GB of space, plus the kernel's 2GB), for a total usage of 5 GB. However, the overall system memory usage would really only be 3GB (application 1's 0.5GB, plus application 2's 0.5GB, plus the single copy of the kernel's 2GB shared in common between the two). More savings are also possible if both applications make use of some common code from DLLs, because the system only needs to load the DLL into system memory once, and map that single copy into each process's virtual address. As well, it's likely that portions of the kernel's 2GB is actually unused.
Any process may potentially grow up to 4GB (minus the kernel's reserved space), provided the MMU has adequate resources (available system RAM plus pagefiles) available to accommodate it.