The Address Windowing Extensions (AWE) is a feature of Windows that allows programs to allocate physical memory and map them on a page-by-page basis into a region of address space (the “address window”). PAE is the Physical Address Extension, which is a feature of the x86-32 CPU that allows a 32-bit processor to generate physical addresses larger than 32 bits, thereby allowing it to access more than 4GB of physical motherboard RAM.
Some time ago, I noted that AWE does not require PAE. The two features operate independently, but they are useful together.
If you use AWE without PAE, then your 32-bit Windows system can access only 4GB of onboard memory, so the feature of AWE that gives you access to lots of physical memory is of limited use: The system has only 4GB of memory to begin with, so that’s all that you can get. You wrote a lot of complex code for a high-RAM scenario when there isn’t really a lot of RAM available to take advantage of it.
It’s like getting a large teapot for making a single cup of tea: Your teapot has the capacity to hold a large amount of tea, but you’re going to put just one cup’s worth in it.
This is all largely historical information, since 64-bit processes running on 64-bit systems can allocate more than 4GB of memory and use it in the normal way. No special hoops necessary.
Note: One thing that AWE does give you is the ability to allocate physical non-pageable memory. Again, you can use this feature whether or not you have also enabled PAE.
Note 1: A 32-bit program that uses AWE will still run on a 64-bit system provided the 64-bit system uses the same page size as the 32-bit system. Looking at the table of page sizes used by Windows, it means that an x86-32 program (4KB page size) can run on an x86-64 system and an AArch64 system, but not an Itanium.
I know AWE represents the memory manager’s physical page frames I think or something close to that abstraction
Why is it considered deprecated for x64? It pins your frames and even though the immediate x86 problems disappeared it could be handy to ensure physical consistency, instead of page frames just flying around like mad (in a sophisticated way, but still)
In x64, AFAIK, it would only be useful for reserving non-pageable memory (which, in itself, is usually a bad idea unless you really know what you are doing!). If you can live with regular, pageable memory, it’s easier just to reserve a large enough block of memory. And in the case of non-pageable memory, there are probably other ways to achieve it. So you could say that in x64, AWE was “almost” useless (please note the quotes). Unless you need more than 16 HB (that is, Hexabytes) of memory, of course O:·) .
AWE reminds me a bit of memory mapping a view of a file, or maybe more of the EMS page frame from way back (especially with PAE) as that too involved a window into a larger address space.
It’s not exactly the same, AWE gets close to page frame allocation. It’s like physical allocation. The kernel manages a virtual-physical memory map. The virtual frames can stay resident while physical page frames can fly around.
Mmapping on this particular implementation just streams Io Into RAM. Theres nothing equivalent between them.
Well, that's quite close to what EMS did in software emulation mode, which is what 99% of people did use: it mapped into a window under the 1 MB limit pages from above it, so real mode programs could use more than 640 KB of RAM. It also did some memory management above the 1 MB limit, mostly keeping track which pages were allocated and which were free.
Of course, there were also physical EMS memory cards, but even in its day they were uncommon, and the arrival of 386-based PCs with more than 640 KB base RAM made them...
We have “Note:” and “Note 1:” but we skipped “Note 0:” in the pursuit of sharing knowledge.
Perhaps I see another (admittedly niche) use case of AWE without PAE: if you have 4GB of RAM and a GPU (or some other device) with, say, 2GB of RAM, AWE will let you use both to the fullest extent.
Without PAE, the TOTAL physical address space is limited to 4GB, so there is no way to simultaneously map 4GB of system RAM and 2GB of VRAM into it.
(No option to reply to 3rd-level comments)
In some cases, the chipset only supported a 32-bit physical address space, so everything was limited to a total of 4GB regardless of the CPU or OS. I witnessed this on a motherboard with a Pentium D CPU and Intel 945 chipset – I booted a FreeBSD-based OS and it reported <4GB of total memory.
In that era, there were a lot of PCs which showed exactly 3.25 GB of RAM. They were actually 4 GB machines running a 32-bit OS, and for whatever reason the motherboard reserved a 768 MB (=0.75 GB) window for memory mapped devices (of which, in almost all cases, there was only one: the graphics card). I don’t know it that window size was part of any specification, but I saw many computers with 3.25 GB of RAM, and I can’t remember of a single one with a different figure.
Huh. Ok, I didn’t know that. I presumed that they will both have separate mappings into the virtual address space.