Channels ▼
RSS

C/C++

WinRT: The New Runtime in Windows 8


In Windows 8, you can still keep writing classic .NET applications as you have done for the past decade. Windows 8, however, adds a new family of applications often referred to as "Metro applications." To be precise, "Metro" is the blanket term used to indicate a collection of design principles that have inspired Microsoft in the creation of the new interface of Windows 8, running side by side with the classic Windows interface. Glimpses of the Metro style are visible in Windows Phone and will likely be visible in the new releases of Microsoft's flagship products in the months to come. I agree with those who say that we can measure the real commitment of Microsoft to Metro with the next version of Office.

According to Wikipedia, Metro is a "design language" inspired by the "principles of classic Swiss graphic design" that emphasize cleanliness and readability. If Metro is mainly a design language, then a Metro application is a Windows application whose user interface and user experience are inspired by the Metro principles. In light of this, what's the role of Windows 8 and why does Metro seems to be so tightly bound to it? What's really going to be different for developers?

Meet WinRT

The .NET framework runs on top of the old Win32 API and it uses the P/Invoke mechanism to make calls from the dazzling world of managed code to the wilds of COM and C-based APIs. With Windows 8, Microsoft is undertaking an important move — replacing the underlying layer through which the core of the OS functions is exposed to applications. In other words, Microsoft is attempting to touch and restructure some of the pillars of all Windows applications. They're doing so by introducing WinRT — short for Windows Runtime.

WinRT is ultimately a new layer of code that is expected to provide the same core services as Win32/COM. You should be able to see immediately the deep impact of such a change: WinRT can't just be plugged in silently while keeping existing .NET applications working as usual. WinRT is the dawn of a new generation of applications. It goes beyond .NET in the sense that it would ideally require a new, revisited .NET.

Not really a realistic scenario is it? Or, at least, not a scenario that will be realistic in the space of a Windows release; and not a scenario you can enable overnight. That's why Windows 8 is presented as a dual operating system — the classic Windows/.NET model and the new WinRT-based model.

WinRT-powered applications are also expected to show off a new and more modern user interface and user experience — the Metro style. However, WinRT and Metro are distinct things. It is mere guesswork at this time, but it seems that you can have WinRT applications equipped with a non-Metro UI; likewise, you could have Metro-inspired applications written for classic .NET. If past history holds, it will take only a few months to see Metro-inspired UI components from major vendors. At that point, the circle will be closed and the message will be clear to everybody: Metro is the recommended UI/UX of the next Windows. And WinRT is the new runtime for building next-generation Windows applications.

WinRT and .NET

What's the relationship between WinRT and today's .NET Framework? As I said, my guess is that in an ideal world, Microsoft would have shipped a brand new .NET Framework working on top of WinRT and would have educated the masses to forget the old and embrace the new. This is ideal, but not realistic, and some common ground must be found.

WinRT offers a framework that looks like the familiar .NET Framework, but still has some key differences — clear signs of the underlying idea of reworking the programming framework developers deal with. Some classes are very similar as .NET Framework classes, with only minor differences; some.NET Framework classes have a counterpart in WinRT, but in different namespaces (and renamed and refactored a bit); and some of the .NET Framework classes are not exposed to WinRT applications and are unavailable. Finally, some new classes make their debut in WinRT.

In addition, WinRT is driven by a new set of policies and this is reflected in the organization of the programming API. For example, all APIs expected to run for longer than a few milliseconds have been designed to be asynchronous. This is a huge change that introduces a significant paradigm shift for most developers. The shift, however, is partially mitigated by some new facilities available at the language level, such as the new await/async keywords, which you may have already seen in F#. Direct file access is also restricted in the name of sandboxing and making new applications ready for a Windows-specific marketplace. That doesn't mean that you cannot permanently store data in WinRT applications: You just have to use a different API, such as the classes stored in the new Windows.Storage namespace. To open and save documents and files, you have new file picker components that replace the standard common dialogs of Windows. You also have an ad hoc WinRT API for accessing the registry. In a nutshell, you have a new API, only a part of which exactly matches the .NET API.

WinRT native components can be written with primary .NET languages such as C# and Visual Basic as well as with C++ and JavaScript.

Conclusion

Anybody outside Microsoft today who claims to have a vision regarding WinRT and what Windows 8 will become might be proved wrong in a few months. This is due to the lack of specific and detailed information at this early stage. At any rate, I feel confident stating that the new Windows runtime takes on a huge challenge: improving the Windows programming model and subsequently the foundation of Windows applications. To make this happen and push a more modern view of applications, Microsoft had to touch the ground occupied by the .NET Framework. In doing so, it considered and rejected breaking changes in the framework that serves millions of applications today. That's why we now are getting this "new" thing — the new Windows Runtime.


Dino Esposito is a frequent contributor on Microsoft topics and has written several developer-oriented books for Microsoft Press.

Related Reading

Windows 8: Microsoft's Development Re-Do


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video