.NET Compact Framework; Past, Present and Future

After the holiday break things got really busy around here, and again I feel like a human interrupt service routine. I don't have time to read everything I need to, let alone write. I apologize for dropping off, and thanks for the feedback on my previous blog entries.

Here at Microsoft we have a sophisticated process for conducting market research. The output of that process is a carefully crafted set of requirements for each release, with an accurate prioritization, cost and risk mitigation model for every feature. This is then turned into a detailed milestone schedule with clear exit criteria for each milestone. With near perfect planning, projects then proceed like clockwork.

I wish.

This is as believable as some of the conspiracy theories about us, that, while entertaining to read, would require a degree of organization and coordination that we only dream about. Software is complex. We do our best.

One of the unfortunate side effects of very large software projects that ship on a global scale is that we think "we're done" a rather long time before we can release the product. We're not really done, we just stop adding new features and changing things and enter a cycle of testing and fixing, and testing, fixing, more testing and fixing.

The .NET Compact Framework Version 2 is entering the final testing cycle now. We are starting to plan for the next release. I would like to ask for your input into the evolution of the product, and I would I encourage you give the Beta 2 release a good shakeout as soon as it is available. It is a goal of ours to allow apps written against Version 1 to run unchanged against Version 2. With over 5000 public APIs, this is a tough problem but I feel good about our progress. I encourage you to report app compatibility bugs (and all other bugs) to us and we will try hard to fix them for the final release. 

Let me share some history on how we "planned" the .NET Compact Framework product evolution, starting 5 years ago. We really were only certain of a few things:

  • There was a hole in our product line in the "sweet spot" between C++ and Visual Basic. Visual Basic offered the productivity of modern typesafe, garbage collected languages, but was tuned for business applications. C++ offered flexibility and power but not productivity.

  • COM and OLE , while enabling rich, graphical multi-vendor in process extensibility, were relatively complex technologies to master.

  • Each of our language offerings had a different "standard library".

  • The diversity of products and requirements built on top of Windows CE, and the rapid pace of embedded and mobile hardware evolution had created a situation where Windows CE Win32 API compatibility across operating systems versions and across products was a source of developer frustration.

  • A healthy developer community is very important to the success of any platform technology.

  • The world didn't end in 2000 and gasoline generators were going on sale.

The list of things we didn't know was much larger, including:

  • What should the target size of the .NET Compact be? J2ME was tiny, but was it useful? Should we aim to enable simple games on 20MHz processors with 32K of RAM, or business applications on 200Mhz processors and large amounts of storage?

  • How big would the apps be? Where is the sweet spot for performance optimization? Should we shrink the footprint, or work on scalability?

  • How much should we worry about API consistency across platforms?

  • Would people want a rich visual design experience, or would command line development be OK?

  • How important was Win32 interop? Would applications be mixed C++ and C#/Visual Basic?

  • Would everything be running in a browser frame by 2005? Did that make sense on devices?

  • How big would screens be? Would the phone kill the PDA? Would the portable game kill the PDA?

  • How fast would wireless networks evolve? What standards would win?

  • How much higher could pets.com go? Had the entire world gone crazy?

These are the decisions we made that I feel have served us well:

  • Compatibility was key. We would not have a different executable file format. We would enable rich protocol level interop whenever possible and we would set a very high bar for API level compatibility with the larger .NET and across product and device versions. This decision had an unseen cost in terms of product footprint that we really didn't understand until later in the cycle, but I still think the net value to customers was very strong.

  • Great visual design tools were important.

  • Rich, accurate emulators were important.

  • Remote source level debugging is important.

  • Databases were important.

  • Quality was important. We were asking people to make a bold step and bet on something new; it had better be great.

We learned a few lessons:

  • Our hardware targets we're too low, which led to low estimates about how large and complex applications would be. The first applications we saw really pushed the CLR to the limits, and we had not sufficiently optimized for "upward" scalability.

  • We cut a few things, which, in retrospect, seem downright silly: DateTimePicker, MonthCalendar. Actually, I've now use the term DateTimePicker in the team to mean "any silly feature we cut", usually in the phase "are we sure that's not a DateTimePicker?"

  • More people relied on serial ports than we thought. Also, MSMQ.

  • Interop was super important. Our P/Invoke support was not rich enough.

  • Windows Forms abstractions would not completely replace and hide the underlying Windows implementations, and many customers wanted to live in hybrid world. Our Windows Forms extensibility was not rich or formal enough.

  • Embedded developers are very smart, and like to write very complex applications.

  • ActiveSync as a debugging and deployment transport needed some attention.

  • Logging, diagnostics and performance instrumentation are very important.

  • Games are important. And fun too.

After Version 1, we released SP1 which added support for Smartphone. SP2 included significant performance gains around XML, ADO.NET and resource management, in addition to support for landscape/portrait switching. SP3, just released, is a fairly minor bug fix release.

In Version 2, we have added the ability to call COM components, enhanced P/Invoke, added to the built-in Windows Forms feature set and enhanced extensibility, added support for DirectX, MSMQ/System.Messaging, ResultSets, generics, and did lots of performance work (and fixed more than a few bug along the way).

Looking forward at the areas where I think we can still do better, the big one that see is around making it easier to deal with transiently connected networks. It's still way too hard to write robust networked apps on devices. To start with, it’s hard to know what network you are on and what the performance and cost of that network are. It’s hard to “switch” networks. Oddball networks like IrDA, Bluetooth and SMS/MMS are poorly integrated at just about every turn in the road. Even 802.11 and GPRS don’t work as seamlessly as they should.

The only really common quality that the networks we use on devices have is that they are often crummy. Networks can “disconnect” and tear down TCP connections, they can “disconnect” and allow TCP connections to stall for very long time and they can just “go away” for while.

This is one area that we intend to work on for V3, by leveraging the work that has been done on the WS-* protocol suite, and adapting it to a device environment.

Of course, performance is always important, and we will continue to make improvements.

I welcome feedback on these priorities.


Finally, no blog entry from Mike would be complete without a shameless plug for www.zintel.net. I've posted one new photo that I'd like to share:








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

Comments (12)
  1. Chris Tacke says:

    CLR Hosting, CLR Hosting, CLR Hosting….

  2. Kevin Daly says:

    Very cool photo by the way.

    One thing you didn’t mention was the XML support in v1.0, which is basically unmentionable (although it basically just carries on the unmentionableness of the XML support in eVT): "Oh, so I can’t use XML serialisation? Never mind, I’ll just XPath and get at the data directly..No XPath? Oh. Damn."

  3. Jeff Parker says:

    Mike, one thing I have never heard of or found out about and sorry if it seems a silly question, but will the compact framework be released right along with the .net framework 2.0 or will it be a seperate release? I am talking more along the lines of timing. Also will VS 2005 be one of the main developer environments for the compact framework?

    No one has ever been clear on this yes or no. I do not like to think of the compact framework as something different. Yeah we have different controls but everything basically works the same. One of the things I have loved about this ever since the compact framework has come out is 1 dev environment, one language C# for me, and one frameowrk. Which has always been nice. Ever since .net was released it has been like one brain one methodology in programming if you are doing windows, web, or compact, and I have just been having a hey day as a programmer, .net is like being is kid in a Candy store because I can basically do anything.

  4. Daniel Moth says:


    Yes NETCF 2.0 will be released, like .NET 2.0, as part of the Whidbey package that includes VS2005.

    In addition, this time round NETCF will also have a standalone SDK (like its big brother always had) so 3rd party tools could be developed for targeting it (today it is just VS.NET 2003 Pro and above).



  5. Kevin Daly says:

    I’m surprised there’s been very little buzz about the standalone SDK (I’m also horrified at the repetitive vocabulary and the odd missing word in my previous post, but I digress).

    At the time the Compact Framework was originally released, the fact that development was only possible with VS 2003 Professional was not exactly met with shouts of joy, in view of the price disparity with the free embedded Visual Tools. While nobody has a right to expect a free lunch (on the other hand they’re always welcome), a good argument can be made that there is as much software for Windows Mobile as there is because the previous generation of tools were *not* just accessible to the "Enterprise" market (I must remember to make a long, insulting blog post about the universal obsession with the "E" word soon), but to many skilled and innovative developers, including some from countries with very low per capita income.

    So anyway, in my Never-Previously-Known-To-Be-Humble opinion, the standalone SDK is a key element in the future success both of the NETCF and the Windows Mobile platform (does anybody know by the way whether it will include the emulator? – that would be very nice). There’s no reason why tools of the SharpDevelop variety could not be created for the NETCF, which would give us back the breadth of access we had with eVT. I’m all in favour of Visual Studio being the *best* environment for NETCF development, but it’s good to have something for everyone else as well.

    Which brings me back to my surprise that there has not been more comment on what I see as a crucial development. Part of this may be due to the fact that developers seem to be contributing less these days for some reason to the general enthusiast Pocket PC sites, compared with all the other content of the "Look, shiny!" variety (OK that was elitist and I’m very, very sorry. Honest.)

  6. Andy Wigley says:

    I welcome the intention to focus on making it easier to deal with transiently connected networks. New APIs to allow easy switching between networks would be great – at present it’s not at all easy to switch between an 802.11 and GPRS network, on devices that support both.

    Kind of in the same vein – one goal of .NET CF 3.0 has to be some level of compatibility with Indigo. In general, I’m not convinced that the goal of compatibility with the desktop developer’s ‘way of doing things’ is that important to us on devices, but the unified messaging API that is Indigo is going to change the way developers look at distributed applications, and devices have to be a part of that.

  7. In the late 90s, I worked on the IrDA infrared connectivity technology. My team built the protocol stacks…

Comments are closed.

Skip to main content