Ivan Krivyakov's Blog

I was a little late for the keynote @8AM, but I don’t think I missed much. I expected some kind of strategic speech, but it was yet another demo with code samples, etc., some of which failed to work.

Pete Brown, Rich Dudley and Vishwas Lele gave excellent presentations on WPF 4.5 and various aspects of WinRT. There was certain overlap (async keyword was mentioned, like, 50 times total ), but not too much to make it boring.

Rocky Lhotka tried (unsuccessfully) to alienate every web developer in the audience by saying that he does not know JavaScript and does not care, and other things like that. Nonetheless, his presentation was quite good. Everyone seems to agree that “the days of plugin-based browser applications (read: Silverlight) are coming to an end”.

They were other entertaining quotes you would probably not find on the slides, such as “google it with Bing”, and “the first thing we write is ‘Hello World’, the next thing we write is a book”. Life of Microsoft evangelists is not always easy.

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

Attended a bunch of session about WPF and WinRT/Metro. A couple of points:

Windows. The schizophrenic operating system with two start screens is here to stay. They openly admit it, talking about “desktop side” and “metro side” or even “green side” and “blue side” following the [in]famous architecture slide. I don’t mind if several visually similar ecosystems talk to different APIs under the hood, like POSIX and Win32 subsystem in Windows NT. Having several distinct visual managers on top of the same API also makes sense, like Gnome and KDE. But when everything is different, from input methods to security model, it can hardly be called a cohesive product, IMHO.

Big Brother Development Model. You probably heard that Metro apps take the whole screen, that there are no right clicks, etc. This is all true, but there is more. You cannot develop Metro apps on your local machine without obtaining a special (free) developer license from Microsoft, and this license is good for 30 days. It works per user, per machine. After 30 days if you do not renew the license, you won’t be able to run your own Metro applications on your own machine unless you renew the license. Nice, eh? And this is not a theory: one of the presenters had their license expired during lunch and was forced to rush to renew it. If he did not happen to have Internet connection at the moment, he would not be able to run his own demos. This rule applies only to applications that target Metro runtime, “traditional” applications are not affected.

WPF 4.5. No major changes in WPF 4.5. “Everyone is focused on Windows 8, so it’s a polishing release”. No type safe bindings either. Event ASP.NET got them (ItemType property), but in WPF DataContext remains untyped.

.NET Framework. async and await keywords are the biggest deal on the block, every single presenter mentioned them. This partially has to do with the fact that Metro/WinRT enforces asynchronous call model for potentially time consuming APIs, such as network or file operations The funny part is, they did not have to add new keywords to Javascript – it already has continuations

There was a profound lack of consensus between presenter on whether .NET Metro “profile” is a proper subset of “big” .NET with exactly the same binaries, or the compatibility exists purely on the source code level. The truth is probably somewhere in between.

HTML and JavaScript on Metro. There is a big fuzz about ability to write native Metro applications using HTML and JavaScript. This is technically true, but the resulting applications are not regular HTML/JavaScript applications. They heavily use Metro-specific library called WinJS, which will not appear anywhere else except Metro. So, while they are HTML, they are not cross-platform. Visually HTML Metro applications do not differ from C# or C++ Metro applications.

More later