"When you come to a fork in the road, take it."  - Yogi Berra

As you may have read already, we have decided to reinstate support for Windows CE 4.2 in our forthcoming V2 SP1 of the .NET Compact Framework.  (You can read the actual announcement here.)   Here's some of the behind-the-scenes background on how the decision was made to drop it in the first place, and why we have decided to bring it back.

During the planning of every platform release, there are hard decisions to be made regarding how much backwards compatibility to provide.  (There are equally hard decisions about "forwards compatibility", but that is for another post.)  It's not that we don't want to provide perfect backwards compatibility -- we do -- it's that the cost of providing that compatibility is nontrivial, and the farther back you go, the more costly and imperfect that compatibility will be.   In some cases, there is extra development work required to support older versions of the operating system:  as features evolve and bugs are fixed in the underlying OS, we naturally adapt our newer code to the newest (and hopefully best) implementations, and that may mean that we have to keep special-case code (#ifdef-ed) around for older implementations.  The more of this you have, the messier your builds and implementations become.  Until relatively recently, version-to-version compatibility of the Windows CE and Windows Mobile operating systems hasn't been a very high priority, and so there have been a pretty large number of version-specific features in the operating system that we have had to work around.  But, even though #ifdefs can make your code messy, they don't really add much cost, because you have already completed the older implementations once, and it's not really that difficult to keep them around. 

A much larger cost of running on older operating systems is the test effort required.  The "test matrix" for the .NET Compact Framework is a big chart showing which hardware and software versions of operating systems we test the NETCF runtime against, and the size of this effort is really very large.  We test systems with NETCF in RAM, and systems with NETCF in ROM; we test Windows Mobile as well as Windows CE; we test Pocket PCs as well as Smartphones; and for each type of system, we test hardware from as many vendors as possible.  This all takes place in a state-of-the-art testing lab that is busy every day, testing every build of NETCF.  At the end of each release cycle, we do a full test pass, which exercises thousands upon thousands of test cases in every one of these configurations.  Even with testing going on virtually around the clock, completing a full, final test pass takes about three weeks to complete!  This test pass is quite costly, and is one gating factor in how quickly we can bring new versions of NETCF to market, so we try to keep its size under control.  Eliminating an OS version from this matrix results in a sizable reduction in testing time, and in significantly lower numbers of (older, and special-purpose) hardware in our test lab.  So, we are quite deliberate about eliminating everything from this matrix that is not absolutely necessary.

Yet another consideration is the cost of ongoing servicing of any release.  Microsoft has standardized support policies in place for all types of releases, and by re-releasing software on an OS, you in effect restart the clock on some of those support policies.  Even though it might not cost that much to "make it work" right now, supporting any particular platform can cost quite a bit more over the lifetime of the product.

Which brings us to Windows CE 4.2.  At the time we were making our final support plans for NETCF V2, Windows CE 5.0 was already close to being shipped.  We knew that it was going to be released shortly, and we expected the uptake of Windows CE 5.0 to be very good.   We also knew that our embedded developers -- the ones using Windows CE to begin with -- tend to be more sophisticated, and able to deal with the complexities of an OS upgrade most readily.  So we convinced ourselves that the cost-benefit of dropping WinCE 4.2 support was favorable, since dropping it from our test matrix brought a big reduction in our test matrix, and our developers could readily upgrade to 5.0.  Another consideration was the fact that Visual Studio 2005 would now, for the first time, include native and managed device projects, and it turned out to be very costly to support native 4.2 project types in VS2005.  The thinking was that it was preferable to have no 4.2 support in VS at all, rather than to have support for only managed project types.  Not everyone agreed with dropping 4.2 support, and we debated this internally for many weeks before making our decision.

As word of our decision got out, we began to get feedback from one or two isolated MVPs that dropping 4.2 support was not a good idea.  One of the big appeals of NETCF, they told us, was exactly that we provided such good backwards compat, and helped smooth out the changes that developers face on the underlying OS.  By dropping 4.2 support, they argued, we were undermining one of our key strenghts versus native code, and versus our competition.  For a time, we were unconvinced, since we still felt that developers could easily upgrade to WinCE 5.0, and still be able to use NETCF V2.  And our efforts with some large individual customers bore this out.  We saw several customers converting from 4.2 to 5.0, and from NETCF V1 to V2, without any major problems and seemed to be happy with the transition.  However, over time, the one or two MVP complaints became a veritable chorus, and we began to realize we may have been shortsighted.  The kicker came when we learned that many customers had committed to embedded designs with OS versions in ROM, that could not be changed easily (and in some cases not at all!) over the life of the project.  We came to realize that we were not just inconveniencing some customers, but that we were actually making it impossible for some customers to adopt our V2 runtime.   Eventually, as Whidbey got closer to RTM, and more customers actually began using NETCF V2, we began to get more requests for V2 on 4.2, and these real customer requests finally made the right thing to do crystal clear. 

It took time for this message to sink in, but eventually we realized what we had to do.  We began to float the idea internally of adding back in support for 4.2.   At first, there was some opposition, but after we laid out the actual customer feedback, internal opposition fell away pretty quickly, and we began working towards a plan for implementing support for 4.2.  Our next release was the upcoming V2 SP1 of the .NET Compact Framework, and that is the one that is targeted.  The development work (on the NETCF team) for this is already completed, and what remains is including 4.2 in our full test pass for SP1.  The SQL Mobile team still has more development work to do, and we will be working with them to integrate our schedules to that both components of this solution (the NETCF as well as the SQL Mobile parts) are ready at about the same time.

So.  Sorry, everyone, that we dropped something that some of you really valued and wanted.  From time to time, as cost/benefit dictates, we will have to make changes in our platform and perhaps modify our OS compat policy.  But, in this case, we heard your feedback, and we took action to address it -- and we hope it satisfies those 4.2 customers who want to move to NETCF V2.  Please keep that feedback coming;  as you can see, it does make a difference.