Windows CE: Risks v. Benefits

Jan 30, 2014 Update: A few vendors are now supporting, or planning support for Wi-Fi for WEC, which would likely change a significant portion of the analysis below.  If indicates that not only can we get new Wi-Fi hardcware, but also that third-party vendors are once again taking interest in Windows CE. See my comments and links here.

I’ve been developing applications for Windows CE for more than 12 years now and for a pretty good chunk of that time I also created OS builds themselves for custom hardware. Still, if you’re running a business it’s often a good idea to do a risk analysis of some of your dependencies occasionally, even if those dependencies define a core part of your business or expertise. I recently took a hard look at both the Compact Framework and Windows CE (or Windows Embedded Compact as it’s now known) recently, to identify some of the risks and benefits of choosing them as a foundation of a product or business.

Since I like dealing with concrete examples, instead of abstract “what if’s” let’s look at it from a specific point of view – specifically a customer of mine that wanted to get a turnkey upgrade for a product platform. This customer builds and ships tens of thousands of custom point-of-sale devices each year. A large portion of their current platforms use a home-brewed Compact Framework wrapper sitting on top of Silverlight for Windows Embedded, with a pretty large infrastructure code base written in C# below that. Historically they have been running on x86 hardware.

Recently they’ve decided to create and release a new product. An ARM-based tablet that will run the same application, with the goal being that the new hardware will provide them room to expand and grow in new markets and use cases. They designed the hardware, but contracted a third-party to deliver a Windows CE Windows Embedded Compact 7 OS for the platform. Once they got everything up and running, it turned out that the existing application ran, but really right on the edge of acceptable for performance. Adding more to the application would likely lead to customer dissatisfaction. This was not a good place to start with a new product, so they had me come in to see if I could help improve the application performance and make some recommendations.

The application code base had some areas that could be improved, but that was expected.  Pretty much every code base can be improved, including our own, and anything that had gone through several revisions over many years is always going to have room for improvement.  That said, the code wasn’t bad – in fact it was pretty good.  There really was no low-hanging fruit to be picked.  Any performance gains were going to take a fair amount of work to achieve, and we’d be measuring improvements in milliseconds.  With a month of work, I guessed that we might be able to get a 5% improvement, and that’s probably best-case.

So how could we get large improvements?  Well, WEC 2013 has been generally available since June.  It has a new SWE engine, which if the past is any indicator, probably has a decent performance improvement over previous versions. It includes Compact Framework 3.9, which includes lots of optimizations from Microsoft’s Windows Phone 7 work, as well as, and probably most importantly, multi-core support.  The new platform has 4 processor cores.  My guess is that moving to WEC 2013 and CF 3.9 on this hardware will probably improve the application performance by 20% conservatively.

So the decision to move is simple, right? They already have WEC7 running, so porting the OS shouldn’t be too much work, and managed code should just transfer right over.  They asked for a quote to do the whole thing, and that’s when I started doing a real risk analysis.  The decision, it turns out, is far from simple.

The Question

So what’s the big question here?  What, exactly do we need to understand to be able to estimate the work involved, the cost to the customer, the risks associated, and the recommendations to present?  In this case there are really three “options” to look at.  The first option, which is almost always an option (though not necessarily a good one) in these cases is to just do nothing.  Keep the hardware as is, keep the OS as-is and the application as-is.  The cost is zero and the schedule impact is zero so you shouldn’t just hand-wave it away.  The problem here is that the performance, and therefore the quality, of the “do nothing” option isn’t desirable, so we’d really like another option.

Option 2 is to port the OS and application to WEC 2013 and CF 3.6.  What are the benefits of doing so? What are the risks to the schedule, the budget and project as a whole?

Option 3 would be a nebulous “port it to another platform altogether” option.  Maybe Android or some other embedded Linux platform.  I wasn’t tasked to do this, or even quote it, but it’s certainly an option for them and we should at least consider the risks and benefits of the choice if we’re to make a recommendation that is good for their business.  While my core competency is in Microsoft technologies, I don’t have any qualms about recommending other technologies if it makes sense for the customer.  We integrate Linux, Android and iOS support into some of our products because they make sense in many cases.

Really, though, we need to come up with a cost/benefit analysis of Option 2 and then present that while keeping in mind that Option 1 or 3 are on the table.

The Benefits

So let’s look at what Option 2 brings to the table. Some of the benefits I’ve already talked about, but it’s a good idea to look at the larger picture and see what shakes out.

  • We get multi-core support.  This is likely to give us a significant performance boost, especially considering that their application makes heavy use of multiple threads, and a code analysis shows that the UI rendering thread is really what’s eating a large amount of the processor time on the existing system.
  • We get the CF 3.9 optimizations. Microsoft spent a lot of time squeezing performance out of the CF for Windows Phone 7 (before abandoning it for Windows Phone 8), and those performance benefits looks promising.  Probably double-digit performance increases in several areas.
  • The existing application code base ports easily, after all, it’s managed code.  The expectation is that no rewriting should have to happen (more on this expectation in a bit).  Yes, some optimization could be done, but the app should just run.
  • The tools are first class, meaning developers are more productive.  Yes, we could argue for days about Eclipse versus Studio, or Platform Builder versus whatever tool chain another OS supports, but I have experience in all of them and my experience is that Studio is flat out better.  The debugging experience is better at the app and OS level, and this saves a lot of developer time.
  • The current team is experienced with Microsoft technologies.  They know Windows. They know Studio.  They know Silverlight.  They know Win32.  They know C#.  Having to learn a new OS, a new development environment, a new driver and kernel architecture and a new development language would be very, very costly – especially when time to market is important.

The Risks

And now the fun part.  The part where there are surprises, and the reason you’re likely reading this article.  What are the risks involved with the migration?  After all, it’s just a port of an OS to a newer version and the application shouldn’t need changing, so what could possibly be a scary enough risk to make us even question the port?  It turns out there are lots of them.

  • When moving to WEC 2013, you get code compatibility, but not binary compatibility.  <— Read that again. This is a huge, huge risk in many cases. Let’s look at why.  The application is managed code, so that compiles down to MSIL, which is portable right?  Actually yes.  In fact, I call bullshit on Microsoft’s statement that CF applications aren’t binary compatible because they only way to break that would be to deviate from the ECMA spec or to remove opcode support – I think they just say it’s not supported because they don’t test it and their legal department therefore tells them they can’t say it’s supported.  However, lack of compatibility makes a huge difference on the native side. What exactly broke binary compatibility anyway?  Well WEC 2013 ships with a new C runtime, and all older binaries were built against an old runtime, which is baked right into the OS (so you can’t ship the old runtime with your app).  What this means is that all native code has to be recompiled.If your application uses *any* P/Invokes to something outside the OS (so not in coredll), that DLL must be recompiled for WEC 2013 (coredll is already going to be recompiled).  If that library came from a third-party, then you either have to get the full source and recompile it, or convince the vendor to compile for WEC 2013 (and they probably don’t have an SDK, since that’s exported from a BSP – hello schedule risk!).What this means is that if you’re using a third-party native component and you don’t either have (or can’t get) full source and the vendor won’t provide WEC 2013 support, then you must either find another vendor, recreate the capability yourself or the project is at a dead stop.  That is a big risk.  Maybe not insurmountable, but big.
  • Processor and BSP support.  The new hardware is using a processor that WEC 2013 doesn’t support out of the box.  It’s not an esoteric processor, it’s actually a pretty common Freescale processor, but the point is that support isn’t in the box.  Microsoft has said that support for it is “coming soon” but they’ve not quantified “soon” and their record on ship dates isn’t something I’d want to bet a business-critical project on.  So we must assume that we’d have to build BSP support for this processor ourselves.  This isn’t an impossible task – in fact it’s not even a new task.  But it takes time, and it takes experience.It also requires full source code to the existing BSP including all of their existing drivers.  Again, because of the lack of binary compatibility, all drivers must get recompiled.  It’s very rare in CE to have source code for all peripherals – many silicon vendors just don’t supply it (no idea why, since it’s only useful with their silicon).  That means you need to get vendor support for WEC 2013 drivers, and my experience so far is that there aren’t many ship vendors supporting WEC 2013.  This is especially true for WiFi.  The selection of WiFi drivers for WEC 2013 is very, very sparse.  To make matters worse, Microsoft changed the NDIS driver model in WEC 2013 (from 5 to 6) *and* they completely dropped WZC support in favor of native WiFi .  So it’s a lot of work for WiFi chip vendors to add support, and if your application happened to use WZC for network status and control, you now get to rewrite all of that code.Binary compatibility here is probably the biggest risk.  If you can’t get a driver for silicon that’s already on your board, especially for something as critical as WiFi, the project is at a dead stop (unless you want to respin the board for different silicon).
  • General OS support.  WEC 2013 is supported by Microsoft.  It’s not been out long, and they guarantee at least 10 years of support.  On paper, that’s great, but really you need more than just Microsoft support to be successful.  OS support without any peripherals isn’t overly helpful.  Yes, if you’re on an x86 and all you need is a serial port, then you can probably get by, but if you’re using ARM and other peripherals some confidence that when parts go EOL you’ll be able to get replacements would be nice.It’s only anecdotal evidence and a small subset of the market, but I know of exactly zero customers using WEC 2013.  In fact I can count on one hand the number of WEC 7 installations I’ve ever seen.  The general consensus that I see is that CE 6.0R3 was solid, covered 90% of use cases and has peripheral drivers.  I’m still working with customers who are rolling out new CE applications and still adding new features, it’s just they’re all based on CE 6.0.

The Conclusion

So where does that leave us?  In this particular case, I can’t in good conscience recommend that the customer move to WEC 2013.  If it were my business, I definitely wouldn’t – the risks are just way too scary (unless they can get all of that source code).  What about all of the existing source code?  Well Mono would help them migrate a lot of the business logic, but the UI is going to have to be completely rewritten whether they go iOS, Android or some other flavor of Linux.  Maybe HTML5 would make sense (though in general I think it’s overhyped, performs poorly compared to native apps, and sucks at getting to any actual device resources, which they need), but since they are a POS system, which is all about UI, a UI rewrite is going to be expensive.

Does this mean that WEC2013 won’t ever be a good choice?  I, honestly, have no idea.  As I’ve mentioned before, I have zero visibility into what Microsoft is thinking or planning.  I do know that we still build all of our code to support the Compact Framework – though that’s because it generally makes porting to Mono simple.  I also know that I’ve been spending a lot more time working on porting our products to Mono and ramping up on Linux – more specifically Wind River Linux, but I’ve also been playing with Fedora, OpenSUSE and Ubuntu.  Just like our customers, we have to be forward-looking and mitigate risks if we’re going to keep paying the bills, and from my perspective WEC 2013 is a high-risk, low reward path.  I’d say it’s telling that the anchor of our product line, Solution Engine, which is based on a Microsoft technology (C#) is tested and supported on Wind River Linux but I’ve not even bothered to try running it on WEC 2013.

13 thoughts on “Windows CE: Risks v. Benefits”

  1. Nice post Chris.

    This is the perfect example of a platform with no hardware support. Until Microsoft start talking and listening to the Enterprise Mobility community I can’t see WEC 2013 being adopted.

    Enterprise Mobility is a small part of my day job and I didn’t know that Compact Framework v3.9 had been released! They also need to return “first class support” to the later version of Visual Studio. It’s not fun maintaining 2008/10/12 etc just for specific platforms.

    Phil

    Like

  2. WIndows CE 6 and prior, thay all had the compatability problems too. On all these devices coredll dlls (and other system librarys) were different, with a differnet subset of supported functions. Not a big deal if one relies on his own source code and can replace or remove the specific function call. But when you have a third-party component in your app design that’s a show stopper.
    I just don’t understand why it was so! May be vendors have to pay more for WinCE builds depending on the subset of functions they’ve used?
    I work mostly with android devices now, tablets, smartphones, and I experince no such dull problems on this OS from day one!
    And don’t event get me started on the fact that CE devices were just not progressing for years! The same old 200-400 Mhz CPU’s and 32 Mb memory limits per app, 320-240 screens and styluses.

    Like

    1. @Stefan: NI’ve heard through the grape vine that a few OEMs are working on WiFi chipset drivers, but I’ve not heard who, or when they might be released. I also have seen some movement in newer BSPs (like the one from GuruCE), but it’s still pretty bare out there. I hope to get more information next week, but the the unknown are keeping the risk of depending on the platform unacceptable high.

      Like

  3. As a developer of a CE6 based product, it appears to me that in the last few years, MS completely ignored CE/NETCF as they shifted to focus on Phone7 to compete with Apple/Android. I’m sure I was not alone in wondering if MS had left CE/NETCF for dead. Well, now MS has WEC2013 and NETCF3.9 but the ecosystem has collapsed as silicon vendors have moved on. This is especially apparent due to the binary compatibility issue that Chris points out because without the ecosystem in place – you don’t get your fresh binaries.
    The question is, will MS instill enough confidence (and/or provide enough cash) in the WEC ecosystem/marketplace to attract enough support to make WEC truly viable, all the while pushing Win8 to smaller (and ARM) platforms? I don’t think so. The remaining challenge is how best to pursue Chris’s option 3 when Option 2 presents too much risk, and option 1 won’t keep up support life issues and continued product innovation/improvement. The nice tools (VS) will make saying goodbye more difficult, but no less necessary.

    Like

  4. I believe that CE itself should be re-invested in by Microsoft as a small-footprint, real-time capable OS for IoT. Linux can’t do that, nor can Windows vNext. I also think that any work on the CF should be stopped and just open-sourced. Microsoft should instead invest resources in getting Mono compiling for Windows CE. There’s no way that the CF will ever catch up in language features, so we should just cut bait and move on.

    Like

  5. very true. I am having a really tough time porting the NDIS 5.x driver for Marvell SD8787 to WEC7. Also the developer(s) Eco-system for the win CE market seems to be concentrated on few companies like Adeneo and not distributed throughout the world. Which means the customer I work for had purchased the BSP source code from Adeneo for CE 6.0 and it had to be adapted for WEC7.

    As a side note, I think the android developers’ job market is getting better and better than CE and I am thinking of moving back to Android side. Anybody feeling the same ?

    –Alex

    Like

  6. Chris,

    It’s been over a year since your update. Has anything changed? Do you see vendors starting to support and use WEC 2013?

    Like

  7. I’ve seen a couple devices offering WEC 2013, but I still know of no one fielding WEC2013 devices. From my perspective, I’ve pretty much stopped supporting Windows CE except for maintenance-type work because there simply aren’t any customers any longer. Most CE-based products we offered we open-sourced, and all of my new development is desktop or Mono-only because I was tired of being hamstrung by trying to maintain .NET 3.5 and Studio 2008 compatibility.

    Like

  8. I have an application that is developed and runs on CE6.0. Now my new HW support only a WEC2013 BSP. Assuming that the BSP works on my new HW, how easy/difficult is it to port my application (.NET, C#) on WEC2013? Any idea of efforts?

    Like

    1. Apps (unfortunately) are not binary compatible. They should, though, be code compatible. So just recompile with a WEC2013 SDK and they should just work.

      Like

  9. Chris,

    I have another query. We have an embedded application running on CE5.0. We have done some modifications to the SDK and of course developed a lot of drivers. Now we are constrained to move to CE6.0 due to discontinuation of support from Microsoft. Do you have any experience you have in such porting that you could share?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s