It is implemented in C++ and officially supports development in C++ (via C++/WinRT, C++/CX or WRL), Rust/WinRT, Python/WinRT, JavaScript-TypeScript, and the managed code languages C# and Visual Basic (.NET) (VB.NET).
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.
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.
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.
[6][7][8] This common metadata format makes it easier to consume WinRT APIs from .NET apps with simpler syntax than P/Invoke.
The previous C++/CX (Component Extensions) 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.
[13] 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.
[16][17][18][19] 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.
[20] 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.
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.
One of the major additions to WinRT relative to COM is the cross-application binary interface (ABI), .NET-style generics.
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.
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.
[24] 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.
[25] C++/CX on the other hand wraps-up calls to WinRT with code that does error checking and throws exceptions as appropriate.
The syntax resembles the one of C++/CLI although it produces native (although not standard) code and metadata that integrates with the runtime.
WinRT applications using .NET languages use the XAML-based WinUI, and are primarily written in C#, VB.NET, and for the first time for XAML, with native code using C++/CX.
With .NET 5, Microsoft removed the built-in WinRT support and instead created CsWinRT, a tool that generates interop code for accessing Windows Runtime APIs similar to how C++/WinRT works.
[27][28] Classes defined in WinRT components that are built in managed .NET languages must be declared as sealed, so they cannot be derived from.
The release brings a full Windows Runtime API to the platform, including support for WinRT XAML, and language bindings for C++/CX, and HTML5-JavaScript.