Windows CE 5.0: Virtual Memory Consideration

Windows CE is a 32-bit OS so we can address 4 GB (0x0000.0000 to 0xFFFF.FFFF) of virtual memory. The Windows CE 5.0 Virtual Memory Map looks as follows:

• The upper 2 GB is kernel space


• The lower 2 GB is user space which is separated into 34 slots of 32 MB each for application execution and shared memory. In slot 0 resides a pointer to the currently executed application, slot 1 is used for shared user DLLs (called XIP = execution in place) so that those DLLs do not need to be loaded into each process space again. Slot 2 to slot 34 can be used to load applications. So you can run up to 32 applications with 32 MB of virtual memory each.

Now I want to focus on slot 0. Each DLL that is loaded into your system that is NOT an XIP DLL (those are in slot 1) will be loaded into slot 0 from top down. This is also true for DLLs that your currently running process has NO access rights for: if your process were to load an additional DLL it will be placed below the already loaded DLLs regardless of whether or not your process has access rights to them. This is to prevent your process from overwriting any preloaded DLLs. So you see in order to ensure that your process is capable of loading DLLs, it is necessary to reserve the space where preloaded DLLs reside even though your process might not have access rights to all of them. This of course reduces your 32 MB of virtual memory process space. This problem is known as the congestion of slot 0. To make things worse each DLL will be loaded 64 KB aligned and therefore decrease virtual memory even further due to fragmentation.


So, what can we do to solve this problem? Well the easiest way would be to move all DLLs to the XIP slot which can only be done in the image namely by placing them in the MODULES section in the corresponding .bib file.
But what if we do not have the sources for the image? How now brown cow??
Well in this case we have really got a problem and we have to bite the bullet one way or another:

• We could at least create one large DLL rather then a lot of small DLLs to avoid fragmentation. The downside of this solution is that applications that do not need the functionality still have the virtual memory reduction.


• Or we could build a LIB rather than a DLL and link that LIB to each application that needs the functionality. As you probably guessed, there is also a downside to this solution namely that you will need the extra physical memory for each application that links to the here created LIB. Of course applications that do need the functionality exported in the LIB still need the virtual memory as well but this time in there process code which is loaded from bottom up.

So you see either way you are not in the clear here; quite the conundrum!

Have fun!