More on MFC for Windows CE and progress on MDC bits
Earlier today (well yesterday technically, since it’s now after 2am), I received the following question “Are you planning to fix the problems in MFC which mean that you can't use the traceWinMsg trace flag?”. I was not aware that this issue existed in the current version of MFC for Windows CE, but I’ve opened a bug to track this for the “Whidbey” version of MFC for Windows CE, to ensure this defect is not replicated there. I should note that we are not actually starting from the existing MFC code base for Windows CE. We are re-adding support for Windows CE to the desktop “Whidbey” version of MFC. This was done for several reasons:
- The current desktop version of MFC has had over a man-year invested in security reviews (probably more by now, that estimate is over a year old).
- It should make it easier (although not free) to share code between the desktop and devices.
- Device developer’s will benefit from the greater resources dedicated to desktop MFC in terms of fixes and broader testing on common code.
- It’s forward looking, as it should be easier to port new MFC features to Windows CE, if the desktop and the device share the same code base, then if they are divergent code bases.
It’s been a very long week, which isn't over yet, but we have made some good progress on getting end-to-end scenarios enabled for our MDC build. We had to punt on a few things we were hoping to have working for MDC, and we may have to punt on a few more, before the weekend is out.
Unfortunately, “Whidbey” generated .PDBs are not compatible with the Embedded Visual C++ debugger and “Whidbey” compatible C++ source code isn’t compatible with the Embedded Visual C++ compilers, so our ability to debug on Pocket PC 2003 and SmartPhone 2003 has been non-existent up until last week, when our new, written from scratch, device debugger first became dogfoodable (i.e. useable for internal development, dogfooding compilers and debuggers is an ‘interesting’ experience). ATL and MFC are actually running fairly well on CE OSes we build ourselves using Windows CE’s Platform Builder, which we can debug using Platform Builder’s kernel debugger for the next release of Windows CE, whose compilers are compatible with “Whidbey” C++ source. The next release of Windows CE is using C++ compilers based on the last release of Visual Studio/Visual C++, which included a fair number of breaking changes for C++ source compatibility, in order to achieve a much higher level of compliance to the C++ standard. A number of these breaking changes were with respect to C++ templates, which are used by both ATL and MFC.
The net result of the above, is that our native libraries are not currently working as well as we would like on Pocket PC 2003 or SmartPhone 2003, and there is a good chance they will not be much improved in the next two days before the code is forked (after which, making fixes becomes much more difficult). While this means we will not be able to get quite as much feedback from our MDC bits as we had hoped, this MDC push has been an awesome forcing function for establishing where we currently have some ‘weak spots’, and I’m positive this investment will result in a far better quality Beta 1 release later this year.
Josh Heitzman
Software Design Engineer
Microsoft - Visual Studio for Devices
This posting is provided "AS IS" with no warranties, and confers no rights.
