Selecting a Windows Mobile API

msdn.gif There’s a useful if slightly misleading new article on MSDN on ‘Selecting a Windows Mobile API’. It explains when to use .NET, MFC, ATL, WTL and Win32 in terms of existing source code, your team’s skill set and vendor support for the API and supporting tools.

One thing I take issue with is the following statement with respect to Win32…

"Of more concern is that the API is prone to memory leaks"

This gives the impression that using Win32 will give you memory leaks. This clearly isn’t true because all the other alternatives mentioned are actually built on Win32. The developer might be more prone to creating memory leaks but certainly not the API. The article mitigates this slightly by saying Win32 needs to be coded well. Nevertheless, the article still gives the impression there’s something wrong with Win32.

One thing the article doesn’t cover is fragmentation of your application and how this changes depending on your chosen framework API. The article starts with the warning…

"Some choices in life carry more consequences than other choices. This means that the effect is felt long after the choice is made."

I consider fragmentation, or put it another way, the number of different builds you need for different device OS versions, to be the greatest consequence that has long lasting affects on not just development resource but also future support, maintenance and potential end-user confusion.

Fragmentation differs depending on what development approach (win32, MFC or .NET) you take. The problem is that if you choose the easier routes (MFC and .NET) you end up with problems of not knowing you will have the correct version of runtime on the device. My experience is that if you code for the lowest common denominator (win32) then you achieve the most amount of code that will run on all devices.

If you program for Windows Mobile you will know that both MFC (a programming library) and .NET framework have evolved over time and it’s not possible to rely on a person having a particular version of these on their device. At one time (a long long time ago) Microsoft recommended you link dynamically with MFC so as to have small executables (and downloads) and prevent bloating each exe with what would be the same code. Now, with the variety of MFC versions (and I suppose greater memory on devices), the accepted technique is to link statically and include all the code in every application.

It’s a similar situation with .NET compact framework. A method of working is to code against one version of the framework and rely on end users possibly having to download that particular version of the framework in addition to your application – which can run into megabytes of download and is a complicated extra step the user really shouldn’t have to concern themselves about. Alternatively, you can write different versions of the application for each framework version.

For many serious applications, .NET compact framework excludes many things and the extra effort of interfacing with base Win32 c code sometimes makes it a better choice to use Win32 for everything – with no dependencies on MFC and .NET compact framework and hence maximum compatibility across Windows Mobile devices.

The fundamental problem is that runtimes/frameworks themselves have different versions with different capabilities and different bugs. The versions also tend to be out of step with underlying OS versions which complicates compatibility.


One last thing. If you are coding Windows Mobile for the enterprise or for industrial devices where you can guarantee the required runtimes are on the device, it’s worth thinking about MFC and particularly .NET.
Update: Miron Ophir, R&D Manager Emoze emailed me to say…

"I agree with large parts of what you’ve said in this post. I think Microsoft is pushing .Net for mobile development before it is matured. This is why in Emoze we wrote the entire push mail application for Windows Mobile (UI and all) in Win32."

Furthermore, Miron told me in a previous role he …

"… had the chance to check the myth about .Net superior development rate. It turned out that in most Windows Mobile project we used .Net the data layer and business logic development times were the same as in C++/Win32. The UI layer was 10-20% faster, but the overall project was not faster than C++ as we were delayed in coding some cutting edge requirement that .Net limitations made impossible to implement. I’m not saying there is no room for .Net at all, but performance wise I think Win32 has still the upper hand, and development times are not that better with .Net."