Windows Runtime

"WinRT" redirects here and is not to be confused with Windows RT.

Windows Runtime

Other names	WinRT
Developer(s)	Microsoft
Initial release	September 2011 (2011-09)
Operating system	Microsoft Windows
Predecessor	Win32 API
Standard(s)	ECMA 335
Type	Application programming interface
Website	Official documentation

Windows Runtime (WinRT) is a platform-agnostic application and component architecture first introduced with Windows 8 and Windows Server 2012 in 2012. WinRT supports development in C++/WinRT (standard C++ based library), C++/CX (Component Extensions, a set of language extensions for the Visual C++ compiler that simplifies Windows Runtime access), Rust/WinRT, Python via the winrt package, JavaScript-TypeScript, and CLI languages such as C# and Visual Basic (VB.NET). WinRT applications natively support both the x86 and ARM processors however native apps need to be separately compiled for each architecture, and may run inside a sandboxed environment to allow greater security and stability. WinRT components are designed with interoperability among multiple languages and APIs in mind, including native, managed and scripting languages.

Windows Phone 8.1 used a version of the Windows Runtime named the Windows Phone Runtime. It enables developing applications in C# and VB.NET, and Windows Runtime components in C++/CX.

Technology

WinRT is implemented in the programming language C++ and is object-oriented by design. Its underlying technology, the Windows API (Win32 API), is written mostly in the language C. It is an unmanaged code application programming interface (API) based on Component Object Model (COM) that allows interfacing from multiple languages, as does COM. However, the API definitions are stored in .winmd files, which are encoded in ECMA 335 metadata format, which .NET Framework also uses with a few modifications. This common metadata format allows significantly less overhead when invoking WinRT from .NET applications, relative to P/Invoke, and much simpler syntax.

The new C++/CX language extensions also known as the C++ component extensions, which borrows some C++/CLI syntax, was introduced for writing and consuming WinRT components with less glue code visible to the programmer, relative to classic COM programming in C++, and imposes fewer restrictions relative to C++/CLI on mixing types. The language extensions provided C++/CX are recommended for use at the API-boundary only, not for other purposes. Regular C++ (with COM-specific discipline) can also be used to program with WinRT components, with the help of the Windows Runtime C++ Template Library (WRL), which is similar in purpose to what Active Template Library provides for COM. In 2019, Microsoft deprecated C++/CX in favor of the C++/WinRT header library.

Windows apps built using the Windows Runtime usually run within a sandbox and need explicit user approval to access critical OS features and underlying hardware. By default, file access is restricted to several predetermined locations, such as the directories Documents or Pictures. These apps use inbox WinRT APIs exclusively to do that however the Windows Runtime component platform itself can be used from any kind of Windows app, not just UWP apps.

WinRT based apps for Windows RT, Windows 8 and beyond are packaged in the .appx or .msix file format; based upon Open Packaging Conventions, it uses a ZIP format with added XML files. Those applications are distributed mostly through an application store known as the Microsoft Store, where Windows software (termed Microsoft Store apps) can be downloaded and purchased by users. Packaged apps can only be sideloaded from outside Windows Store on Windows 8 or RT systems that are part of a Windows domain, or equipped with a special activation key obtained from Microsoft. This limitation no longer exists in Windows 10 November Update or later where users can freely install any app package outside the Store directly from publishers.

In a major departure from Win32 and similarly to .NET Framework 4.5, most APIs which are expected to take significant time to complete are implemented as asynchronous to keep the app responsive to user input while the operation is executing in the background thread or process. The application dispatches the API call, which returns immediately, letting the app perform other tasks. After the task is complete, a callback is issued which the app can use it to get the results. The asynchronous model requires new programming language constructs. Each language has its own way of calling such APIs. Parts of the built-in API needing asynchronous access include on-screen messages and dialogs, file access, Internet connectivity, sockets, streams, devices and services, and calendar, contacts and appointments.

Services

Metadata

See also: Metadata (CLI)

The metadata describes the code written using the WinRT component architecture. It defines a programming model that makes it possible to write object-oriented code that can be shared across programming languages and can be accessed in a natural, familiar manner in any language.

Herb Sutter, C++ expert at Microsoft, explained during his session on C++ at the 2011 Build conference that the WinRT metadata is in the same format as CLI metadata. For managed components, the code is emitted in the metadata itself like any other .NET assembly however since native code (i.e., processor-specific machine code) can't be included in a .NET assembly, the machine code is included in a separate DLL/EXE file and the metadata only contains declaration.

Due to the fact that it's CLI metadata, managed CLI languages can browse and resolve the declarations directly however the actual call itself is performed using low level COM APIs unless the component is implemented in managed code.

Type system

WinRT has a rich object-oriented class-based type system that is built on the metadata. It supports constructs with corresponding constructs in the .NET framework: classes, methods, properties, delegates, and events.

One of the major additions to WinRT relative to COM is the cross-application binary interface (ABI), .NET-style generics. In C++/CX these are declared using the keyword generic with a syntax very similar to that of keyword template. WinRT classes (ref classes) can also be genericized using C++ templates, but only template instantiations can be exported to .winmd metadata (with some name mangling), unlike WinRT generics which preserve their genericity in the metadata. WinRT also provides a library of generic containers that parallel those in the C++ Standard Library, and some reciprocal (back-and-forth) conversion functions. The consumption of WinRT collections in .NET languages (e.g., C# and VB) and in JavaScript is more transparent than in C++, with automated mappings into their natural equivalents occurring behind the scenes. When authoring a WinRT component in a managed language, some extra, COM-style rules must be followed, e.g. .NET framework collection types cannot be declared as return types, but only the WinRT interfaces that they implement can be used at the component boundary.

Windows Runtime components

Components whose classes are exposed in a Windows metadata file are known as Windows Runtime compontents. They are classes that can be written in any supported language and for any supported platform. The key is the metadata. This metadata makes it possible to interface with the component from any other WinRT language.

There are restrictions when building Windows Runtime components using certain runtimes such as .NET which requires all classes emitted to the metadata be sealed as inheritance isn't support yet except for classes related to the XAML framework. JavaScript can consume components written in other languages but can't be used to create new Windows Runtime components.

Programming interfaces

Programs and libraries targeted for the WinRT runtime can be created and consumed from several platforms and programming languages. Notably C/C++ (either with language extensions offering first-class support for WinRT concepts, or with a lower-level template library allowing to write code in standard C++), .NET (C# and Visual Basic .NET (VB.NET)) and JavaScript. This is made possible by the metadata.

In WinRT terminology, a language binding is termed a language projection.

C++

See also: C++/WinRT and C++/CX

Standard C++ is a first-class citizen of the WinRT platform. As of version 10.0.17134.0 (Windows 10, version 1803), the Windows SDK contains C++/WinRT header files for the inbox Windows Runtime APIs. C++/WinRT is an entirely standard modern C++17 language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library, and designed to provide first-class access to the modern Windows API. With C++/WinRT, Windows Runtime APIs can be authored and consumed using any standards-compliant C++17 compiler (Only Clang and Visual C++ has been tested but others should work just fine for the most part). WinRT is a native platform and supports standard C++ code, so that a C++ developer can reuse existing C/C++ libraries.

Prior to C++/WinRT being officially released in the Windows SDK, from October 2016, Microsoft offered on GitHub C++/WinRT. It does not rely on C++/CX code, with the result of producing smaller binaries and faster code. Although C++/WinRT is header based, it does not rely on the SDK headers (eg: Windows.h), instead setups its own header files with types that have identical binary representation under the hood.

There are two other legacy options for using WinRT from C++: WRL, an ATL-style template library, and C++/CX language extensions which resembles C++/CLI. Because of the internal consumption requirements at Microsoft, WRL is exception-free, meaning its return-value discipline is HRESULT-based just like that of COM. C++/CX on the other hand wraps-up calls to WinRT with code that does error checking and throws exceptions as appropriate and vice vers.

C++/CX has several extensions that enable integration with the platform and its type system. The syntax resembles the one of C++/CLI although it produces machine code (although the source code isn't standard) code and metadata that integrates so others can access types provided by a specific compontent. For example, WinRT objects may be allocated with ref new, which is similar to C++/CLI's gcnew keyword however allocates using the Windows heap instead of the CLR heap as there's no CLR when using C++/CX. The hat operator ^ in C++/CX is simply a reference counted smart pointer to a COM interface (eg: ComPtr<T>) but built-in to the language. In the case where both the caller and callee are written in C++ and living in the same process, an hat pointer points to a vptr of a virtual method table (vtable).

Along with C++/CX, relative to traditional C++ COM programming, are partial classes, again inspired by .NET. Partial classes help tools such as the XAML compiler to generate appropriate binding code and then it's combined with manually-written code to produce the complete class while allowing clean separation of the machine-generated and human-edited parts of a class implementation into different files.

.NET

See also: .NET Framework

Originally the .NET Framework and the Common Language Runtime (CLR) were integrated into the WinRT as a subplatform. It has influenced and set the standards for the ecosystem through the metadata format and libraries. WinRT applications using .NET languages can use the new Windows Runtime XAML Framework, and are primarily written in C#, VB.NET. Although not yet officially supported, programs can also be written in other .NET languages. With .NET 5, Microsoft decided to remove the built-in support for using Windows Runtime APIs and instead offers a tool named CsWinRT as an alternative which generates interop code for WinRT access similar to what C++/WinRT does.

Limitations

Classes defined in WinRT components that are built in managed .NET languages must be declared as sealed, so they cannot be derived from. However, non-sealed WinRT classes defined elsewhere can be inherited from in .NET, their virtual methods overridden, and so on; but the inherited managed class must still be sealed.

Members that interface with another language must have a signature with WinRT types or a managed type that is convertible to these.

JavaScript

See also: JavaScript, Rich web application, and WinJS

It is possible to develop native Windows apps using WinRT through HTML with JavaScript in code-behind. The original approach was using the Trident rendering engine and Chakra JavaScript engine, both of which are also used by Internet Explorer and use the WinJS library to get a Windows like look an feel. However this approach is no longer supported by Microsoft. These days web based Windows apps are usually written using Electron or React Native and more often by hosting a web page using the WebView control. When coding a WinRT app in JavaScript, its features are adapted to follow JavaScript naming conventions, and namespaces are also mapped to JavaScript objects.

Other languages

Microsoft is in the process of projecting Windows Runtime APIs to languages other than C++. One example is Rust/WinRT, an interface for programs written in Rust to consume WinRT APIs. Rust/WinRT is part of Project Reunion, a Microsoft effort to reconcile the Windows desktop (Win32) and the UWP low IL app model.

API

Windows provides an application programming interface (API) built on the Windows Runtime infrastructure and exposes the features of Windows 8 and later to all language developers in a natural and familiar manner. These APIs are available under than Windows namespace and is accessible and consumable from any supported language. The Windows SDK provides the metadata for static compilers however dynamic languages load them at runtime from %windir%\System32\WinMetadata folder that exists on every Windows 8 or Windows 10 device.

Runtime classes

A runtime class is a concrete implementation that implements a specific number of interfaces and casting to any one of them by should succeed. Each runtimeclass has a default interface which is the interface that will be returned when constructing an object of that runtimeclass and requires no casting to access members of that interface.

The inbox API set contains runtimeclasses that provide access to all functionality of Windows 8 and beyond from the XAML parser to the camera function. All the built-in functionality are implemented in DLLs located in System32 or SysWow64.

Naming conventions

The naming conventions for the components (classes and other members) in the API are heavily influenced by the .NET naming conventions which uses camel case (specifically PascalCase). Microsoft recommends users to follow these rules in case where no others are given.

These conventions are projected differently in some languages, like JavaScript, which converts it to its conventions and the other way around for a native and consistent experience regardless of the programming language.

Restrictions and rules

Since Windows Runtime is projected to various languages, some restrictions on fundamental data types exist so as to host all such languages. Programmers must be careful with the behavior of those types when used with public access (for method parameters, method return values, properties, etc.).

Fundamental types

• In .NET languages and C++, a rich set of data types exists, representing various numerals while
• In JavaScript, a Number can only represent up to 53 bits of precision which means JavaScript developers must be careful when dealing with big numbers while receiving data and sending data from and to other components.
• In the Windows Runtime, the only lacking numeral data type is 8-bit signed integer relative to .NET and C++.

Strings

• Strings are immutable in .NET and JavaScript, but mutable in C++.
• A null pointer passed as a string to WinRT by C++ is converted to an empty string
• In .NET, null being passed as a string to WinRT is converted to an empty string
• In JavaScript, null being passed as a string to WinRT is converted to a string with the word null. This is due to JavaScript's keyword null being represented as a null object. Similar results occur when passing undefined to WinRT from JavaScript.

Structs

• In .NET and C++, structs are value types, and such a struct can contain any type in it while JavaScript doesn't directly support structs.
• In WinRT, use of structs is allowed only for containing types that have value semantics, including numerals, strings, and other. Object references are disallowed since different languages manage memory differently.

References

• .NET has a concept of reference types and value types, where reference types are passed by reference and value types are passed by value however this behavior can be changed explicitly in some .NET languages.
• C++ treats all types as value types by default however all of them can be passed by reference or value.
• In WinRT, interfaces are passed by reference; all other types are passed by value.

Arrays

• In .NET, C++, and JavaScript arrays are reference types.
• In WinRT, arrays are value types. This means returning or passing an array will create a copy of it.

Events

• Under the hood, subscribing and unsubscribing to an event requires a call to the event's add and remove methods respectively. When an user subscribes to an event, a token is generated which should used be when unsubscribing from that event.
• In C++ and JavaScript, a weak reference is stored when a client subscribes by default. This means the client doesn't necessarily need to unsubscribe from a subscribed event to prevent memory leaks.
• .NET always stores a strong reference when a client subscribes, so the client must be careful in unsubscribing non XAML events in order to eliminate memory leaks.
• In .NET and C++/CX, clients subscribe to events using += operator and unsubscribe through the -= operator.
• C++/WinRT uses a function call like syntax to subscribe and unsubscribe.
• In JavaScript, addEventListener function or setting on<EventName> property is used to subscribe to events.
• In WinRT, all languages can use their own way to subscribe to events.

Collections

• The Windows Runtime itself doesn't provide any collection classes and only provides parameterized interfaces that represent a collection data structure.
• Classes that implement these interfaces are mainly provided by each language while some are provided by Windows itself.
• The .NET Runtime maps a few .NET collection interfaces to a similar WinRT collection interface (eg: IVector<T> is projected as an IList<T>).

Method overloading

• .NET and C++ also support overloading based on type type.
• JavaScript parameters don't have a type specified so overloading can only be done using the number of parameters.
• In WinRT, only parameter number is used for overloading.

Asynchrony

• All inbox WinRT methods are designed such that any method taking longer than 50 milliseconds is an async method. Microsoft encourages other developers to do so when building their own libraries and APIs. T
• The established naming pattern to distinguish asynchronous methods is <Verb>[<Noun>]Async. For the full runtime library, all methods that have a chance to last longer than 50 ms are implemented as asynchronous methods only.
• UI apps can't really call them synchronously as blocking the thread will cause an exception to be thrown. Non UI apps don't have this limitation.

Windows Phone Runtime

Starting from Windows Phone 8 it is possible to develop apps using a version of the Windows Runtime called the Windows Phone Runtime (WPRT). Although WP8 brought limited support, the platform did eventually converge with Windows 8.1 in Windows Phone 8.1.

Windows Phone 8

Windows Phone 8 has limited support for developing and consuming Windows Runtime components through Windows Phone Runtime. Many of the Windows Runtime APIs in Windows 8 that handle core operating system functions have been ported to Windows Phone 8. Support for developing native games using C++/CX and DirectX has been added, by request from the game development industry.

However, the Windows Phone XAML Framework is still based on the same Microsoft Silverlight framework, as in Windows Phone 7, for backward compatibility. Thus, as of 2016, XAML development is impossible in C++/CX. Development using either HTML5 or WinJS is unsupported on Windows Phone 8.

Windows Phone 8.1

Windows Runtime support on Windows Phone 8.1 converges with Windows 8.1. The release brings a full Windows Runtime API to the platform, including support for Windows Runtime XAML Framework, and language bindings for C++/CX, and HTML5-JavaScript. There is also a project type called Universal apps to enable apps to share code across 8.1 versions of Windows Phone and Windows.

The Windows Phone 8 Silverlight Framework has been updated. It can exploit some of the new features in the Windows Runtime.

Windows Phone Runtime uses the AppX package format from Windows 8, after formerly using Silverlight XAP.

Windows 10 Mobile

Windows 10 Mobile now supports UWP APIs and apps can be written once for all Windows devices without any change. Windows 10 Mobile supports the Windows Runtime XAML Framework just like on desktop in addition to the Silverlight framework. Some older APIs require checking at runtime based on the device family as they aren't present on all devices but newer APIs introduced in Windows 10 work on all devices even if the feature itself isn't supported on the device (eg: You probably never have a scanner connected to an Xbox but the APIs will return there's no scanners just like on a PC with no scanner connected instead of throwing an exception).

See also

• Windows Runtime XAML Framework

External links

• Official website