I received the following comment from Mike Dimmick:

“My other issue has to do with supporting the same component on multiple platforms - I now have an application (it's a thin client) which needs to be built for Pocket PC 2000, PPC 2002 (for the emulator), and two custom CE platforms. This is a major pain right now due to two project files (one of the custom platforms is CE 4.2 on ARMV4, necessitating eVC 4 if I want to debug); setting up an automated build is irritating. I could set up a NAnt (or similar) external build process, but I'm concerned about the environment getting out of sync with the main build process. Will Whidbey help me out? Will I even be able to develop for Pocket PC 2000? (Will I be able to port my hybrid ATL/MFC application, which would have been MFC-free except I needed to reuse a component that was built with MFC and couldn't get approval to rewrite it...)“

I'll respond with the bad news first.  “Whidbey” will only support Pocket PC 2003 and better.  It will also only be officially supporting CE5.0 or better, although there may be a whitepaper released detailing how to manually configure “Whidbey” to make use of a CE4.2 SDK; however, this will not be a supported or tested scenario.

Now for the good news.  For the platforms that “Whidbey” does support you will get a lot of help targeting multiple platforms.  This support comes in the form of #ifdef'ed code generated by the wizards, varying levels of support in the ATL headers based on the OS components list in the SDK's ceconfig.h, and runtime detection and loading of specific API's in the runtime libraries (e.g. COM vs. DCOM, AYGSHELL vs. class look).  We also looking into doing work for specific new features coming in the next releases of the Pocket PC and SmartPhone platforms, which should be dynamically enabled for those platforms, but turned off for older platforms.

I also received the following comment from David Mooney, which I forward to various folks in my group looking for guidance in how to respond:

...I am still using EVC3. The reason for this is that Pocket PC 2000 and 2002 devices still dominate my world of developing applications for rugged Pockets PCs. Symbol and Intermec are still selling largely CE3/PPC2000 and 2002 based devices and there is a significant installed base of these devices...The only tool for these devices is EVC3, a tool roughly equivalent to the mid 90's VC5.

I'd love to use VS.NET 2002, or even EVT4. I can't wait to use Whidbey. But for the foreseeable future I'll be using EVC3 because of the abundance of CE 3.x based devices.

I'm am very disappointed at Microsoft's lack of support for CE3 devices. There has never been a service pack for EVC3 and all the new tool development has been for 4.x devices only. It is even more disappointing because of how quickly Microsoft quit supporting new tols for CE3. PPC2002 is less than two years old. I assume the company line is that C# can serve most needs. However, I don't think the impracticality of installing the CF on any number of devices with nothing but a serial connection is being considered.

While I don't have the official response yet, I'll give you my personal one, which is that I agree that historically we've done a poor job of providing and supporting developer tools for CE platforms.  The current team is working very hard to make sure our story going forward is much better, and we've even cleaned up the problems created between eVC4.0 RTM and it's first two service packs with eVC4.0 SP3; however, our team simply does not have the resources to backport the fixes done in eVC4.0 RTM through eVC4.0 SP3 to a eVC3.0 SP1, nor do we have the resources to support Windows CE 3.0 based OSes from “Whidbey”.  I know this doesn't help out anyone who is currently using eVC3.0, but we have taken these issues to heart and we are deterimined to ensure that these issues do repeat for folks targeting Pocket PC 2003, Smart Phone 2003, Windows CE 5.0 and beyond.  “Whidbey” will be serviced appropriately, and we are working to raise awarness with the OS teams about the need for future releases of the OSes to remain compatible with previous releases of the developer tools.