At the 2011 Build conference Microsoft announced the introduction of a new programming model for Windows as part of their shifting support towards Windows 8 and Metro apps. This new programming model is called Windows Runtime or WinRT.
What makes WinRT different is the COM-based definitions are stored in a ECMA-335 formatted “.winmd” file. If anyone else is familiar with the CLR you would know that the most common ECMA-335 formatted file structure is the CLI; .NETs common language infrastructure format which contains MetaData and CIL code. What this means is that the interfaces coded using WinRT that are exposed are stored as .NET metadata, which can be scanned over using Reflection or by cracking open a WinRT winmd file in ILdasm.
Now dynamic reflection at run time may not be everyone’s cup of tea, but by storing the calls via metadata we can happily invoke native code methods from .NET code with ease and allow much easier programmer interoperability; rather than adding additional P/Invoke code or hooking onto QueryInterface and hoping you remember the correct COM GUID.
Generics is a strong feature of .NET and a lot of work has gone into making this cross compatible in WinRT. Native C++ can use the generic keyword; akin to using the template keyword, and classes can be made generic however during compile time a lot of ‘internal magic’ occurs when creating the metadata ‘.winmd’ file. On the .NET side the CCW (COM Callable Wrapper) is being extended (although not by much) to support the additional native metadata.
When producing WinRT classes, there are some additional limitations; especially if you want your .NET code to be compatible with other languages. These limitations usually revolve around the structure of COM calls and class design, no big issue if that is what you are used to, or if you come from a Native development background. The biggest is the paradigm in .NET where you would throw exceptions if an error is encountered, in the COM world, errors are consumed by the method and a HRESULT is returned. These HRESULT values are interpreted and converted to the correct Exceptions; .NET already does this in part with ComExceptions.