One of the main problems with Windows Mobile 5.0 devices is that they don't have a lot of RAM available to users so you can't run a lot of applications at the same time, and on top of that some applications aren't good about returning the RAM they use after they're done. RAM in Windows Mobile 5.0 works in the same way as RAM on a PC. It's volatile storage which means that if power is lost everything in [...]One of the main problems with Windows Mobile 5.0 devices is that they don't have a lot of RAM available to users so you can't run a lot of applications at the same time, and on top of that some applications aren't good about returning the RAM they use after they're done. RAM in Windows Mobile 5.0 works in the same way as RAM on a PC. It's volatile storage which means that if power is lost everything in it is erased. It's used to load running programs and store info temporarily. Windows Mobile 5.0 devices also have ROM which can be compared to a hard drive on a PC and is used for persistent storage. So essentially, much like a PC whenever a program runs on a Windows Mobile 5.0 device (for the most part) it is copied from ROM to RAM and then executed. The code then remains in RAM until it is done and then it's supposed to free that RAM for something else - except it doesn't always seem to happen too well. Keep in mind, releasing this free RAM and memory management in general is the responsibility of the application NOT Windows which is why things get messy with third-party apps.  In any case, I am very much in love with my Cingular 8125 which runs Windows Mobile 5.0 but I got frustrated with the constantly vanishing RAM so I sent an email to the Windows Mobile Team blog, who actually work on the development of the system. This a great email response from Mike Calligaro of the Window's Mobile Team. Its pretty self-explanatory. What do you think? Is Mike's explanation valid? I think if what he says is true that we need to pick up our pitchforks and go after the OEMs such as HTC for sticking us with a paltry 64MB of total RAM...most of us start with only about 22MB available after a soft-reset and if 10MB+ is "supposed" to be used by the OS then we're left with 10MB or even less. Leave a comment and let me know what you think. -----Original Message----- From: Me Sent: Friday, April 28, 2006 8:15 AM To: Windows Mobile Blog Team Subject: (Windows Mobile Team Blog) : WM 5.0 System Processes Memory Consum= ption Importance: High Hi, I would normally accept OS memory allocations and system process memory foo= tprints as a necessary evil but something just does not seem right. I have a HTC Wizard device running the latest AKU2 ROM (OS 5.1.195 Build 14= 847.2.0.0) I start off with about 22MB of free memory after a soft-reset and now after= using the device for about 8 days, I'm consistantly floating around 7-8MB = free. I ran Task Manager (similar to MemMaid) which looks at running processes an= d memory footprint. Guess what I found....the top 4 memory hogs are ALL WIN= DOWS MOBILE 5 SYSTEM PROCESSES!! So in reality it doesn't matter which apps you are running from third-parti= es because it's WM5's own system processes that are killing your memory. Here's my top 4: GWES.exe - ~3MB Filesys.exe - ~ 2.5MB Shell32.exe - ~ 2.5MB Device.exe - ~ 2.0MB Total = 10MB!! VoiceCmd also takes up about 2MB and the rest of my apps/plug-ins take up ----- Reply to Original Message----- From: "Mike Calligaro" To: Me Sent: 5/8/06 4:43 PM Subject: RE: (Windows Mobile Team Blog) : WM 5.0 System Processes Memory Co= nsumption These numbers feel about right to me. It takes code to run an operating sy= stem, and code uses RAM. All of the processes that you've listed below are= system processes. GWES is the windowing system. A large number of the system bitmaps are loa= ded into GWES. Bitmaps (pictures) take up a lot of space. Also, every app= lication that creates a window causes GWES to allocate space to manage that= window. Font data is also loaded into GWES. The more fonts used, the mor= e space GWES will use. Filesys is the file system. It is equal parts Microsoft code and OEM code,= but 2.5M feels about right, especially if you had a storage card inserted = when you took that number. It is the file system that stores data in inter= nal flash and storage cards. Because flash is considerably slower than RAM= the file system uses a chunk of RAM as a "cache." When you want to write = something to the flash, the filesys will store it in the cache and let you = get on with your business quickly. Then it slowly writes the data out to f= lash. A sizeable chunk of the RAM you're seeing is used by these caches. = An OEM can configure how big the caches should be, but this is a tradeoff b= etween RAM usage and performance. If you use too little RAM, the device wi= ll go too slow. Shell32 is the user interface of the system, including the today screen. A= ny today screen plugins you have are loaded in Shell32's space, as is the b= ackground image. Device contains all of the device drivers on the system. Device drivers ar= e the code that make the hardware work. Without them, your device is nothi= ng but a hunk of plastic. Device contains, minimally, the Display driver, = backlight driver, audio driver, keyboard driver, battery driver, usb driver= , camera driver, Bluetooth driver, wifi driver, and cellular radio driver. = Remove the display driver, and your screen wouldn't work anymore, etc. Al= though all of these drivers are written by the OEM, running more than ten f= undamentally important pieces of code in 2M seems reasonable to me. Mike