WinRT has an object model that owes a great debt to COM, which has been part of the Windows operating system since the last century. Like COM servers of old, WinRT communicates with the application via an object that they share.
Taking a standard Silverlight application, the start up class is named App by the code that generates the Silverlight project. An instance of this class will be made and the Run method will be called on it to jump back into WinRT (see the main method in the second picture). WinRT can then finish the startup and call back into the application via its OnLaunched handler (or potentially via one of the other contracts for something like Search).
App is a partial class, and the user definitions are mixed together with a generated class in the App.g.i.cs file. It is this class which is marked as inheriting from Windows.UI.Xaml.Application. The latter class is something we can find in WinMD files, the metadata files that describe the services offered by the WinRT runtime. Moreover, the classes from the WinMD files are “projected” into the various languages, making them appear much like normal classes in those languages.
If we break inside the Initialize, we can check the inheritance of the App instance. It inherits from Windows.UI.Xaml.Application which inherits from __ComObject.
Using the “Make Object ID” functionality in the debugger, we can get hold of the BaseType and check the interfaces that it supports.
These interfaces are all described in metadata which you can find on the system. Moreover, the format of the metadata is derived from that used by the CLR, so you can inspect it (and search and analyse it) using Reflector.
Application looks like this, and the following pictures show the information for the interfaces that it supports. The items supported by Application are split across these two interfaces.
There’s one other piece in the jigsaw, the IApplicationFactory interface.
Application supports two interfaces, one containing the application provided events and methods which can’t be overridden (IApplication) and one that is designed to be overridden (IApplicationOverrides). The idea is that behind the scenes, the overrides are constructed into an object that implements the IApplicationOverrides interface. This is then passed to the factory, which combines the overrides with the system provided Application object, returning a new object which will call the original methods on the non-overrides, and which will call the user supplied overrides when a call is made on one of the methods from that interface. The factory also provides the original implementation of those methods – this returned implementation can be stitched into the overrides to make calls to the base functionality (and is the inner parameter in the method signature).
Since this is hidden behind the work that the projection mechanism does when it imports the interfaces into the managed world, you can really only explore what is really happening if you use a language where the project can be turned off. There’s a really good post from Ian Griffiths here which implements the top level application object in C++ without using any of projections which covers the items above in really good detail. Go and read it now!