Windows Runtime


Windows Runtime is a platform-agnostic application architecture first introduced in Windows 8 and Windows Server 2012 in 2012. WinRT supports development in C++/WinRT, C++/CX, Rust/WinRT, JavaScript-TypeScript, and the managed code languages C# and Visual Basic.NET. WinRT applications natively support both the x86 and ARM processors, 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 uses 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, is written mostly in the language C. It is an unmanaged code application programming interface based on Component Object Model 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, 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 Component Extensions of C++/CX are recommended for use at the API-boundary only, not for other purposes. Regular C++ can also be used to program with WinRT components, with the help of the Windows Runtime C++ Template Library, 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.
WinRT applications run within a sandbox and need explicit user approval to access critical OS features and underlying hardware. File access is restricted to several predetermined locations, such as the directories Documents or Pictures.
WinRT applications for Windows RT, Windows 8 and beyond are packaged in the .appx file format; based upon Open Packaging Conventions, it uses a ZIP format with added XML files. WinRT applications are distributed mostly through an application store named Microsoft Store, where WinRT software can be downloaded and purchased by users. WinRT 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.
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. The application dispatches the API call, which returns immediately, freeing the application to perform other tasks while waiting for results. The asynchronous model requires new programming language constructs, similar to try/catch used in exception handling. Parts of the 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

The metadata describes the code written for the WinRT platform. It defines a programming model that makes it possible to write object-oriented code that can be shared across programming languages, and enables services like reflection.
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. Native code cannot contain metadata, so it is stored in separate WINMD-files that can be reflected like ordinary CLI assemblies.
Because it is CLI metadata, code written in native WinRT languages can be used from managed CLI languages.

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,.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 can also be genericized using C++ templates, but only template instantiations can be exported to.winmd metadata, 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 conversion functions. The consumption of WinRT collections in.NET languages 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.

WinRT components

Classes that are compiled to target the WinRT are called WinRT components. 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. The runtime requires WinRT components that are built with.NET Framework to use the defined interface types or.NET type interfaces, which automatically map to the first named. Inheritance is as yet not supported in managed WinRT components, except for XAML classes.

Programming interfaces

Programs and libraries targeted for the WinRT runtime can be created and consumed from several platforms and programming languages. Notably C/C++,.NET and JavaScript. This is made possible by the metadata.
In WinRT terminology, a language binding is termed a language projection.

C++ (C++/WinRT, Component Extensions, WRL)

Native C++ is a first-class citizen of the WinRT platform. As of version 10.0.17134.0, the Windows SDK contains C++/WinRT. C++/WinRT is an entirely standard modern C++17 language projection for Windows Runtime 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. WinRT is a native platform and supports any native C++ code, so that a C++ developer can reuse existing native C/C++ libraries. With C++/WinRT, there are no language extensions.
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.
There are two other legacy options for using WinRT from C++: WRL, an ATL-style template library, and C++/CX 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.
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 native code and metadata that integrates with the runtime. For example, WinRT objects may be allocated with ref new, which is the counterpart of gcnew from C++/CLI. The hat operator ^ retains its meaning, however in the case where both the caller and callee are written in C++ and living in the same process, a hat reference is simply a pointer to a vptr to a virtual method table.
Along with C++/CX, relative to traditional C++ COM programming, are partial classes, again inspired by.NET. These allow instance XAML code to be translated into C++ code by tools, and then combined with human-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

The.NET Framework and the Common Language Runtime are integrated into the WinRT as a subplatform. It has influenced and set the standards for the ecosystem through the metadata format and libraries. The CLR provides services like JIT-compilation code and garbage collection. WinRT applications using.NET languages use the new Windows Runtime XAML Framework, and are primarily written in C#, VB.NET, and for the first time for XAML, with native code using C++/CX. Although not yet officially supported, programs can also be written in other.NET languages.
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

WinRT applications can also be coded using HTML with JavaScript in code-behind, which are run using the Trident rendering engine and Chakra JavaScript engine, both of which are also used by Internet Explorer. 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 WinRT APIs to languages other than C++. One example is Rust/WinRT, an interface for programs written in Rust to use WinRT APIs. Rust/WinRT is part of Project Reunion, a Microsoft effort to reconcile the Win32 and WinRT platforms.

Bridges

With the introduction of the Universal Windows Platform, WinRT has received many API bridges that allow programs originally coded for other languages to be ported easily while taking advantage of UWP features. Microsoft has provided bridges for Android, iOS, Progressive Web Apps, Silverlight, as well as bog-standard Win32-based desktop applications.

API

WinRT comes with an application programming interface in the form of a class library that exposes the features of Windows 8 for the developer, like its immersive interface API. It is accessible and consumable from any supported language.

Runtime classes

The Windows Runtime classes is a set SDKs that provide access to all functionality from the XAML parser to the camera function. The SDKs are implemented as native C/C++ libraries.

Naming conventions

The naming conventions for the components in the API are heavily influenced by the.NET naming conventions which uses camel case. 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. This is to give 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.
;Basic types
;Strings
;Structs
;References
;Arrays
;Events
;Collections
;Method overloading
;Asynchrony

Version history

Windows version
Windows 8Windows Runtime
Windows 8.1
Windows 10Universal Windows Platform

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. 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.