Raf's laboratory Raffaele Rialdi personal website

The new Windows start screen 8 shows a number of tiles that may look like a revamped version of the old shortcuts:

But appearances can be deceptive and tiles are not shortcuts and they do not launch directly the application process.

The crucial point is that Windows Runtime (WinRT) is the layer of the operating system that allows an object-oriented dialogue between the application and other applications or the operating system. In an object oriented environment, the dialogue is obviously accomplished through interfaces.

WinRT, unlike COM, establishes standard interfaces that allow dialogue with applications. I'm talking about Metro Contracts.

When a user "tap"/"click" on a tile, Explorer.exe uses the "Launch" contract that every Metro application created by Visual Studio implements automatically.

For each contract Explorer knows the list of applications that implement it, by simply looking into the registry (HKEY_CURRENT_USER\Software\Classes\Extensions that is a per-user and not per-machine branch).

As far as I could understand, Launch contract interfaces are Windows.UI.Xaml.IApplication and Windows.UI.Xaml.IApplicationOverrides that are implemented by the class "Windows.UI.Xaml.Application" that is the base class for the App C# project class. At the moment MSDN does not provide any details about these private interfaces.

In addition to "tap"/"click" actions, an application can be activated as a result of other contracts such as Search or Share. For example our application may apply to provide the list of files with a custom file-format that contains a certain keyword.

When the user uses the Windows "search charm" to find the word "Raf", Explorer shows the list of applications that implement the Search contract. At this point the user chooses an application that in turn is activated in order to perform the search. It is important to note that the application can be activated multiple times, once for each contract, and each activation is served in the same process but in different threads.

The share contract is similar: Explorer shows the list of applications that can share an element and, once the user has chosen the application to share the element with, it is activated.

The activation

The focus is now on the activation mechanism of the application. Let's examine the Launch contract which activates the application as a consequence of the "tap"/"click" action in Explorer.

On the "Start Screen" Explorer shows all applications whose packages are registered in the system by adhering the Launch contract. As soon as the user request the application launch ("tap"/"click"), Explorer uses the previously examined informations in the registry to start the activation of two WinRT objects used internally by Windows: Extension Catalog and Extension Registration that use the Windows registry  for persistance (Extension Catalog and Class Catalog).

Explorer uses the RPCSS (RPC system service) to activate the application. As RPCSS is exposed to the network and has a large attack surface, RPCSS runs with low privileges (network_service) and with a integrity level system that prevents other processes with a lower integrity level can affect RPCSS in reading or writing.

As we have been told during the build conference, RPCSS maintains the list of activated objects, and can create a pool of objects (anyone remember COM+?) via IObjectControl.

To start the process (real or surrogate), RPCSS service uses "DCOM Launcher" that has higher privileges (localsystem). The "DCOM Launcher" service reads from the registry the informations related to the class and the host process and finally create the application process.

Once in memory, the application process performs a series of steps:

• initializes the current thread as MTA (Multi Threaded Apartment) which allows concurrent COM requests.
• create the "Core Application Object" (Windows.ApplicationModel.Core.CoreApplication)
• invoke the Run method on the "Core Application Object" (passing IViewProviderFactory as parameter, that is the factory used to create our application View)
• the Run method also registers the "Core Application Object" in RPCSS which in turn returns it to the Extension Registration Object of Windows Explorer

This is the crux because from this moment on, it's possible to "talk" with the application process using the ABI (Abstract Binary Interface) pattern. No more calls to "C-like" API but an entirely object oriented runtime dialogue.

COM was based on the same concepts but there are important differences and not only with regards of the type system or asynchronicity but, first of all, for the activation contract. The mechanism that I just described enables the activation of a generic application while DCOM did not establish a rich ABI to talk with a generic application.
Much more than applications, these processes are pseudo-COM Servers where the dialogue happens via ABI, and the application is a WinRT object itself.

Explorer activation system performs a cross-process call to the "Core Application Object" of our application that will receive notifications about requests for activation, suspend, resume and termination.

For each activation request (which may be one for each WinRT contract the application do support), the system create a new STA thread (Single Threaded Apartment) where the code related to window management, search, share, etc.. will run in.

STA means that all calls made from outside our code will be queued and therefore we should not take any precaution for any concurrent calls (setting all of that aside, if we internally use asynchronous calls we must handle the asynchronicity problem as we have always done).

Tool

How to debug/understand the activation mechanism? Matt session is the best starting point. In his session Matt uses a tool that is not publicly available, but thanks to his suggestions I rewrote a new tool that I published on http://winrt.codeplex.com (including source code) and adds some useful features that I'll summarize here:

• List shows all package system
• Allows you to launch the application with the debugger attached.
• The force suspend/resume an application
• Terminates the processes that make the host of our application

In Codeplex project page there are also a number of command line examples.

The tool is also useful for those who don't want to do deep diving of the internals of WinRT but needs to trigger suspend/resume or terminate the application.

Conclusion

Activation is the process that best represents the power of WinRT and the real Windows 8 innovation. You can't get rid of Metro applications as a mere platform that allows to run web applications on the client. WinRT is not a "PhoneGap" Microsoft release.

The .NET Framework pioneered the interoperability between languages, allowing a very large degree of freedom for developers. WinRT continues this way by allowing an efficient mix of native/managed/scripting languages required to fully exploit the capabilities of the low-level functionalities in the operating system.

With Windows 7 Microsoft created Windows API Codepack to interoperate between managed languages and the operating system. Thanks to WinRT, this wrapper will soon be useless and interoperability much easier and performant.

There are still many things to see such as asynchronous calls and security … stay tuned!