Pocket PC development

I have been spending most of the last month and a half on programming for Windows CE at work. It's been a great experience, and I've learned a lot in the last months. The challenge was a graphical presentation client built from the ground up, to replace a Flash 6 based presentation system.

Platform
Our main platform was from the start a Pocket PC running Windows Mobile CE5, so the first implementation was written explicitly for this platform. The language was C++ from the start, so I was sure I would never run into unsolvable problems - the rationale is "if it has ever been made on the platform, it can almost certainly be done in C++". I had a long look at the samples supplied to get an idea of how things are mainly done, and just started from scratch.

Design
I would like to utilize every feature available, while still holding the door open for future ports, so I decided to try to separate portable and non-portable, and make all system-dependent code subclass an abstract class, containing platform independent code. The image class for example contains 90% independent code, whereas the loadImageFromFile function inside the class was abstract and each platform has it's own class implementing it.

As it might be apparent I choose not to implement the wheel, so if a functionality was available from the OS, why not use it. There really isn't any need to supply your own JPEG loader, if the OS does it well enough.

Speed
I didn't really have my hopes that high about the speed of these devices, but I was quite wrong. My performance expectations were largely based on what Flash could deliver, and a "Donuts" DirectDraw-based game. But boy was I wrong. I was expecting to have to squeeze every cycle out of the ARM-processor, and possibly dive into ARM assembler for critical functions - but things just ran smoothly.

When I had set up the first "screenflipper" test, blitting a single image and overlaying another image it became apparent that I would have all the speed I needed - even in rather unoptimized C. I choose to use 16 bit 565 images for all my internal opaque screenbuffers, and ordinary RGBA32 for buffers with alpha. I implemented Avery Lee's 16 bit blending optimizations from the start, but beside common sense, I didn't really need to do much more.

So far I also only have praise for the speed of the internal functions I've used. The JPEG/PNG loader is lightning fast, and the SAX/DOM reader has also shown very good performance. I haven't used anything graphically, except a fullscreen directshow surface, so I think I've also come around the biggest issue - which based on the other applications on the platform seem to be GUI performance.

The Windows CE platform
Without a doubt the biggest headache has been the platform itself. For those of you who don't know, the platform is a huge platform - so for each device the manufacturer is able to customize the OS. This is not only a matter of selecting which applications are available, but also which COM objects will be included in the OS.

This leads to a massive headache, if you need them, and they aren't there. My first encounter with this was when I tried to add mp3 playback. According to the SDK that should be an easy job for Directshow - but as it turns out that feature is appropriately not enabled by default. No problems - that only took a couple of wasted hours to find out. (Even more interestingly, there is a DS filter that claims to be "MPEG 1 Layer 3 Decoder" - but even after wasting a few more hours trying to manually set up a decoder graph, I finally gave up, as there seemed to be no way to get it to make any form of incoming connection).

Another example is the SAX XML parser, which is included in CE 4.0, 4.1 and 5.0, but apparently it wasn't needed in CE 4.2. So here a day was wasted on writing a DOM-based parser for CE 4.2.

This basicly makes CE a very difficult target to write for, as it is completely up to the OEM to decide which features are available to you. This might make sense to MS and the OEM, but it isn't really an argument that works on our customers.

That said, the OS is really nice to write for. You basicly have the same application possibilities as in Windows - with a few very minor things.

Visual Studio 2005
While I have used VS 2005 (Express) for a while, I must say that this project has me convinced. I really love the must - just as much as I hated VS 2003. It has been quite smooth, with a very small number of crashes and bugs.

I briefly had eVC4 fired up, since there was a problem, when I had to do the CE 2003 version (VS 2005 generated invalid some code - long story). Having to think about broken for-loop scoping and other stupidities of the past made me try just that little harder to get VS 2005 working, which I finally did.

Symbian
You cannot really talk mobile programming without mentioning Symbian. I've been looking at porting possibilities almost from the start, but so far I haven't done much more than installing the SDK, looking at documentation and samples. I obviously wont comment too much on it, but a few observations.

When I first opened a document on programming for Symbian, I saw "Welcome to Symbian C++", and hit my head. I want "C++" and not "Symbian C++". No STL and no exceptions??!? Come on! While I understand their argument, that STL can in some cases lead to larger code size and exceptions to sub-par performance, I do not need you to make the decision for me. So far I've used plenty of STL in my app, and the executable isn't over 40KB yet.

It does however seem that the next Symbian will include some or all of these features. It doesn't really help us until a couple of years have passed, but in the meantime, I've found uSTL, which looks really good (but could you include a VS 2005 project file ;)

Conclusion

Well - these are fun little devices to program for - after the basic framework was done, and the initial bugs were sorted out, it feels as if the fun has just started - and it's quite hard to get to work on other projects. Hopefully I can return with a link to a demo version soon.