I am a developer at Microsoft and work in the .NET Common Language Runtime (CLR) team. For the last 4 years I have been working on virtual machine technologies on a variety of form factors including desktops (Windows, Linux), tablets (Win8), gaming-consoles (Xbox 360), mobile devices (Windows Phone 7, Windows CE, Symbian).I have worked on various core pieces of the runtime including Garbage Collector, memory manager, platform abstraction layer, runtime-performance, etc.Before working on .NET I worked on Visual Studio Team Foundation Server, Visual Studio Team System, Adobe Framemaker, Adobe Acrobat, Texas Instrument's Code Composer Studio.
If you are following the latest Windows Phone stories than you have surely heard about the .NET Compact Framework (NETCF) which is the core managed runtime used by the Windows Phone 7 programming model. This is an implementation of the .NET specification that works on devices and a disparate combination of HW and SW.
In case you are hearing about NETCF for the first time, then hopefully this post will help you to understand it’s architecture and how it is different from the desktop .NET.
At the heart of NETCF is the execution engine. This contains the usual suspects including the JIT, GC, Loader and other service providers (e.g. Marshalling that marshals native objects to managed and vice versa, type system).
The entire Virtual machine is coded against a platform agnostics Platform Abstraction Layer or the PAL. In order to target a platform like say Nokia S60 we implemented the PAL for that platform. Stringent policy of not taking any platform dependency outside PAL and ensuring in PAL we only use features that are commonly available on most modern embedded OS allows NETCF to be highly portable. Currently the PAL supports a variety of OS and processor architecture. The ones in Red are those that are used for Silverlight, the others are available for the legacy .NETCF 3.5.
The other system dependent part is the JITter which compiles the MSIL into the platform dependent instructions. For every supported processor architecture there’s a separate implementation of JIT.
This entire runtime is driven by a host. E.g. for Silverlight on S60 it’s the Silverlight host running as a plugin inside the Nokia browser, on Windows Phone it’s the Windows Phone task host. These hosts uses the runtime services to run managed code. The host interacts with the runtime over the hosting interfaces.
Managed code can either be the framework managed code like BCL and other Silverlight/XNA framework managed code or the user code that is downloaded from the web/application-store. Even though the framework managed code can interact with the underlying system including the execution-engine and the OS (via Platform-Invoke) the user managed code is carefully sandboxed. If you see the arrows moving out of the user managed code it is evident that user managed code can call only into the framework managed code (which in turn can call into the system post security verification). User code is not allowed to access any native resources (including P/Invoke).
The host knows about the UI and it’s rendering and uses reverse Invoke to call into the managed code. E.g. if a user clicks on a XAML button the Silverlight host using the XAML object tree and rendering logic (hit-testing) figures out which object got clicked on and it uses reverse-pinvoke to call into the corresponding managed objects (which provides the event handler). That managed code is then verified, security checked, jitted and run by NETCF.
NETCF is highly portable. As far as I know it’s one of the very few (or is it the only one :)) runtime shipping out of Microsoft that supports Big-Endian processor architecture (Xbox360 uses Big-Endian processor). It is designed for resource constrained devices and is battery friendly. For many time-space trade-offs it tilts towards conserving space (e.g. Code-pitching which I’ll cover later) and at the same time works well on Xbox360 running high-end games. The list of processor/OS I have given above is just illustrative and it actually works or there are POC (proof-of-concept) of it working on really esoteric SW+HW combinations.
Some CF Facts
Just sometime back I posted on the MIX 2010 announcements. One of the major aspects of the announcement was
“The application model supported on Windows Phone 7 series will be managed only and will leverage Silverlight, XNA and the .NET Framework”
That’s a mouthful and includes 3 framework names in once sentence :). This was already disclosed and has resulted in some flutter over the web and twitter. Let me try to explain how these 3 interplays in the application model with the following diagram
First of all the application model allows users to write only managed code (to repeat native code is not allowed). That means they do not have direct access to any native APIs and cannot use platform-invoke to call into native user or system code. So all resources including phone capabilities have to be accessed using the various managed APIs provided.
Two Flavors of applications (XNA and Silverlight)
There are 2 variants or flavors of applications users can write, XNA Games and Silverlight applications. Obviously the former is for writing games and the later is for your typical phone applications (nothing stops you from writing a Silverlight animation based game though). So you cannot mix-match SL and XNA UI in the same application.
However, do note that the traditional NETCF development using WinForm based UI is not supported.
Common Services available to both
That said, beyond the UI rendering and controls there is the common services which both SL and XNA applications can use. This includes all the phone capabilities like microphone, location, accelerometer, sound, media, networking, etc... Some of these features come from SL and others from XNA but land up in the common pool usable by either types of applications.
Core Runtime is .NET Compact Framework 3.7
The core runtime for both SL and XNA applications is .NET Compact Framework (henceforth called NETCF). This is the team I work for. .NETCF is a highly portable and compact (as in smaller size and footprint) implementation of the .NET specification. It is designed to run on resource constrained devices and on disparate HW and SW configurations.I will have a post later on the detailed architecture or .NETCF.
Over the last two years a lot of work has gone into .NETCF to scale it in terms of features, performance and stress to meet the requirements of Windows Phone and other newer platforms on which it is being targeted. We also added a lot of features which I hope you will enjoy. Some of the features is just to reach parity with the desktop CLR and others are device specific and not available on the desktop.
Over this blog in the course of the coming months I’ll try to share with you what all we did to reach here.
In the comments of my previous post Windows Phone 7 Series Programming Model and elsewhere (e.g. twitter, WP7 forum) there seems to be a lot of confusion around how NETCF 3.5 compares against the new WP7 programming model powered by NETCF 3.7. People are asking why some API got removed from 3.5, or is 3.7 a subset of NETCF 3.5 as they are not seeing some familiar 3.5 APIs.
First I’d urge you to go visit the Windows Phone 7 Series Programming Model to see what it offers.
Essentially NETCF 3.5 can be broken down to
Now each of this has been updated (in order) as follows
So the runtime is hugely updated (and hopefully you’d feel the improvements, especially in performance).
For #2 and #3 the level of difference is same in magnitude as you compare WinForm with Silverlight on desktop. They are simply two different programming models.
In case you hit a 3.5 API that’s missing then it’s either because it’s (a) WinForm based API that got totally replaced, or (b) a BCL API that the Silverlight profile doesn’t support. The workaround is to search for how to do the same thing in Silverlight (e.g. use XDocument instead of XmlDocument). In some cases you’d get into situations where there is no direct alternative. E.g. there is no P/Invoke and if your code say P/Invoked to get data from a bar-code scanner you cannot do so now.
Also keep in mind that the bits available right now is just early preview bits and subject to a lot of change. The whole purpose of having CTPs is to hear our customers and ensure we use the remaining time before release in fixing issues that helps our customers the most. Hopefully some of the gaps will get closed before the final release.
Today at MIX 2010 we announced Silverlight beta for Nokia S60 phones. Go download the beta from http://silverlight.net/getstarted/devices/symbian/.
Currently the supported platform is S60 5th Edition phones and in particular the 5800 XpressMusic, N97 and N97 mini. It works in-browser and only in the Nokia default web-kit based browser.
Silverlight on S60 uses .NET Compact Framework (NETCF) underneath it. I work in the dev team for the Execution Engine of NETCF and I was involved at the very beginning with getting NETCF to work on the S60 platform.
NETCF is extremely portable (more about that in later posts) and hence we didn’t have a lot of trouble getting it onto S60. We abstract away the platform by coding against a generic platform abstraction layer (PAL), but even then we had some challenges. Getting .NET platform on a non-Windows OS is challenging because so much of our code relies on Windows like functionality (semantics) which might not be available directly on other platforms.
As I was digging through emails I found the following screenshot that I had sent out to the team when I just got NETCF to work on the S60 Emulator…
As you can see the first code to run was a console application and it was not Hello World :). We have come a long way since then as evident from the touch based casual game running on the N97 shown below
Today is a very big day for me and my team. The stuff we have been working on is finally went live on stage MIX 2010.
Windows Phone 7 is easily the most dramatic re-entry/reset Microsoft has undertaken in any field it’s in. We announced the phone in MWC and the reception it got was phenomenal. However, in the new connected devices world, the application platform+market story is as or more important than the device itself. Today at MIX we just disclosed details of that.
Our team was involved with building the IDE, the emulator and the core .NET runtime that powers the applications. So watch out and in the coming posts I’ll deep dive into these areas.