More Memory for ALL in WM 6.x

Now that the Windows Mobile 6.5 DTK is available, you are probably starting to discover some of the new features and APIs available to you. There is pretty cool stuff in there to move us forward from 6.1…things like Gestures (see the DTK samples since the docs are still coming) and Widgets. More importantly, Windows Mobile Marketplace is going to be on every 6.5 device and if you are an ISV, bells and whistles are nice, but an effortless consumer connection to sell your software is HUGE.

 

It you were a mobile developer attending Tech-Ed this last round in LA, you know it was special. Not only was it a the first real depth series on 6.5, but I think it might have been the best event we’ve ever done in terms of session content and speaker quality (I can say this since I didn’t actually speak this time!). There were no watered down mobile sessions…lots of info on topics like Location, Advanced UI, Motion Tips & Tricks, WCF in NETCF, SQLCE, etc… it was all great stuff. If you attended and missed any sessions, you can watch most of them online via Tech-Ed Online. Windows Mobile was the highest rated track at the event…credit to the partners and community who contributed to make it a success. Many of the speakers were all the guys(and gals) who have been silent mentors to me. You all did a fantastic job. THANK YOU.

 

As I was sitting in Rob Tiffany’s session on “Breaking out of the 32MB Barrier with .NETCF”, he stirred my memory concerning another major improvement in 6.x that nobody (except “the man” Doug Boling) has really been talking about yet… memory improvements for native devs. First let’s recap Rob’s message… The technique he outlines is a clever approach to maximize available Virtual Memory space for managed apps. It basically says, use a super light stub of an EXE and then package all your code into managed DLLs. That keeps your EXE footprint very small and because NETCF uses large memory areas to map the DLLs into memory, you maximize your VM address space for the runtime. You’re still subject to the 32MB limits, but because you have minimized the footprint of the EXE and DLLs in Slot 0, it’s almost all free for the managed heap which means you get a very large playground for app development. This is a technique that works for all versions of WM…not just 6.5. Managed Developers cheer!

 

Well that’s cool for managed developers, but… what about native developers? What about managed code that is p/invoking native DLLs?

 

So check this out… with every release of WM, there are usually little “tweaks” added by our platform gurus to squeeze more out of available memory. Maybe they allocate stacks out of another slot to help device drivers, load resource DLLs into slot 63, or flag a way to keep a specific DLL from reserving VM space in another process. These changes are largely invisible to ISVs and commonly geared to help device makers. But here is one change you may notice…especially if you are building beefy apps. Starting with Windows Mobile 6.1, loading native DLLs larger than 64k will often end up in slot 60 and 61. That’s a 64MB area in high memory that can now be used to get DLLs out of slot 0 and free up a ton of Virtual Address space in your processes. The OS will attempt to load any DLL over 64k into upper slots… falling back down to lower slots when things are full. Remember DLL crunch? You might not after moving to WM 6.x…

 

Let’s take a look…

It’s hard to directly contrast 5.x and 6.x device memory because there are so many variables, so I’m just going to look at a simple native app that pulls in a bunch of native dlls for comparison. The important thing to note is how much space in slot 0 is being used. Slot 0 is the crunch zone, so anything you get out of there is a good thing. I’m going to build a native DLL with Visual Studio. By default, a Hello World kind of DLL is only about 4K, so I’m going to bloat it out a bit by statically linking in a bunch of runtime code. I basically want a bunch of small and large DLLs that I can examine in Slot 0. So I build SimpleDLL_1, SimpleDLL_2, SimpleDLL_3, etc. The first three are 4K, then second three are much larger (1312K). Then I load the into my little native app called Loader.exe using LoadLibrary and compare the footprint of Slot 0 across WM emulators for v5.0, v6.1, and v6.5. Check this out..

 

On WM5, as expected… I see all the DLLs crowding into Slot 0 (under address 0x02000000)…each DLL pushing lower..crowding my heap and reducing my space to load others DLLs for everyone.

On WM6.1, and WM 6.5, something very different happens…notice that the three bigger DLLs are … gone! Only those tiny 4K DLLs were pulled into Slot 0 and everything is sitting much higher in Slot 0 memory (which leave more room for your code).

 

If you look higher in memory, you can see that they did in fact load, but they are taking advantage of some memory optimizations you get with WM 6.x to load large components high and free up Virtual Address space in Slot 0.

What does this mean? It means that large apps have more memory space than ever to get things done. It also means better stability for devices and applications across the board since it reduces DLL crunch and Virtual Memory pressure. Mike Francis asked me if the Virtual Memory Monster was dead now… well, let’s just say it’s walking with a big limp and probably won’t be bothering anyone today.

 

Cheers,

Reed