My thoughts about Build, Windows 8, WinRT, XAML and Silverlight

by Laurent Bugnion via Silverlight on 9/17/2011 7:32:12 PM

Last week, Microsoft held their long awaited Build Windows (or simply "Build") conference in Anaheim CA. About 5000 people packed the convention center to discover the latest version of the Windows operation system: Windows 8.

This is a very major iteration (much more than the Windows Vista –> Windows 7 transition) (and also, it is an early preview so it is quite unfinished ;) As such, we will definitely need a bit more time to play with it before we can express a truly informed opinion. Of course that didn't stop tech journalists and dumbasses all over the world to (again) express complex thoughts such as "Microsoft is abandoning Flash/Silverlight in Windows 8" or to ride again the "Silverlight is dead" roller coaster.

Of course, as usual (it is starting to get annoying, right?), these opinions are far from the truth and attempt to put a negative spin on everything Microsoft does. I won't even speculate why that is, but based on track records, it is safe to say that this kind of prediction is not very accurate or rational (remember when we were told that we would not be able to use anything else than HTML to build Windows 8 apps? Yeah those were the days ;)

So what is the reality now? Here is what we know:

(disclaimer: this is based on what I understand after many discussions with experts. However, I am not a Windows 8 expert, I just played with it for 5 days now. If anything here is incorrect, it is my own fault and not the experts')

Desktop vs Metro style

• Windows 8 has two modes, one named "Desktop" and one named "Metro style". These names are temporary and may very well change before release. The "Metro style" applications are also referred to as "immersive apps".
• Silverlight and WPF will continue to run as is on Windows 8 in Desktop mode. You can think of the Desktop mode as Windows 7++, an improved version especially optimized for touch operation. Honestly using the Desktop mode with the fingers is an amazing pleasure now, while it was a pain in Windows 7.
• All applications (as far as I tested) that run in Windows 7 also run on Windows 8 Desktop mode. I installed Silverlight and Flash already on mine, OneNote, Live Writer, Live Messenger, Skype and more. No issues at all so far (apart from an occasional instability because "it's an early preview" (TM)).
• Metro style applications (aka "immersive apps") are a new class of apps altogether. They are in fact much more similar to a Windows Phone 7 app than to a classic Windows application. They are optimized for Touch and can also be actuated with keyboard and mouse, though the experience is better with the fingers.
• Metro style apps are sandboxed for security. Again, this is very similar to the Windows Phone 7 model.
• Metro style apps can be developed with 3 possible stacks: XAML/C++, XAML/C# or HTML/CSS/JavaScript. They rely on a set of API named "WinRT" which is exposed in a very consistent manner for the three stacks.

This last point is important. It means that there is no reason to choose one or the other stack based on WinRT features that you want to address. Because of the chosen architecture, the features will automatically be available to the three stacks. In some cases however, some features will be hidden on purpose from one stack or the other, because they might simply not make sense.

The Windows 8 programming model: The blue side is largely unchanged (.NET 4.5, Silverlight 5, Win 32) and everything runs as usual. The green side is new (see the next section).

Programming stacks for WinRT

• Amongst the three stacks, there will be some differences due to the languages. For instance, JavaScript and C# don't address asynchronous programming in a similar manner (by the way Windows 8 is sporting C# 5, so you have the great "await" and "async" keywords that are making asynchronous programming much more similar to synchronous coding). Similarly, JavaScript is more dynamic than C#, but C# is easier to code and to debug, etc.
• All three stacks talk to unmanaged code (the WinRT libraries). For C++, this is a direct unmanaged call. For C# and JavaScript, there is a thin managed layer to "map" the calls into WinRT. However, the managed layer is much thinner than before. It is simply because most of the previous .NET libraries are now WinRT libraries, and these are unmanaged.
• For the C# developer however, you will not notice that the WInRT are unmanaged (except in some rare occasions) because the API is managed.
• This means that the performance gain in C++ is not going to be as significant as versus "classic .NET". There will be however a small performance gain in using XAML/C++.

Portability of Metro style apps

• HTML/CSS/JavaScript applications coded for WinRT are not cross platform. They are something new. They use WinRT specific APIs, both in HTML/CSS (for instance the new Grid layout, which is not supported by other browsers at this time), or of course any calls against the WinRT APIs. This is NOT web programming. This is a standalone Windows 8 app that happens to be coded in a programming language that can also be used on the web. Two very different beasts, though of course knowledge and skills can be leveraged.
• XAML/C# apps are not Silverlight or WPF. They are something new. They use WinRT specific APIs (sounds familiar?). Mostly, these APIs were already available in Silverlight, however there was a rather large "spring cleaning" operation, and a lot of APIs were moved in different namespaces, and sometimes renamed. A good example of this is the System.Threading.Dispatcher class which is now a Windows.UI.Core.CoreDispatcher. The original dispatcher's CheckAccess() method is now a property named HasThreadAccess.

In both these points, notice how similar the experience is for the developer: Much is familiar, some things are new (most significantly new/renamed APIs), skills are portable but there is a learning curve.

How to choose?

In Jason Zander's (and others') own words, to choose the stack of choice to create a new Metro style app, you should consider the skills you have. If you are a web programmer with a solid experience in JavaScript, it's obvious that you want to leverage your knowledge of the language. You will have a learning curve though, to learn the new proprietary APIs. If on the other hand you are a Silverlight/WPF developer, or even a .NET developer with no prior XAML experience, it will be easier and more faster for you to climb on the C#/XAML stack. Finally, if you are a C++ enthusiast, the C++/XAML stack is for you. And if like me you love to learn new things, then you can try one or both of the other stacks to build new apps.

Because of the Win8 architecture, any new feature added to WinRT will (almost) automatically be available to all three programming stacks (in fact it requires a little bit of work to decide what should be exposed or not, because some APIs just don't make sense with a given programming language, but in regards to the investment needed to implement the feature, this is not significant.

What about existing applications?

It means that your (our) investments in any technology you were using until now are safe for a number of years. You had a Silverlight application, or are currently working on one? You should continue. WPF? Same thing. Not only these frameworks are fully supported and extended (Silverlight 5 release candidate was announced a few days before Build started), but they also work as is, without any changes on Windows 8.

And C#?

I had the immense privilege to be invited to a side session with Anders Heljsberg, the father of C#. It was a great session, and you can feel Anders' happiness and enthusiasm. WinRT currently supports C#5, including all the new features such as the async and await keywords, and more. When asked if he was thinking of a version 6, Anders laughed and told us that he had a history of being quite stable at his job (13 years at Borland, 10+ years at Microsoft) and that he was foreseeing C# 6, 7, 8. C# is actively developed, and Anders is an accessible architect, who will listen to requests for new features. Changing a language is obviously not a fast process (nor should it be!) but his team is working on exciting stuff, and we are his customers!

Thoughts about porting applications from Silverlight/WPF to WinRT

This one is a tough one, mostly because I did not have time to experiment enough. If you have an existing application implemented in Silverlight or WPF, and you want to make it a WinRT application, how should you proceed, and is that easy?

Based  on what I saw and what others reported, it is not a trivial process, even if in most cases the major work is to find out what was renamed and what was moved (see the “spring cleaning” mention above). If you want/have to do that work, I would consider the following:

• Why do you want to do this? Do you really want to make your existing application (which by the way runs perfectly fine on the Windows 8 Desktop) a WinRT app? Who are you trying to touch. Shouldn’t you rather be developing a new app, something like a companion to the existing application?
• If you answer “yes” to the “do you really want to” question, then I really hope that you followed best practices and layered and componentized your application carefully (I also hope you wrote unit tests, because you’re going to need those to verify that the ported code runs fine).
• Porting the code will take some effort. Do not underestimate the effort. I tend to believe that Microsoft was (purposely?) over-optimistic in telling us that this is an easy process. At least now that the documentation is in a very early stage, looking for the renamed objects is a tedious process.
• By the way, I started porting MVVM Light to WinRT and I hope that (if my compulsion to blog about Windows 8 lets me) I might have something to share soon.

Tip: I was told (and didn’t test yet) that ILDASM can decompile the WinRT assemblies and let you peek for your objects/methods/properties. This is because even though the WinRT framework is unmanaged, a thin layer of meta data is built in to allow managed code access. Pretty clever (and handy) if you ask me. I (again) didn’t try but I suspect that dotPeek and other similar tools may work too. Let me know in the comments if you try it!

Wrapping up

There are a few not-very-well organized thoughts on Windows 8, WinRT, XAML and more, put together after 5 days of immersion and tons of discussions with Microsoft employees as well as third party experts. I hope you'll forgive me if it sounds a bit chaotic, it is simply that a new framework of that amplitude will need a few weeks (months?) to be fully assimilated and digested. I hope that this helps painting a clearer picture however.

If there is one thing only you should take from this post, it is the following: Don't panic. Yes we will have some work to fully climb on this new exciting platform. But much MUCH of what we know is going to apply almost 1:1 to the new stack. Also, Microsoft is really investing in user experience, Blend, XAML, C# and all that. If there is only one session of Build that you must see, it is Jensen Harris fantastic Big Picture session about the Windows 8 UX.

I for one am pretty excited about Windows 8 and WinRT. First it confirms what I have been thinking since I started playing with the Avalon bits: XAML is a great way to build a wonderful user experience, Blend is central to that experience and C# is awesome. I am also excited to see new ways to develop applications for WinRT, because diversity is good. The Samsung slate is an awesome device, and there was a great sense of excitement in Anaheim this week. Of course I am known for being an optimistic, but I don’t think it’s just me feeling that excitement. Windows 8 is going to be pretty awesome.

Credit for “Don’t panic” button: http://www.flickr.com/photos/brighton/2153602543/s

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn