So, this is probably going to be a series of posts on why Windows Mobile sucks, from both an user and developer perspective… and I’ll try to explore exactly what Windows Mobile needs to do to survive as a platform – and if what Microsoft is doing in Windows Mobile 6.5 is enough. Some of the topics I’ll be covering include developer tools and user interface. We’ll start today with #1. Note that this isn’t really in any order of how bad the problems are – but rather, when they come to my mind. So let’s start!
Problem 1: .NET Compact Framework
Okay, a good idea in theory – the .NET framework is proven in both client and server-side applications, and unless you’re a masochistic developer – you would probably prefer programming with the .NET framework if it didn’t have any performance issues. Managed code makes the programmer’s life much easier – among other things, you get garbage collection, somewhat automatic exception handling, lots of libraries for accessing both operating system functions, containers, and common algorithms… the list goes on.
Managed code is run inside a virtual machine known as the common language runtime (CLR) – for those familiar with JAVA, the concept is very similar. Think of the CLR as a special machine which runs Common Intermediate Language (CIL) as its assembly code. When a .NET program is run on the CLR, the CLR does Just-In-Time compilation of CIL code to the native assembly language of the machine. The advantage of this idea if you write a program in CIL, you can run the program on any platform with the CLR on it – you don’t have to recompile your code each time. The programmer only needs to write their C#, VB.NET or other code and compile it to CIL that targets the CLR. This managed code seems like it would be great for a platform like Windows Mobile, that runs on a variety of architectures. In fact, I’m pretty sure Microsoft thought this would be the answer when PocketPC devices were running on a number of architectures, including MIPS, ARM and SH3/4… and programmers had to recompile their binaries for each architecture. Today, nearly all Windows Mobile devices run on ARM.
Of course, you might have guessed, running managed code, has its negatives. The biggest problem on embedded devices is the resource and performance hit that you take from starting this virtual machine. If you’ve ever run a .NET program on Windows Mobile, you probably noticed it took 5-10 seconds for the program to start… during which you are presented with the annoying Windows Mobile wait cursor. This is the CLR taking the time to load up – which needs to be started for any .NET program that runs. After the CLR loads, performance is typically acceptable for non-processor-intensive applications. The problem here is that a 5-10 second load time is unacceptable for a mobile device. Windows Mobile users are probably all too familiar with how long it takes for the built-in calculator to startup. The built-in calculator is written in .NET! The 5-10 second startup time pretty much makes the calculator unusable for what its meant for – making quick calculations. I can’t tell you how many times I needed to do something like calculate the tip I needed to pay – only to be frustrated and outpaced by someone else with a “dumbphone”. The thing is – most applications on a mobile phone are meant for doing something quickly. Taking a long time to load up really takes away from the mobile phone “experience”.
Another problem is operability with native code. Many core Windows Mobile features, such a Today plugins, extensibility, chome, etc. Must be written in native code. But what if you want to use managed code from native code? This is something you might be able to do from a desktop computer, but the .NET compact framework doesn’t allow calling managed code from native code. Other problems include random functions not included in the .NET compact framework, and strange window handling behavior when using the UI editor – but we’ll skip over those for now.
Is the .NET framework a big step up over JAVA? Although I prefer C# myself, I would have to say that it is not – at least on embedded devices. Most modern Windows Mobile devices contain an ARM core that features Jazelle technology, which does hardware optimization of JAVA bytecode. Its unfortunate that we don’t have the same hardware optimization of .NET code. The main attracting factor to .NET though, are the Windows Mobile libraries that let a programmer easily work with Windows Mobile features that are difficult, if not undocumented – to work with natively.
So why is this such a big problem with Windows Mobile devices? It seems that it is more of a problem with the Compact Framework. The problem is that Microsoft encourages development of .NET applications on Windows Mobile, even though – in my opinion it is really only appropriate for prototyping and maybe some applications where some of the built-in libraries would be immensely useful. It is not appropriate for production applications. I guess you could say that it is nice that we have something like the .NET compact framework – but it should only be used when appropriate.
The next post in this series will probably cover the Windows Mobile SDK and how it compares horribly to other mobile phone SDKs.