Design Details of the Windows Runtime
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.
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.
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.
It seems that MS has still the same problem as apple with Obj-C...
As for async API, it reminds me of the old days when I was programming on the classic MacOS, where the lack of threading forced to implement complex chain of callbacks.
Well, maybe since modern languages have a better syntax to do that, this kind of API is easier to use now.