• WinRT …COM by any other name?

    by  • February 14, 2012 • .Net, Programming • 2 Comments

    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.

    WinRT itself is not a new programming language but a COM-based API set which can be accessed in C++, the managed languages C# and VB.NET, and surprisingly Javascript.Being based on COM the runtime can be accessed from a variety of different languages but at it’s heart, WinRT is an unmanaged API framework.

    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.


    Software engineer. Tea drinker


    2 Responses to WinRT …COM by any other name?

    1. Munch
      April 10, 2012 at 8:29 pm

      It’s all HRESULTs and GUIDs behind the scenes. The real innovation is the new type library …err…metadata. Beyond that, it’s basically COM as it _almost_ should’ve been back in 2000. Either way, I’m happy to see this work, because I loved COM, and I’m happy to see it getting some much-needed love.

    2. ben
      April 27, 2012 at 3:31 am

      The big things for managed environments are the shared types , that’s a huge amount of marshalling that is not needed when making native calls.

      Also JIT’S cans use the metadata to inline code. I just did a test and C# calling C# was 3 * faster than C++ calling C++ or C# calling C++. This is because of polymorphic inline caches which C++ cannot do with COM.

    Leave a Reply

    Your email address will not be published. Required fields are marked *