Select a language to translate this page!
Powered by Microsoft® Translator
Originally posted April 17, 2009 at MSDN.
Previous post: Twisted Pixels #2, Doing Graphics
To recap – I have a program that works in the emulator, but does not run on real hardware. The question is why.
After reading the following memory model posts:
Slaying the Virtual Memory Monster (http://blogs.msdn.com/hegenderfer/archive/2007/08/31/slaying-the-virtual-memory-monster.aspx)
Slaying the Virtual Memory Monster - Part II (http://blogs.msdn.com/hegenderfer/archive/2007/10/01/slaying-the-virtual-memory-monster-part-ii.aspx)
Visualizing the Windows Mobile Virtual Memory Monster (http://www.codeproject.com/KB/mobile/VirtualMemory.aspx)
I strongly suspect that the problem I reported in my last post is memory related. The Donuts2 sample code tests to see if the proper interfaces are implemented in the device drivers, and everything seems ok there. The failure comes during the allocation of memory for a DirectDraw surface, which makes sense for a memory problem. One other thing – after I posted the last article, I found a device that does run the application, and it has fewer applications pre-installed, and no UI shell.
Windows Mobile 6.1 inherits the memory architecture of Windows CE 5.0, and this model was originally designed when a small footprint was very important. Because of this, Windows Mobile has only 32 MB of virtual memory space for your application to occupy. It does not matter how much memory is built into your device, you can only use that memory in 32 bit slots. There are additional issues that further reduce the amount of available memory, and these are well described in the posts mentioned above, so I will not go into detail here.
Note: This memory limitation has been removed from Windows Embedded 6.0, and we can hope that this change will find its way into a future version of Windows Mobile.
You can’t debug what you can’t test, and there are two tools that let us examine virtual memory conditions on Windows Mobile:
I do like the memory visualization tool VirtualMemory.exe included in the page Visualizing the Windows Mobile Virtual Memory Monster (Link above), and have added it to my debugging toolbox, although I can’t use it today. Another invaluable tool allows the creation of screen shots on the device. Although there are several free utilities available, the one I found to work the best was SPB’s “SPB Screenshot” utility, which can be downloaded from the publisher at:
That’s another one for the toolbox.
Because Donuts2.exe runs full screen, and captures all input, I was unable to run either of these memory profiling applications to test my theory. At this point, I could have instrumented the sample to log memory conditions to a file (or perhaps to execute DumpMem), but that is time consuming, and I don’t really care enough about this one example to try. If this was a production application, it would be well worth while to study the information on memory model, and test till there were no questions left. I do have some simple questions that I would like to answer, and I’ll try to do that in a later post.
Although I’ve failed to slay the monster, I think I understand it a bit better than I did before. It seems strange that a sample in the current SDK would fail like this – Perhaps some other phones have fewer apps installed than my stock Diamond. I was able to borrow a few other devices and started testing performance on other devices.
No luck with my old HTC Hermes, and no luck on a Samsung I780. No luck with a couple of other older phones. I was about to give up when a friend dropped by my office to show off a new ASUS P835 running Windows Mobile 6.1. Just for fun we tried it – and it worked. SPBScreenshot does not seem to work with DirectX apps, so you will have to take my word for it, but performance was good, and the app conformed to the large high resolution screen, and the seemed responsive, with a reasonable frame rate.
Out of curiosity I ran VirtualMemory on some of the phones and on the emulator just to get an idea of what can be expected and to look at variance between different phones. DLL space goes from the top of the screen to the bottom. Program space goes from the bottom to the top. As I understand it, the limiting factor is the lowest DLL loaded into memory.
Figure 1. Emulator memory map (Windows Mobile 6.1)
Figure 2. HTC Diamond memory map (Windows Mobile 6.1)
It is clear that the HTC has more DLL memory pre-allocated, which is likely interfering with my application. That’s the price that a user has to pay to have an awesome interface like TouchFLO.
So – the lesson learned today is that available memory varies from phone to phone, and there can be issues that show up on some phones and not on others. It is always good coding practice to check for failure every time you allocate memory, and that becomes particularly important here. One of the challenges of writing games for the mobile platform is dealing with resource issues, and this will remain an issue for the developer of Windows Mobile 6 software.
Next up – Twisted Pixels #4: A Button Masher's Guide to Input