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

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


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


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 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?


I'm surprised to hear no requests around GUI.






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


Comments (6)
  1. Daniel Moth says:

    > ASP.NET is huge feature, and would consume most of my team for a major release.

    It would also probably double the amount of your "users" (ok, developers using the NETCF)

    > I’m surprised that no one beat me up for the difficulty of doing cross-process calls.

    I would, but when/if my article gets published you’ll see why I didn’t 🙂

    > Headless support is something we planned that is close to being cut.

    Now I am shocked! I am looking forward to this feature and we are in fact planning a product using it!! Please tell me "close to being cut" is a joke :-O

  2. Daniel Moth says:

    Headless support… cut!

  3. Chris Tacke says:

    I really hope you look again at headless support and opt it *in*. The CF is cool and cutting it out of an entire set of vertical markets is no fun.

  4. 1) Headless support has been a major factor for the "embedded" crowd. Cutting that off is gonna piss off a whole lot of people and make them look to form a Mono for CE project just to get the ability to run managed code.

    2) managed C++ is a huge benefit for building interop bridges for stuff that is not based on COM already. (PInvoke is just ugly and scares people away)

    3) Hosting is how we’d implement services that are written in managed code AND a means for us to implement our own limited variations on ASP.NET until you implement it or someone adapts the mono code over to the CF.

    Without these the only thing V2.0 has going for it is the COM interop – but that tool so long it’s not nearly as important as it would have been for V1.0.

  5. Dr. YSG says:

    We are trying to open up all sorts of markets within the DOD wearable computing areas, and PDA type display does not cut it for a lot of this. We need to be able to have headless support for all sorts of embedded sensor gear.

    Do you really want to through out this market?

    Especially since PDA sales are down, if we don’t come up with new ideas for PDA type devices, then all interfaces will end up on the cell phones, and Microsoft’s penetration of that market is really not so great.

    Sounds like poor tactics both on the long term and the short term.

Comments are closed.

Skip to main content