//build–WinRT internals

Matt Merrys’ session on the internals of WinRT was interesting and worth watching if you’re interested in understanding WinRT at a deeper level, at the same time it was a little thought provoking in terms of why some of the decisions were made and what the implications are. Whilst you don’t need to understand what’s going on under the hood to write a Metro Style app, its interesting to know and will likely be helpful to understand when things go wrong / debugging.

WinRT is implemented using a modified version of COM, it introduces the IInspectable interface which all WinRT objects implement, the interface derives from IUnknown adding the following methods:

  • GetIids() – returns the interfaces that the object supports, in classic COM you needed to know what interface you wanted to QI for
  • GetRuntimeClassName() – returns the type of the object, this is used by Javascript to get the fully qualified name of the WinRT class
  • TrustLevel() – returns the trust level of the WinRT object

Activation of WinRT objects is very similar to DCOM activation and happens via RPCSS, apps can be in-proc or out of proc (server), which are hosted by wwahost.exe, sound familiar?! Wwahost.exe is the app container, which is effectively a sandbox for the application with a security context. Apps can run in single threaded or multithreaded apartments – though its not clear how that is controlled.

Since activation is performed in a DCOM like manner, meta-data describing where the binaries are located for a given app type is required by the run-time, Microsoft chose to put this in the registry ala COM style. The registry entries are written at deployment time, when running through the VS debugger this happens when you run up an app. Deployment effectively involves running the manifest through the deployment engine which writes entries into the ‘Extension Catalogue’ and ‘Class Catalogue’.

The model is interesting in that in many ways it does perhaps feel like a bit of a move backwards after being immersed in .NET for a number of years now, I say that having been a C++/COM developer for a number of years and at the time thinking COM was the best thing since sliced bread, but the world has moved on. Whilst to a large extent much of this doesn’t effect the apps that are written, there are some implications. Error handling may be less rich, lets face it HRESULT’s are not the best way of passing back error information to the caller, especially when all you get is an E_FAIL. The use of the registry is not one I’m a fan of at all, I personally favour XCopy deployment where possible which is more frictionless approach and less error prone whilst making patching easier. The registry has been a source of pain to me over the years. All calls into the WinRT from managed languages will be via .NET introp which of course doesn’t come for free, though the API does look for the most part like a .NET API when consumed from managed code.

WinRT looks like a rich set of API’s that should enable some great apps to be written. The cross language binding for C++, .NET, Javascript is a good move, though in reality apps written in any of these will need to be ported in order to run them on other platforms such as iPad, it won’t just be a re-compile. The interop performance hit for managed code apps should not be noticeable in the big scheme of things assuming that the WinRT API’s are all ‘chunky’ or async which they appear to be with an initial look.

The bottom line is that the success of the platform will be defined by the apps that are built for it.


~ by kevinsmi on September 17, 2011.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: