So you just bought a brand new WM5 device. The box says it's got 64M of RAM. You go digging through control panels on the device and find one that says it's only got 50M. Is something wrong? Should you be worried about this? The short answers are "No" and "No." This blog entry will explain why.
First though, please make sure you've read my earlier "RAM, ROM, NAND, NOR--that's a lot of capital letters..." entry. I'm assuming here that you understand what I described there.
It's all about control
The primary source of this confusion stems from the fact that the control panel which shows your RAM usage only counts RAM that you have any control over. That is to say, it only shows running applications. There are other uses for RAM, and such things are hidden from you. As end users, there's nothing you can do about them, so why display them in the panel? Now you could make the argument that you'd still like to see a listing of the RAM you can't directly use. The WM5 designers disagree. I personally don't have a strong opinion on the matter one way or the other.
You might also make the argument that you don't really have control of everything listed in the control panel, since there's application RAM used at boot time and there's no easy way to close things to free it up. I don't have a good answer for this, other than to say that the RAM is being used for things that we're pretty sure you want running--the phone dialer, the PIM, the drivers that make the hardware work, etc.
Some of that code comes from Microsoft, and we're interested in feedback on things you don't want to be running by default. If we shut off the dialer, you wouldn't receive phone calls. If we shut down the PIM, you wouldn't be able to see your next appointment from the home/today screen. Etc. If there are apps that you don't think should be running, let us know. The more specific and constructive you are, the better. You'll get more traction with, "I never use this app, so I wish it wasn't using RAM all the time," than "Stupid Microsoft, all you can ever do is bloat stuff."
Some of that code, however, comes from the Mobile Operator who sold you the device, and some comes from the OEM who manufactured it. It's sometimes hard to tell which is MS code and which is MO code. But giving similar feedback to the place where you bought the device is a good thing to do. "I really never use add-on app X. Please have it stop using my RAM."
So what's this stuff I can't control?
Where did the those 14 megs go? This will vary from device to device, so I can't give exact numbers. But I can tell you the kinds of things that tend to use RAM outside the scope of running applications. There are five main sources.
The Page Pool
Applications use RAM in two ways. There is code that runs, and there is data that is created while it is running. On a NOR device, the code can run directly from the ROM and not be loaded into RAM first. This process is called XIP (eXecute In Place). NAND devices can't XIP, so their code is loaded into RAM and executed from there. If you don't have a Page Pool, this code is loaded into normal RAM. The Page Pool is a mechanism to limit how much code is loaded into normal RAM. With a Page Pool, we can unload code that hasn't been used in a while and reload it later if we need to. We can't do that without a Page Pool.
On a typical NAND-based WM5 device, the Page Pool is 4.5M.
The Radio Stack
Devices with a Cellular Radio have a complicated bunch of code to make their radios talk to cell towers. On some devices, the radio is a self-contained module with its own RAM and ROM. On others, the radio code is stored in the normal system flash. If so, it either needs to XIP, or it needs to be run in RAM. If it's run in RAM, that RAM is taken away from the system.
A typical radio stack takes 4M.
Some hardware can write directly into RAM without using the CPU to do it. This is called "Direct Memory Access" or DMA. DMA is very efficient and lets you get a lot more data transferred in the same amount of time, usually for less power. But it's best to set aside your DMA buffers before the system boots. This guarantees that they're there when you need them. PocketPCs have been doing this for a decade. But, back in the old days, the main use for DMA was audio capture. Audio data is small, so the DMA buffers are also small. Video, on the other hand, is big. More data requires bigger DMA buffers.
An OEM will tune the size of the pre-allocated DMA buffers based on what the device is intended to do. If the main goal is still photos, you can use a much smaller buffer. If the goal is recording video, it needs a much larger buffer. If the goal is video conferencing, it needs a bigger buffer still.
DMA buffers range in size between 300K and 6M. For a video capture device, it's likely to use around 4M.
There are portions of the deepest parts of the OS that have to XIP. If you're on NOR, that code just XIPs like everything else. Not so on NAND. For a NAND system to boot, it needs to load this code into RAM first and then run it from there. When the system is running, it can't really tell if it's running from RAM or ROM, so it assumes it's running from ROM and doesn't count this space.
The XIPKernel region tends to be between 1.5 and 2M.
The Frame Buffer
There is a chunk of RAM set aside to hold everything that's on the screen. (If you want to know more about it, read this.) On most devices, every dot on the screen needs two bytes. A typical Pocket PC has 240x320 dots. That would be 300K. If you have a 640x480 screen, it's 600K. Sometimes, for performance reasons, devices will have two frame buffers. So this could take up to 1.2M.
But you said 32M was enough!
You obviously can't have a 32M device if 14M are gone before you start loading applications. What's important to understand is that all of the big ticket items above are dependent on the hardware used. If a device was NOR based and XIPed, it would use a smaller Page Pool (or none at all). It would likely XIP the XIPKernel region. It might be able to XIP the Radio Stack as well. If it was tuned for taking pictures instead of video conferencing, it could use a smaller DMA buffer. If the device was 240x240 instead of 640x480, its frame buffer would be 1/6th the size. Etc.
The important thing to understand is that these are all knobs that the OEM can adjust to tune their particular piece of hardware. The OEM makes conscious decisions on trading off speed and abilities vs. loading a bunch of applications. You could say, "I don't trust them to make those decisions" but that would be silly. You trust them to design the hardware and write the drivers. That stuff is far more difficult to get right than the relative tuning of DMA buffer sizes.