I just returned from the Microsoft TechEd conference in Orlando. While there, I gave two talks and presented a Preconference tutorial. During the preconference tutorial, I discussed changes to the Windows Mobile 6.1 memory model. Here is a short summary of the changes.
Despite the implication of the “6.x” version number, Windows Mobile 6.1, like Windows Mobile 6 and Windows Mobile 5 are based on a modified Windows CE 5.0 kernel, not the newer Windows Embedded CE 6 kernel. The “old” kernel uses the slot based model for memory management shown in the figure below.
Processes are assigned a “slot” from 2 to 32 allowing up to 31 processes. (The kernel is counted as the 32nd process.) The process with the currently running thread is cloned into slot 0. This allows each application to act as if it is running in slot 0 since when a thread in a process is running that process is in slot 0. Slot 1 is used to load DLLs that have been bundled with the system. Slot 63, at the top of the Large Memory Area, is used to store resource only DLLs, those DLLs that have no code, only resource data such as fonts and strings. More detail on this memory model, and the problems associated with it can be found in a white paper I wrote a while back titled Windows CE Advanced Memory Management. (For those interested in Windows Embedded CE 6, I wrote paper on CE 6 memory management here.)
The problem with memory in Windows Mobile has always been the vast number of DLLs in the system. DLLs are loaded from the top of slot 1 down. Since there are so many DLLs in the system, not only do they fill up slot 1, they encroach into slot 0. This leaves only about 18-20 Meg of virtual space for each application. This problem is most acute in the Device Manager process space where dozens of device drivers, each with their own interrupt service thread, tended to consume most of the virtual space in that process.
This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.
In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks.
In addition to the stack move, changes were also made in where DLLs are placed. While execute-in-place(XIP) DLLs are still loaded from the top of Slot 1, any DLL that is larger than 64 KB and isn’t XIP is loaded in slot 60. If the 32 MB of slot 60 fills up with DLLs, the OS uses slot 61 for the DLLs. This additional 64 MB of DLLs space should go a long way in reducing the problem of too many DLLs in Windows Mobile systems. The new memory map now looks like this:
The shared heap slot was added in Windows CE/Windows Mobile 5 but its addition wasn’t an attempt to solve the DLL problems with Windows Mobile. While in this diagram it looks like the large memory area has been shrunk significantly, it really hasn’t. The LMA size, which is close to 1 GB was only reduced 128 MB.
To take advantage of this change, OEMs who build Windows Mobile systems need to adjust how they assign DLLs in their .BIB files. Now, large DLLs should be moved from the MODULES section of the .BIB to the FILES section. This change prevents the tools from converting those DLLs to XIP. DLLs smaller than 64 KB should be left in the MODULES section.
Third party application developers really don’t have to do anything to take advantage of this new arrangement. It has always been good practice to combine DLL code into a few, large DLLs. Now, if that DLL is larger than 64 KB, it’ll be loaded in one of the upper slots. This won’t change the way DLLs operate, its just you may notice some rather unusual base addresses for DLLs when you start debugging your application on Windows Mobile 6.1.
