As so much existing software is 32bit only, is it fair to assume that these, and the things that new software will still need to do that way, will reside in the lower 4GB window for 32bit addressing? Or have I been out long enough to not well understand today the 2GB limitation of certain things, and thus things are limited to the lowest 2GB range?
I would imagine that this all means that the old 32bit only software, the OS things they need to hook into, and hardware space like PCI, southbridge things, Xmos etc. would be addressed inside the lower window.
Then newer software will refer to that window for OS and hardware addressing if needed, but then can otherwise go where it pleases in 64bit space, subject to memory allocation availability.
But, while things may need to address into library function calls and all that down in 32bit window, can the actual OS libraries themselves begin to go 64bit with these EMOs, and thus while we must enter them in 32bit space, then the libraries could immediately jump to some 64bit EMO location, and thus begin moving OS library code outside of that window, if it would make sense to do so, and thus free up more of that window for legacy 32bit software to live in? It seems like that would be a goal now, to move as much as possible above the 32bit window, when running on a 64bit machine with enough RAM to do that.
Aside from those thoughts, how does new software address compatibility with 32bit only motherboards? It would be nice to still be able to code in such a way that w ecan compile onto XE, Pegasos, Sam* etc. boards, and maybe Classic accelerators if we're still that crazy.
(I am) So if we're on a 32bot platform, when we request an EMO, are we now provided with that, but it just happens to be down in that usual 32bit window space for these boards, and for 64bit boards then it might tor might not be above that, so no new coding needs to jump through special #ifdef this or #else that every time memory is allocated?
