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
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