.NET Compact Framework; Past, Present and Future (Follow Up)

Thanks for the feedback to my request for V3 guidance. A few thoughts:

Hosting

The idea that you could add managed extensibility to a native application always seemed cool to me. We were actually building hosting into V2. The plan was that the COM interop and marshalling would become the basis for hosting. Unfortunately we ran out of runway and cut the hosting part. One of the reasons is that, besides Mike thinking it was "cool", we couldn't seem to figure out what you would use it for. Maybe you can help.

More Love for Embedded Folks

We actually did something really cool for the embedded crowd in V2, but we don't talk about it much because we're slightly embarrassed that it was even necessary. We had two JITs in V1. The first was highly portable (simple, 'C') but, er, slow. The second was decently fast, but had lots of complicated ARM assembler in it. We tried and failed to port it to other processors, and we ended up shipping the simple JIT on everything except ARM. You can now impress your friends at parties by explaining why methods > 64K fail to JIT on the (x86) emulator, but work fine on the (ARM) device (different JITs). After we shipped, we gained a lot of knowledge on how real world applications behaved, unified the two architectures, and successfully ported the new JIT to all processors. V2 is faster for ARM, but way faster for everything else. In the process, we simplified our code a lot and laid the groundwork for more optimizations in V3 on all processors.

Two relatively common requests we get from embedded developers are "less" (componentization) and "more" (remoting, web services server, more). I want to set expectations around this, even if it does disappoint. We support an ever growing matrix of operating systems and devices, and we try very hard to make sure everything works on everything, always. Additionally, each .NET Compact Framework release becomes a new "servicing train", for which we need to be prepared to release a patch or and service pack. The testing matrix starts with .NET Compact Framework release x processor x Windows CE / Smartphone / PocketPC release. Given that the platform builder crowd runs on a huge assortment of hardware, and PocketPC and Smartphone OEMs generally request features and operating system customization to target their platforms, there is a hardware and driver component in the matrix too. And the C# and Visual Basic compilers change from .NET version to version. And Visual Studio itself has design time components that make certain assumptions about the class libraries they target. Don't forget SQL-Mobile, it too changes from release to release. My test manager, Paul, gets really stressed out when I suggest we should allow developers to mix and match class libraries.

I call that paragraph "let me share my pain". This one, "that bug's a feature". We are able to release SPs and get them to deployed to devices much more quickly if we can make certain assumptions about the hardware, drivers and operating systems under us, and retain the ability to patch directly without going through the platform builder channel.

One feature that we have been working on for V2, and I am hopeful that we will complete, is the ability up upgrade Smartphones in the field using the upcoming Windows Mobile Magneto's "Image Update" feature.

As for the "more", that embedded developers ask for, I'm surprised that no one beat me up for the difficulty of doing cross-process calls. I am hopeful that MSMQ will be part of the solution to this. ASP.NET is huge feature, and would consume most of my team for a major release. I hear you that we made terminating inbound Web Services connections "pretty hard" for V1. We did add support for XML serialization in V2.

Headless support is something we planned that is close to being cut. We're going to look at this again.

Free

We're adding support for the SDK in V2. But my real goal is to add enough value that people are willing to pay. eVC and eVB were certainly priced right, but they also suffered from a lack of ongoing attention that was in no small way a result of the fact that they were free. Part of the reason .NET is a quality offering is that we are running it like business, judging ourselves on adoption, satisfaction and sales.

Speech

Speech is cool. I want to do speech. We looked at wrapping SAPI in V2, but SAPI doesn't handle multiple applications in a coordinated way very well and the solution would not be satisfactory.

Native Interop

I thought we did pretty good for V2. Let me know where the holes are.

Managed C++

Does this have any value over native C++ / C# hybrid apps?

Other

I'm surprised to hear no requests around GUI.

Thanks.

Mike.

This posting is provided "AS IS" with no warranties, and confers no rights.