Visual Studio Live New York – Day 1 (continued)

WinRT Internals. WinRT runtime is a completely new set of classes available out of the box and usable in all 3 supported Metro environments, namely CLR (with C#/VB), WinJS (with JavaScript/HTML), and native (with C++). The runtime itself is a mixture of COM-like technology and CLR-compatible metadata, but its implementation is in C++. It is not garbage collected, but reference-counted, like COM, and uses RPCSS behind the scenes (per Vishwas Lele). It registers classes and applications in registry like COM, but with slight variations.

Allegedly, all user-facing applications are hosted by an invisible “shell”. There were claims and JavaScript/HTML applications are run by Internet Explorer 10, but technically this is not true: they are hosted by special process wwahost.exe.

One can extend WinRT runtime with custom components (“WinMD components”), which can be written in any supported language and used by any other supported language, just like .NET. Certain limitations apply, e.g. if written in C#, component classes must be sealed. Components are not distributed directly to end users, but are shipped to developers. Each application must package all its dependencies with it, there is no central repository like GAC.

WinRT runtime, including custom components, is exposed to user subsystems via “projections”, which were directly compared to CORBA bindings. An intersting (and, IMO, dangerous) feature of “projections” is that they alter not only names (method named PascalCase() would be seen as pascalCase() in JavaScript), but also semantics of certain components. E.g. PropertySet collection throws when adding a duplicate key from C# and replaces existing value when doing the same from JavaScript. Obviously, this could be a source of interesting bugs.

WinRT/Metro application have a different life cycle compared to classic desktop or classic web apps. Unlike a classic web app, the application is one (ever changing) page, so there is no need to save session state, to a point that the word “view state” got completely different meaning in Metro and means screen orientation and the like. Unlike classic desktop apps, Metro apps are not explicitly closed by the user. So, instead of open and close events they receive open, “checkpoint” (suspension, going to background) and optional “resume” event. After going to the background, an application may be either resumed or killed and then reloaded. Ideally, this should be transparent to the user, so the application should save its state during checkpoint and restore it when it opens

Leave a Reply

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