WinRT and HTML Apps

Core Internals
Mubbasher Mukhtar mubbasher@ymail.com

WinRT Overview
Before we begin we have to understand the paradigm shift for Applications on WinRT
Application means traditionally a dll/component or self contained App In Windows Runtime each Application is a native component. This native component doesnt start of immediately on double click/touch as it usually does on traditionally windows system. Each Application extends the OS and becomes an integral part of the OS experience.

WinRT Overview
Each application is a COM object. We tell the WinRT what this component can do We specify what environment is required to run the component as well. Then anyone within the OS can consume it based on Contracts. WinRT provides a set of contracts that an Application can implement.

WinRT and HTML App

When we build our HTML app, the project gets a Package Family Name.
Package Family Name is:
Package Name + [Special Hash Code] If you Notice, if your solution have more than one project, than all of those projects will have the Same Special Hash Code Ill Call it Solution or Package Id

Each Project gets an ID for Installation which is:

Package Name + [Version] + [Target Platform] + [Special Hash Code] For short, we will refer it as PackId

Upon Installation of HTML app we register it with the System and this process would at least have two major registration to WinRT

WinRT Registration System

Class registration:
This registers with System What Component It is and where its located etc This registration creates some registry entries at the following location:
HKCU\Software\Classes\ActivatableClasses\Package\PackId

Now you would notice in case of Html App, the Target Platform is _neutral as its not compiled to native code.
It can run on any platform.

It have two branches:

ActivatableClassId Server

PackId = Package Name +[Version]+ [Target Platform] + [Special Hash Code]

WinRT Registration System

ActivatableClassId
It has two branch:
App.wwa It has the Values as ActivationType, CLSID, Server ActivationType =1 means it will run as an App not as In Process Activation Server Specifies which server or application host will be able to process the request App.wwa have also custom attributes branch custom attributes has the Values: ExeHost (wwahost.exe) which is capable of processing request AppObjectEntryPoint, NavigateTo => default.html Server (One Child Branch) App.wwa Two Values of interest for Now: ExePath C:\Windows\System32\wwahost.exe Permissions

WinRT Registration System

Now we have successfully configured our Application. Now WinRT can locate it and understands it. But wait, WinRT still needs to know What it can do?

Extension Registration (Contract Registration):

If an application is supposed to be launched as in this case, it must register an Extension:
Launch Contract Registration This can be found under Extension Registration:
HKCU\Software\Classes\Extensions\ContractId\Windows.Launch\PackageId\PackId

PackId\ActivatableClassId\App.wwa This provides a simple Description about the Package Package Description, Name, Icon, and Vendor Now the PackId here is a pointer and indication that the class registration is done with PackId, so if its to be launched, find details in Class registeration.

WinRT Execution Process

Execution Process
So, Now the Home start screen will iterate through all available Packages under Windows.Launch Will show the Icon
So, remember here the Icon at home screen are not a Shortcut to Exe as we usually have in our traditional Windows System

When we click or touch a tile, we Launch the Server (i.e. wwahost.exe) with security and authorizations provided in Class Registration which were specified in Application Manifest Plus standard sandbox security restrictions
We provide server with arguments i.e.
AppObjectEntryPoint, NavigateTo => default.html

WinRT Execution Process(Abstract)

2. On Click, Read Class Registration Info

3. Start and Pass arguments (AppObjectEntryPoint, NavigateTo => default.html) WWAHost.exe

1. App Details Loaded From Registry Icons are shown

WinRT Execution Process

Now Who performs this whole process?
WinRT take cares of all that process WinRT doesnt use traditional Read APIs to communicate with Registry
In fact, From WinRT there are only particular COM object through which we iterate and registry is totally abstracted. ITs advised not to use registry for any activity and the whole registration process may be moved to another secure storage .

WinRT Execution Process

Extension Catalog

WinRT Components

Class Catalog

Explorer.exe
1
Activation System
Extension Catalog

RPCSS
Service

2
4. Launch Request

Extension Registration
5. Starts

DCOM Launch

WWAHost.exe

1. Gets a list of Launch Extensions 2. On Click, Verifies ExtensionRegistration object. 3. Calls Activate on ExtensionRegistration object.

WWAHost.exe
This process provides a superset of functionality greater than that provided by the Microsoft Internet Explorer browser. Wait a second, how does WWAHost.exe knows about the content of my app?
Its just an OS binary

WWAHost.exe
In abstract view, when WWAHost starts it creates MTA (multithread Apartment)
WWAHost calls COM API, RoGetActivationFactory( CoreApplication, CLSID).

Method returns IActivationFactory*

Next call goes to IActivationFactory::QueryInterface(ICoreApplication) Results is ICoreApplicationFactory which have Run and RunWithBackground methods WWAHost call ICoreApplicationFactory::RunWithBackground( IViewProviderFactory, IBackgroundTaskFactory )

WWAHost.exe
Application Object extract parameters from the command line
Gets the server name Get the CustomAttribure (AppObjectEntryPoint, NavigateTo => default.html)

Now WWAHost.exe tells RPCSS back Im Ready NOW

And also send back the object reference. RPCSS send this object back to Activation System within Explorer.exe

Now Activation System in Explorer.exe uses standard System contracts and calls Activate on The Application Object within WWAHost.exe Application Object have a reference to IViewProvider that was being passed to it via constrctor by WWAHost

WWAHost.exe
We go through the View creation same way we did with ICoreApplication
We get ICoreApplicationView We load WebInstance inside WWAHost, WebInstance::Load
Application Object (ICoreApplication) send ICoreApplicationView and ICoreWindow to WWAHost for rendering
Application Object calls WebInstance::Load (AppObjectEntryPoint => default.html) Finally Application Object calls WWAHost::Run, to render the Page. Yupiiii and we are done.