5 points developers should know about WinRT/Windows 8

By Anoop Madhusudanan

Most of us already started developing for WinRT, so it make sense to have a better understanding of the run time. I am listing down few points with respect to WinRT, mainly from a developer’s perspective.

1 – WinRT is a new collection of COM objects, native to Windows

Here are some quick points about WinRT

WinRT is native, and all WinRT objects are unmanaged and use COM as the base.

WinRT objects implement IUnknown and ref counting.

WinRT objects wraps a new XAML UI system, along with Win32 APIs. It consumes tons of Win32 APIs (Do dumpbin on a WinRT library) . The new set of XAML libraries are purely native, don’t confuse them with Silverlight or WPF though the terminologies remain same.

As WinRT is COM and hence it is more closer to the Operating system, it is easier to write language bindings (Projections) for WinRT.

A projection is a way of expressing WinRT in each language. More about this below

Just in case you havn’t perceived it yet, WinRT world is totally different than the managed .NET world.

WinRT libraries are built ground up using these new set of WinRT objects, and are kept in the Windows* namespaces. Eg. Windows.UI, Windows.Media, Windows.Networking, Windows.Security, Windows.Devices etc.

2 – WinRT is not exactly your mama’s COM

You don’t need to work with the crappy old COM style, even while developing applications in C++. WinRT provides a higher level of abstraction, based on COM. Win RT implements multiple features on top of COM, including

A Subscriber/Publisher model implemented using .NET inspired Delegates and events. In ‘old’ COM, this was done using events/sinks

Parameterized interfaces or PInterfaces (some what equivalent to generics), and this can be projected if the language supports them.

WinRT components don’t implement IDispatch

3 – WinRT can be accessed from multiple languages/platforms

In some other languages (like C#), WinRT types may be mapped to equivalent language types. For example, in C#, WinRT’s IIterable<T> is mapped to IEnumerable<T> – where CLR will take care of the mapping.

In short, you can ‘project’ WinRT to multiple languages. The language run time will take care of the Garbage collection implementation. All WinRT components implement IInspectible interface for projecting itself to other language environments.

4 – Though WinRT is unmanaged, it has got Meta Data

You might be thinking, if WinRT is so unmanaged, how we can call into WinRT from other environments, especially from the managed world without old techniques like P/Invoke?. In fact, Windows Runtime libraries are exposed using API metadata stored in .winmd files. You could find the winmd metadata corresponding to the WinRT libraries.

The format used for exposing metadata is the same as what is used by the .NET framework or Ecma-335 spec (Secret : WinMD files follow the same format of CLR assemblies though they don’t have any IL. Winmd files are just the definitions of the API. The implementation, as discussed, may be managed).

The underlying binary contract makes it easy for you to access the Windows Runtime APIs directly in the development language you choose.

As the metadata format is similar to the .NET format, you can open a .winmd file in ILDASM and explore, like this.

5 – WinRT API has got language bindings projections

As mentioned, a projection is a way of expressing WinRT in a specific language. You may also create WinRT components in one language, and may consume the same from another (because the metadata is available).

Presently, these are the projections available.

C++ Projections

Using the C++/CX (Component Extensions) which does compile time bindings and compiles the code to a native image. As WinRT is fully native, applications developed using C++ doesn’t need CLR/.NET to compile/run WinRT applications. C++/CX is a set of extensions from Microsoft for developing for WinRT (much like C++/CL was for developing CLR/.NET apps in C++).

C#/XAML

CLR is modified to support WinRT access from the managed world.

Now CLR can can map WinRT types when you use C# as the language.

When you create WinRT components in C# that can be used from other languages, you are further restricted to a minimal subset of C# (language features).

When you develop for WinRT in C#/XAML, you’ll notice multiple things.

As WinRT applications are sandboxed, you don’t have access to a lot of .NET libraries and types like File I/O. Only a minimal set of .NET APIs targeting the metro profile will be exposed

You don’t have access to the synchronous versions of a number of methods. You need to leverage the asynchronous versions in those cases.

You can access WinRT XAML library, or can use the WebView as the front end when you use C# for your metro style apps.

JavaScript Projections

Javascript projections are probably the most abstract and highest level projections for developing WinRT applications. How ever, you can’t create WinRT Components in Javascript. Also, you can’t use WinRT’s XAML library in/from JavaScript as of now. How ever, the advantage is if you are using Javascript, you could also leverage the HTML5 features for developing your applications. You can use the WinJS scripts and CSS files from Microsoft to provide the ‘metro-style’ look and feel.