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
WinRT itself is language neutral. Also, WinRT has got a language neutral type system.
- In some languages, you may even consume some WinRT types ‘as is’.
- 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.
- Full list of WinRT <-> CLR mapped types table is here.
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
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.
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++).
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.
- When CLR does the mapping of WinRT types to CLR types, the WinRT type definitions are made private by the CLR. I may explain the actual mapping process in another post
- You can access WinRT XAML library, or can use the WebView as the front end when you use C# for your metro style apps.
That is about WinRT for a good start.