Raf's laboratory Raffaele Rialdi personal website

In the previous post I retraced the motivations that led to WinRT.

One of the fundamental requirements of WinRT is to allow better interaction between different languages, either native or managed. We also have already seen that only a runtime that exposes functionality in an object oriented fashion can provide a clean and simple interoperability.

Interoperability between WinRT and programming languages is settled by "projections" that solve two problems:

• using WinRT from different languages easily and with no performance hit
• make WinRT available to languages as it was a language-specific library so that it can be used in a natural way

The first step was therefore to establish a type system.

Numerical types are supported as signed and unsigned (integers and floating point). The biggest problem is related to javascript that, according to the ECMA specification, supports a single numeric type (the type floating point specification in IEEE-754) for both integer and floats, which prevents handling integers over 53 bits of precision. Windows kernel uses 64-bit types (even in 32-bit platforms) for certain features such as file size, offset, etc.

There is a new String type whose binary representation avoids marshalling operations with wstring (C++) or with Framework.NET string. The new String is immutable as it is in Framework.NET but instead of being a reference type, WinRT string is a value type as it happens for wstring and therefore non-nullable. This allows you to smooth out the differences between various languages. In order to build strings C++ developers use wstring or wstringstream while VB/c # will continue to use StringBuilder as always.

Reference type. WinRT describes the objects layout using interfaces, therefore all objects that implement interfaces are reference types. As a consequence, when calling a function, object parameters are passed by reference, while the rest are passed by value. Furthermore parameters are passed as [in] or [out] and never in [in, out].

Value type. According to the previous definition of reference types, value types are "the rest". Arrays are value type (unlike Framework.NET) and structures cannot hold pointers/references in order to avoid the problems related to the cost when copying structures (deep vs. shallow copy problem).

Among the various other types defined in the namespace "Platform", there are Vector and Map that maps to collections and dictionaries of the .NET Framework. Note that Vector<T> implements IObservableVector<T> and then natively supports change notifications.

Obviously there are booleans, enums and many other basic types as Object, Type, and Guid, but I could not find anything different than what I expected: they are simply natural types.

To make available WinRT to languages in a natural way, the projections change the casing conventions of the library. Javascript conventions, for example, use camelCase for properties and methods, PascalCase for types and lowercase for events. WinRT instead always use PascalCase conventions already used in the .NET Framework. The projection change library names using the conventions of the "projected" language.

It is clear that each language offer peculiarities that cannot be ignored. This was a problem during .NET Framework design (see CLSCompliant attribute) and continues to be in WinRT.

Rather the fact that now there is a standard way a language can be interfaced to WinRT opens the intriguing scenario of third-party languages. At this point seems a step obvious for Java, Python, Ruby, D, Delphi, and who knows how many others.