Windows Runtime
Windows Runtime is a platform-agnostic component and application architecture first introduced in Windows 8 and Windows Server 2012 in 2012. It is implemented in C++ and officially supports development in C++, Rust/WinRT, Python/WinRT, JavaScript-TypeScript, and the managed code languages C# and Visual Basic .
WinRT is not a runtime in a traditional sense but rather a language-independent application binary interface based on COM to allow object-oriented APIs to be consumed from multiple languages, with services usually provided by a full-blown runtime, such as type activation. That is, WinRT is an "API delivery system". Apps using the Windows Runtime may run inside a sandboxed environment to allow greater security and stability and can natively support both x86 and ARM. WinRT components are designed with interoperability among multiple languages and APIs in mind, including native, managed and scripting languages. Built-in APIs provided by Windows which use the WinRT ABI are commonly known as WinRT APIs; however, anyone can use the WinRT ABI for their own APIs.
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 application binary 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. For WinRT components implemented in native code, the metadata file only contains the definition of methods, classes, interfaces and enumerations and the implementation is provided in a separate DLL. This common metadata format makes it easier to consume WinRT APIs from.NET apps with simpler syntax than P/Invoke. Windows provides a set of built-in APIs which are built on the WinRT ABI which provide everything from the XAML-based WinUI library and device access such as camera, microphone etc...The previous 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.
Most WinRT applications 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.
WinRT applications are packaged in the.appx and later the.msix 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 Windows apps can be purchased and downloaded by users. Initially, WinRT apps could 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. However these restrictions were lifted in the Windows November 10 Update, where users can freely sideload any app signed with a trusted certificate by enabling a setting.
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. When calling a Windows Runtime asynchronous function, the task is started on another thread or process and the function returns immediately, freeing the app to perform other tasks while waiting for results. The asynchronous model requires new programming language constructs. Each language provides their own way to consume asynchronous 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
The metadata describes the APIs written using the WinRT ABI. 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 reflective programming.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 a separate metadata file that can be reflected like ordinary CLI assemblies. Since it is the same format as CLI metadata, WinRT APIs can be used from managed CLI languages as if it was just a.NET API.
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. Only interfaces and delegates can be generic, runtime classes and methods in them can't. Generic interfaces are also known as parameterized interfaces. In C++/CX, they 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 set of interfaces for generic containers that parallel those in the C++ Standard Library, and languages provide 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)
Standard C++ is a first-class citizen of the WinRT platform. As of Windows 10, version 1803, 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.There are two other legacy options for using WinRT from C++: Windows Runtime C++ Template Library, 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 WinRT 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.