I was asked to get a C application working on Windows Mobile. Some colleagues at work have got some hobby code : a bunch of C files which they want to try out on a huge range of mobile platforms such as a slug. On Linux-based platforms, it’s apparently fairly straightforward – without too much work, gcc or some such compiler turns the code into a neat little executable.
Now the plan is to try it on a Windows Mobile device. And, probably cos I won’t shut up about Windows Mobile, they asked if I’d fancy giving the code a try on Windows Mobile.
What were my options?
a) Rewrite the app in one of the languages supported on Windows Mobile – C++ or C#
As hobby code in an early stage of development, it’s changing a lot. I was reluctant to invest much effort in forking the code at this point to write a version of the app in C++ or C#.
b) Try and get the C code to compile for Windows Mobile
This way I can keep changes to the existing code-base to a minimum. And I thought it’d be quicker.
So I went with (b).
It was an interesting bit of work, and not something I’ve tried before.
The SDK for Windows Mobile has a compiler for Visual C++. And C++ is a superset of C, so I should have been fine, right?
Well, no.
Yes, I have a compiler that can compile C code – and if I had code with just the basic bits and primitives of C, I’d be pretty much fine.
What I’m missing is big chunks of the CRT (C Run-Time Library). Presumably because C isn’t a supported development environment for Windows Mobile (Update: see comments below), and this is a mobile platform where resources are scarce. If you don’t want developers to be writing C, why bother filling the storage of a mobile device with all that CRT goodness?
When I imported the C code into Visual Studio, and configured it for a Windows Mobile target, it came up with hundreds of errors. And nearly all of them were due to functions used in the C code which were missing in what passes for the CRT I’ve got!
So the way to get C code to build for Windows Mobile seems to be to write replacements for the C functions used by the original developer, but missing from the mobile CRT. Which meant I spent a fun couple of evenings reading man pages for C functions in the Linux Programmer’s Manual, and trying to cobble together my own versions that conformed to the UNIX versions that the original developer was coding to.
If I recall correctly, the first one was strtok_r
and I went from there.
Interestingly, even after I got the code to compile, it then spat out a bunch of linker errors. It turns out that the Visual Studio SDK has a bug where the time functions were mistakenly left in the headers for Windows Mobile, even though the actual implementations were all removed. So the code – which includes a bunch of uses of C time functions – compiled fine, but then failed to link because the implementations were missing. So I had to back to writing my own implementations!
Not sure that I’d recommend this as a sensible long-term approach, but as a quick hack to get some code working, it was an interesting exercise.
Tags: build, c#, code, compile, visual studio, windows mobile
Yeah this can be real “fun”.
A lot of the open source projects I have dealt with that have Windows Mobile ports are full of “dummy CRT” source code. I.e. a hacked together version of any missing CRT functions in order to emulate enough functionality to get the port up and running.
You might like to investigate the CELIB project – http://www.rainer-keuchel.de/wince/celib.html I have not utilised this project recently, but it was intended to be a common implementation for a number of these missing functions and features as some are inherently more difficult to implement/emulate than others.
To say that Windows Mobile (and by implication, Windows CE) does not support development in C is completely invalid statement. Windows CE *does* support C and always has done. In fact, the .NET Compact Framework CLR was written in C as are significant parts of the operating system. You only need to look at the source code in Platform Builder to discover this.
The fact that the CRT is subset of the desktop CRT is a common scenario in the embedded world. It’s just like the .NET Compact Framework is a subset (and in some respects, a superset) of the .NET Framework. You wouldn’t say that Windows Mobile doesn’t support .NET just because it only supports a subset!
@Christopher
Thanks for the link – I’d not heard of CELIB before, and it looks really interesting.
@Neil
Thanks for the comment. I should have been clearer – by “support” I meant ‘support as in help’ – Microsoft supporting C development in a fluffy, hand-hold-y kinda way, as opposed to making it technically possible. Such as with the samples that ship with the Windows Mobile SDK (all C++/C#/VB), or the forums they host for community support (again, C++/C#/VB).
And all the doc I found for functions I needed, such as when I was looking for the strtok function I mentioned, had the green tick icon for Win Embedded CE and the red dash icon for Windows Mobile.
I just got the impression that they weren’t going out of their way to make it easy to do traditional C development. But you’re right, it was overstating it to say “unsupported”! 🙂
I picked up a very neat trick from Neil via twitter:
You get to see the CRT functions available to you:
Before this, I was relying on Visual Studio’s Ctrl-Space auto-complete to know what my options were, but this is much nicer.