Refactored Dev Tools Connectivity Stack - Josh Heitzman's Blog - Site Home

Well, it's looking very likely that we will be turning on the newly refactored connectivity stack tomorrow. The connectivity stack I'm referring to is the one which allows “Whidbey” to connect and manipulate Windows CE devices and emulator images. The last few weeks have been pretty grueling for the team, but I believe we now have a connectivity stack that we will be able to efficiently stabilize (vs. being in a state were fixing a bug was very likely to create at least one new bug due to the fragility of the code base). In the process we also discovered a few feature holes, which have either been filled in or will be shortly.

Assuming the new connectivity stack is turned on tomorrow (i.e. testing doesn't uncover any major breaks in end-2-end scenarios tomorrow), then anyone trying out our PD5 drop (community drop 2?) will be using this new connectivity stack and will hopefully notice a marked difference between “Whidbey” and Embedded Visual C++ 4.0 and/or Visual Studio 7.1.

The native debugger team has also done a ton of perf work to ensure that the native debugging experience on devices is much more performant than in Embedded Visual C++ 4.0 (i.e. it doesn't take 10 seconds to step over each line).

Also, our integration into the VC project system and the Visual Studio shell is also starting to look really good.

I don't remember eVC taking that long, unless you're talking about serial debugging. Thankfully we mostly use some devices with built-in 802.11b connectivity. Now, if we could do something about ActiveSync dropping its link (which I think is related to WINS, but I'm not sure).

The main problem I've had with device development is IDE crashes: sometimes the Platform Manager will take down the whole IDE. At other times it will apparently lock up, and you have to kill off the cemgr.exe process. Maybe I'm just not patient enough ;)

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