The Windows Runtime (WinRT) was created to provide a fluid and secure application experience on Windows. WinRT was influenced by both .NET, C++ and JavaScript. WinRT does not replace the CLR or Win32, but rather provides unified support for applications written in different languages to run on Windows using the new Metro UI.
Microsoft started working on the Windows Runtime (WinRT) 2 years ago starting from the desire to build a better development platform enabling the creation of fast, fluid and trustworthy applications using rich Intellisense and good debugging tools, while having freedom of choice of the language and libraries to use. The end result was an architecture and a set of API that can be called from .NET languages (C#, VB.NET, F#), C++, and HTML/JavaScript. All these languages had an influence on the design of WinRT.
WinRT is not meant to replace all the functionality provided by .NET or Win32, but it is a common platform for applications written in different languages to run using the new Metro style interface. Hybrid C# applications will still be able to execute LINQ queries while relying on WinRT to create the Metro UI, but also for storage, network, new application security, etc. The overall architecture of the runtime is depicted in the graphics below:
Language Projection represents the view on WinRT API that each of the languages supported has. The recommended API for building METRO applications can be found under the “Windows” namespace in Visual Studio 11’s Intellisense.
Martyn Lovell, Development Manager of the Windows Runtime, presented the design principles behind WinRT during the BUILD session entitled “Lap Around the Windows Runtime”:
- Anything taking more than 50ms should be done through an asynchronous call using Async in order to ensure a fluid and fast application experience. Because many developers tend to use synchronous API calls even when their asynchronous equivalents exists, Async was built deep inside the WinRT forcing developer to make asynchronous calls.
- Better separation between applications so one’s performance would not affect another, and for better security. Runtime objects belonging to one application cannot be exposed to another except by going through the standard OS communication channels mediated by Windows Contracts.
- Platform-based versioning ensuring that applications run well on different versions of Windows. Versioning is included in WinRT metadata, and Intellisense exposes functionality based on the version an application targets, so the developer knows which classes and methods are available for a certain version of Windows without consulting other documentation.
Regarding types, WinRT had to provide language independent types –integer, enumerations, structures, arrays, interfaces, generic interfaces and runtime classes. A new type of String called HSTRING was introduced allowing the transfer of strings between an application and the runtime without performing any data copy.
Each WinRT object is projected through a number of interfaces, two of them belonging to each object: IUnknown, the familiar COM interface, and IInspectable, used to discover information about the object based on its included metadata. An object may provide other functionality via interfaces, but those interfaces are exposed collectively via a runtime class. For example, the FileInformation object has the interfaces IStorageItemInformation, IStorageItem, IStorageFile exposed through the FileInformation class.
WinRT objects are exposed to C++ applications at compile time, and they are bound to C#/VB.NET apps partially at compile time and partially at runtime. HTML/JavaScript applications see WinRT objects only at runtime, the metadata being generated dynamically.
The METRO interface runs on a non-reentrant single thread but the rest of the application can use multiple threads automatically provided by the runtime from a thread pool.
Harry Pierson, Windows Runtime Experience Team, and Jesse Kaplan, Common Language Runtime Team, presented some details for programming with .NET languages against WinRT in another BUILD session called “Using the Windows Runtime from C# and Visual Basic”.
According to Pierson, .NET had a major influence on WinRT, many design guidelines being borrowed from it. For example, the WinRT library is augmented with metadata based on an updated version of .NET’s metadata format. Like Silverlight, WinRT uses a XAML framework for creating Metro applications. .NET applications will feel at home using WinRT since there is a direct mapping between the runtime and .NET: primitives, classes, interfaces, properties, methods, etc., the existing differences being hidden from the developer.
Pierson also said that one can create Windows Runtime components in C# to be consumed by C++ or JavaScript WinRT applications by abiding to a series of rules: “Structs can only have public data fields, Inheritance can only be used for XAML controls, all other types must be sealed, Only supports system provided generic types.”
Windows 8 and perhaps the following versions of Windows will provide a mixed environment where classic applications coexist with the new touch-friendly Metro ones. The future Windows applications based on Metro will benefit from a common infrastructure provided by the Windows Runtime, the developers having to program against a unique API that has slightly different views from different languages. This is Microsoft’s best attempt in maintaining compatibility with the past while providing new functionality for the future.