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.
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.
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.
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.
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.