A Warning about Windows CE

After working on several Windows CE projects, I am noticing patterns. There is a "gotcha" with the OS I find interesting, as it evades all sorts of higher-up managers. Before I say what it is, I'd like to cover first the things people think are gotchas with Windows CE, but are not.

Windows CE is not a RTOS

The first thing I've heard when Windows CE is under consideration is that it is not truly a real time OS. After reading some studies, working on projects with Windows CE and real-time requirements, and prepping to teach a Windows CE training, I am convinced that it is a real time operating system. Interrupt latency is deterministic, and if you know what you are doing, you can use Windows CE as your OS in your embedded system that has hard and soft real-time requirements.

Keep in mind though just because you can use Windows CE doesn't mean you should use Windows CE for your real time OS. I doubt any embedded software developer with real time system experience will take Windows CE seriously as a solution to control flow of medicine to a patient. Or the cooling of a nuclear reactor. For a front-end setup, without real time requirements, to drive a display, UI, and touch screen to these systems? Sure. To be in a closed loop safety control system where one late interrupt could kill someone? No way. Even though you may be able to get it to work, no one else will be doing what you are doing. Any sort of safety certification won't fly. And it shouldn't--you are using something in a way that it isn't intended for. Get something by Wind River or Green Hills.

As a side note, I don't think the above statement isn't recognized by Microsoft. I'm sure they are more than happy for CE not to be in the loop with real time safety critical control systems. Anything to avoid litigation when things go wrong and people get hurt. I'm sure 99.99% of Windows CE licenses are for Windows Mobile platforms anyways, that's where the money is for them. Although who knows what new luscious platforms like the iPhone and Android will do to Windows CE.

Windows CE is not Stable

This one I hear a lot and disagree. The times I have seen a Windows CE system unstable, it is always due to the application level code. When the system is configured right, and the OEM BSP software is production ready, Windows CE runs like a champ.

I think this notion is created by folks that haven't dealt with Windows CE, and fill in the gaps with what sort of Windows experience they have. More often than not this is blue screens on Windows 98 or (even better) Windows ME. But Windows CE is completely different, right down to the kernel.

Windows CE is Closed Source
This one is partially true. The kernel is completely open now, so there is no limit to delving into the source code to completely understand the ins-and-outs. A necessary feature when debugging, especially when timing is involved. However there are all sorts of standard Windows libraries that are closed source. Plan to see the source code for the .NET Compact Framework components? Sorry. How about the IP Helper API so you can figure out all the weird NDIS driver calls? Sorry again.

The Gotcha:
So if Windows CE is real time, stable, and open source enough... what is the big gotcha? It is actually quite simple:

Windows CE doesn't turn Desktop Developers into Embedded Developers.
Managers love the idea of Windows CE because they think they can take the stock windows programmers they posses and have them create an embedded system. But just because Windows CE supports the Win32 and a subset of the .NET Framework API, it doesn't mean you aren't developing an embedded system.

Take a past client I had at a prior job, whose name I won't divulge (as getting sued is lame).While the hardware was being designed, the windows developers got a head start and cranked away on the end-user software. Their platform of choice was AJAX running on top of pocket internet explorer. You don't need to be a rocket scientist to predict what would happen upon running their heavy-weight java script/IE based app on a 400MHz PXA270 XScale processor. Fortunately for them, we were able to accelerate the performance by migrating the system to Adobe Flash for ARMV4I/Windows Mobile.

Long story short, a good embedded developer will be thinking about software performance, and bench-marking end-user software from day #1. You need to start desigining your software for your target device, and use any sort of emulation or cross-platform development with extreme caution. Get the development kit with your embedded processor of choice as a stop-gap until your first rev hardware arrives. Save yourself the headache of discovering that the software you developed on your 500 Watt PC will run differently than on your 1 Watt embedded processor.