Fact-checked by Grok 2 weeks ago

Windows Runtime

The Windows Runtime (WinRT) is a set of application programming interfaces (APIs) developed by to enable the creation of modern applications for the Windows operating system, introduced alongside in 2012 as the foundational API surface for Windows Store apps. It provides a language-agnostic framework that supports development in multiple languages, including C#, , , and C++, allowing developers to leverage existing skills and assets while accessing core Windows functionality such as media handling, networking, and security. At its core, WinRT is built on the (COM) but extends it with a modern, object-oriented design that uses binary contracts and Windows Metadata (.winmd) files to define in a platform-neutral way, facilitating projections for different languages to provide natural programming experiences. This architecture ensures fast, asynchronous operations—essential for responsive apps—through types like IAsyncOperation, and it integrates concepts from .NET and to support hybrid applications combining multiple languages and components. Key features include a consistent design with namespaces, collections, and events; built-in support for file I/O, sensors, and UI elements; and security mechanisms that isolate apps from the system for enhanced user privacy and safety. WinRT serves as the technological backbone of the Universal Windows Platform (UWP), evolving from its origins to enable unified app development across a wide range of Windows devices, including PCs, tablets, , and HoloLens, starting with Windows 10. Through tools like C++/WinRT and projections for .NET languages, it continues to power contemporary Windows app development, including desktop enhancements and integrations, while maintaining and extensibility for third-party components.

Overview

Definition and Purpose

The Windows Runtime (WinRT) is a binary standard and application architecture developed by to serve as the foundation for Metro-style applications in . It represents a modern surface designed specifically for creating Windows Store apps, extending the (COM) with contemporary semantics while maintaining native performance and enabling a reimagined developer experience. WinRT debuted with the release of on October 26, 2012, and on September 4, 2012. The primary purpose of WinRT is to deliver a secure, sandboxed environment for applications, leveraging AppContainer to enforce least-privilege access and prevent malicious interference with the system or other processes. This model provides isolated for app data, restricting and registry access to designated read-write and read-only locations, while supporting efficient, single-package installations that enable rapid deployment without scattering files across the system. By design, WinRT emphasizes touch-optimized applications that operate in a controlled context, promoting through credential, device, and features. WinRT's key benefits center on platform neutrality and seamless , achieved through metadata-based projections that allow developers to consume the same from diverse languages including C++, .NET (such as C# and ), and . This cross-language support facilitates hybrid development, where components authored in one language can be integrated into apps built with another, positioning WinRT as the successor to for contemporary Windows programming.

Historical Development

The Windows Runtime (WinRT) originated as a key component of the operating system, released on October 26, 2012, where it served as the foundation for developing applications across PCs, tablets, and other devices. Designed to modernize app development, WinRT built upon the (COM) by incorporating metadata-driven binary contracts and language projections for C#, , JavaScript, and C++, enabling a consistent API surface that abstracted underlying Win32 complexities. This initiative aimed to streamline cross-device app creation and laid the groundwork for addressing fragmentation in Microsoft's ecosystem through the later convergence of Windows desktop and platforms. In , released on October 17, 2013, WinRT received enhancements including expanded API coverage for better integration with .NET languages, improved asynchronous programming support, and refinements to enable more seamless .NET app deployment to the Windows Store. These updates addressed early limitations in developer tooling and API breadth, fostering greater adoption among .NET developers while maintaining backward compatibility with binaries. By Windows 10's launch on July 29, 2015, WinRT evolved into the core of the Universal Windows Platform (UWP), providing a shared app model across desktops, mobiles, , and devices through device family and a unified store. Post-Windows 10 developments expanded WinRT's reach, notably with the Anniversary Update (version 1607) on August 2, 2016, which introduced the Desktop Bridge (also known as Project Centennial), allowing Win32 desktop applications to access WinRT APIs and be packaged for the Microsoft Store. This bridge facilitated gradual modernization of legacy apps without full rewrites. In 2018, Microsoft released C++/WinRT as a standard C++17 projection for WinRT, with support in Visual Studio 2017 and later, offering header-only implementation for efficient, exception-based programming without reliance on C++/CX extensions. Through Windows 11, released on October 5, 2021, WinRT continued as the backbone for UWP and modern UI frameworks like WinUI, with ongoing API additions for features such as adaptive theming and cloud integration. The decline of related platforms marked a shift in focus; support for ended on July 11, 2017, redirecting efforts toward UWP and cross-platform tools like .NET MAUI. support concluded on December 10, 2019, further emphasizing desktop and mixed-reality development. As of November 2025, WinRT remains a stable core technology, actively evolving within the , which delivers WinRT APIs via for packaged and unpackaged desktop apps across and 11.

Core Architecture

Technology Foundations

The Windows Runtime (WinRT) is built upon the (COM), extending it with modern abstractions for improved developer experience and performance. It uses a binary (ABI) for stability across language projections, ensuring that components can be consumed without recompilation. WinRT employs a threading model based on the single-threaded apartment (STA) for UI-related operations to maintain thread affinity, while supporting asynchronous programming patterns to avoid blocking the UI thread. This foundation enables efficient, secure access to system resources through isolated app containers.

Type System and Metadata

The Windows Runtime (WinRT) uses the format defined in the ECMA-335 standard for cross-language and . It supports a range of fundamental types including integers (Int16, Int32, Int64, UInt8, UInt16, UInt32, UInt64), floating-point numbers (, ), characters (Char16), , , Guid, and DateTimeOffset. Enums are restricted to 32-bit integer underlying types, while structs can compose primitives, enums, other structs, strings, and boxed values via IReference. This design ensures and automatic marshaling across language boundaries without requiring explicit conversion in most cases. Delegates in WinRT serve as type-safe pointers, implementing an Invoke via specific interfaces, with support for parameterized forms like those used in events. Events are handled through specific interfaces, employing add/remove listener that return an EventRegistrationToken for management, enabling invocation. Although generics are not exposed in language projections to maintain compatibility—appearing instead as concrete types like Vector—they are supported internally through parameterized interfaces such as IVector and IIterable, which system APIs can define but third-party components cannot extend with new variants. This internal genericity facilitates collections and async patterns while projecting to idiomatic forms in languages like C# or . WinRT metadata is stored in .winmd files, which adhere to the ECMA-335 (CLI) format and contain only metadata for introspection, excluding executable code in system assemblies to promote stability and versioning. These files encode type definitions—including interfaces, runtime classes, delegates, structs, and enums—using CLI metadata tables, with public types flagged as Windows Runtime compliant (tdWindowsRuntime). The metadata enables runtime and compile-time generation of bindings, allowing projections to map WinRT types to native equivalents without access to ; for instance, tools parse .winmd to produce headers or proxies. File naming must match the primary , and version strings are fixed to "Windows Runtime 1.2" for compatibility. Introspection in WinRT relies on the IInspectable interface, which all public WinRT interfaces must implement, providing methods like GetIids, GetRuntimeClassName, and GetTrustLevel for runtime type discovery. WinRT components are defined as runtime classes that inherit from Object (implementing IInspectable), instantiated via activation factories (IActivationFactory) that support direct activation, factory-based creation, or composition models. Projections leverage this metadata to resolve types dynamically, mapping interfaces to language-specific constructs while enforcing restrictions such as no static members or methods in public projections to avoid cross-language inconsistencies. Private implementations can use language-specific features like C++ templates internally. Unlike the (COM), which relies on IUnknown for basic querying and manual marshaling, WinRT simplifies contract definition using Microsoft Interface Definition Language (MIDL) 3.0, a streamlined IDL syntax that generates metadata directly without raw pointers or explicit interface inheritance. MIDL 3.0 employs C++-like declarations for namespaces, classes, and interfaces, reducing verbosity by about two-thirds compared to prior versions, and includes keywords like "requires" for interface dependencies. Automatic serialization is built-in for parameters, handling value types (structs passed by value), reference types, and arrays via predefined patterns, eliminating much of COM's custom proxy/stub code while ensuring ABI stability across projections.

Services and Components

The Windows Runtime (WinRT) provides projection services that enable seamless across programming languages by leveraging contained in .winmd files. These services include metadata readers, which resolve namespaces and types at compile-time and runtime using Windows APIs, and activation stubs generated for runtime classes marked with the ActivatableAttribute. Activation stubs support direct instantiation or factory-based activation, as defined in the MethodDef tables of .winmd files, allowing tools in the Windows SDK to project WinRT types into language-specific constructs, such as mapping IVector to IList in .NET projections. Built-in components form the foundational layer of WinRT, primarily housed in the Windows.Foundation , which supports essential operations like URI handling through the class for parsing and manipulating resource identifiers across various . Collection interfaces such as IIterable enable over sequences, while IVector provides dynamic, random-access lists for data manipulation in applications. Event handling is facilitated by the TypedEventHandler<TSender, TResult> delegate, which supports typed sender and result parameters for robust, event-driven architectures in WinRT apps. Component authoring in WinRT follows strict guidelines to ensure cross-language compatibility, requiring developers to define runtime classes that implement interfaces and use attributes like to enable . For , classes can specify a default path via ActivatableAttribute without a interface or multiple attributes for specific interfaces, limiting out parameters to the returned instance and requiring at least one input parameter for methods. Tools such as the MIDLRT compiler process IDL files to generate .winmd files—using switches like /winmd and /winrt—while the MDMERGE composes multiple .winmd files into namespace-based outputs for efficient packaging. Runtime services in WinRT handle errors through mappings from HRESULT codes to language-specific exceptions; for instance, failure HRESULTs at the ABI layer are converted to exceptions like hresult_error in C++/WinRT or COMException in .NET projections, with properties like ErrorCode in async interfaces providing detailed error reporting. Asynchronous operations are managed via the IAsyncInfo base interface and its derivatives (IAsyncAction, IAsyncOperation, and progress-reporting variants), which expose properties for status tracking, cancellation via the method, and resource cleanup with Close, integrating with language features like await for non-blocking execution. WinRT integrates with XAML through support in the , enabling components to connect to data sources via interfaces like IBindableIterable for enumerable collections and IBindableObservableVector for change-notifying lists that raise VectorChanged events. These interfaces project to familiar types in other languages, such as IEnumerable and IList in .NET, allowing dynamic updates without direct XAML modifications to WinRT core logic.

API Design

Runtime Classes and Interfaces

The Windows Runtime (WinRT) employs a structured set of core interfaces that underpin its object model and enable interoperability across languages. The IUnknown interface serves as the foundational element, inherited from the (COM), and manages object lifetime through reference counting with its AddRef and Release methods, while QueryInterface allows querying for supported interfaces on an object. All WinRT interfaces implicitly derive from IInspectable, which extends IUnknown to provide runtime type introspection via methods like GetRuntimeClassName (returning the fully qualified class name) and GetTrustLevel (indicating the object's security context, such as base or partial trust). This hierarchy ensures that every WinRT object supports metadata querying and safe reference management, facilitating seamless projection into diverse programming languages. Asynchronous programming is integral to WinRT's design to avoid blocking the UI thread, achieved through specialized interfaces in the Windows.Foundation namespace. The IAsyncOperation interface represents an asynchronous operation that yields a result of type TResult, supporting cancellation via IAsyncInfo.Cancel, progress reporting through IAsyncOperationWithProgress<TResult, TProgress>, and completion handling with Completed events; for instance, it is used in APIs like file loading where the result is a object. Complementing this, IAsyncAction handles void-returning asynchronous tasks, such as animations or network requests, enabling fire-and-forget patterns without a specific result. These interfaces enforce a consistent async model, where operations run on background s and notify callers upon completion, error, or cancellation, promoting responsive applications. Runtime classes in WinRT form the primary programming surface, typically declared as sealed to prevent and encourage over extension, aligning with the platform's emphasis on immutability and predictability. For example, the Uri class in Windows. is a sealed runtime class that encapsulates Uniform Resource Identifiers, offering factory-based through static methods like CreateUri(string relativeUri) or constructors such as new Uri(string absoluteUri) to parse and validate URI components like host and path. Similarly, EventHandler is a generic delegate treated as a runtime class, enabling event subscription with a signature of void (IInspectable sender, T args), where it supports multicast invocation for handling events like property changes. Object creation often relies on activation factories, which implement IActivationFactory to produce instances via ActivateInstance, ensuring classes are instantiated through metadata-driven mechanisms rather than direct new expressions in all projections. WinRT organizes its APIs into a hierarchical namespace structure prefixed with Windows., promoting logical grouping by functionality and reducing naming conflicts. The Windows.Foundation namespace provides core utilities like URI handling and async primitives, while Windows.Storage encompasses file and folder operations, such as streams and pickers for user-selected paths. and UI elements fall under Windows.UI, including sub-namespaces like Windows.UI.Xaml for XAML-based controls and Windows.UI.Composition for visual effects, enabling developers to navigate the API surface intuitively based on domain-specific needs. Collections in WinRT are abstracted through generic interfaces that support dynamic manipulation and data binding, distinct from language-native types to ensure cross-language consistency. IVector models a resizable , allowing indexed , insertion, and removal of elements, with implementations like Vector providing the concrete . Likewise, IMap<K, V> represents a key-value for associative storage, supporting operations like Lookup(K key) and Insert(K key, V value). Change notifications are built-in via VectorChanged and MapChanged events, which fire with IVectorChangedEventArgs or IMapChangedEventArgs to report modifications such as insertions or resets, enabling reactive UI updates in scenarios like list bindings. Extensibility in WinRT's type system includes treating delegates as first-class runtime classes, defined via the MIDL3 delegate keyword to specify callable signatures that can be passed as parameters or assigned to events. For instance, a delegate like delegate void CallbackHandler(IInspectable sender, Object args) allows flexible event handling without tight coupling to specific classes. Language projections support lambda expressions for these delegates, enabling concise inline implementations—such as capturing variables in C++ or C#—that are automatically adapted to the runtime class representation, thus bridging paradigms with WinRT's object-oriented foundation.

Naming Conventions

The Windows Runtime (WinRT) employs standardized naming conventions for its APIs to promote consistency, readability, and seamless interoperability across various programming languages. These conventions are defined in the WinRT metadata format and apply to interfaces, classes, methods, properties, parameters, events, and namespaces, ensuring that developers can intuitively understand and use the APIs regardless of the projection language. Interfaces in WinRT are prefixed with "I" and use PascalCase for the remainder of the name, such as IVector<T> for a generic vector interface. Properties and methods within interfaces follow a verb-noun pattern where applicable, for example, GetItems for retrieving a collection of items, emphasizing action-oriented descriptors that clearly indicate functionality. Runtime classes lack any prefix and use descriptive PascalCase names that reflect their purpose, such as StorageFile for handling file operations. Events are named in the past tense to indicate completed actions, like FileCreated in file system notifications, aligning with the semantic intent of reporting occurrences. Parameter and property names prioritize full, descriptive words over abbreviations to enhance clarity, for instance, using "index" instead of "idx" for array positions. Asynchronous methods append "Async" to their names, following the pattern <verb>[<noun>]Async, such as CopyAsync for file copying operations, to distinguish them from synchronous counterparts and signal potential latency. Namespaces begin with "Windows" followed by a category descriptor, such as Windows.Devices for interactions or Windows.Storage for file management, maintaining shallow nesting typically limited to one or two levels to avoid complexity. This structure organizes logically by functional domain. While the core WinRT metadata adheres to PascalCase for all identifiers to ensure uniformity in the binary metadata, language projections adapt casing for idiomatic usage; for example, projections convert to camelCase, rendering GetItems as getItems and StorageFile as StorageFile (with methods and properties adjusted). These adjustments preserve the underlying semantics without altering the metadata.

Restrictions and Rules

The Windows Runtime imposes strict rules on component design to ensure secure, efficient, and interoperable across languages. Public runtime classes cannot expose constructors; instead, occurs through factory methods provided by the class's factory, which implements IActivationFactory to support parameterless or parameterized instantiation. Public classes in language projections, such as C# or , must be sealed to prevent outside the runtime's control. Static methods and fields are not directly exposed on classes; any static functionality must be accessed via static interfaces on the factory. API surfaces face additional limitations to maintain and avoid complexity in projections. Generics are prohibited in public interfaces or classes defined by third parties; instead, runtime-provided templated collections like IVector or IMap<K,V> handle parameterized scenarios. Types should be designed as immutable where feasible, particularly for structs limited to value types or strings as fields, to promote and reduce side effects. Circular references are forbidden in parameterized type instantiations, such as mutual dependencies in generic-like structures, to prevent issues during . Security restrictions enforce a sandboxed model, requiring explicit capabilities for access to sensitive resources. APIs involving hardware like the demand declaration of the "webcam" capability in the app manifest, granting user-consented access only within the AppContainer isolation. Direct access is barred outside designated libraries (e.g., picturesLibrary); apps must use file pickers or scoped capabilities to avoid unauthorized data exposure. These rules align with the runtime's enforcement for capability checks. Performance guidelines prioritize efficiency in resource-constrained environments. Value types, such as structs, are preferred over types for small, frequently used to minimize heap allocations and garbage collection overhead. All I/O operations must be asynchronous, returning types like IAsyncOperation to prevent blocking and ensure , as synchronous variants are unavailable for long-running tasks. For collections, batch operations—such as bulk inserts via methods on IVector—are recommended over iterative additions to reduce overhead in high-volume scenarios. Compatibility is maintained through contract-based versioning, where are grouped into contracts like Windows.Foundation.1.0, allowing additive changes without breaking existing binaries. Updates must be strictly additive, appending new members or overloads while preserving existing behaviors, to support forward and across Windows versions.

Language Projections

C++ Implementations

The Windows Runtime (WinRT) provides several projections for C++ developers to consume and author components, evolving from language extensions to standard C++ libraries. The original projection, , introduced in , uses language extensions such as the (^) for reference handles to WinRT objects and the ref class keyword to define WinRT classes, enabling and akin to managed languages. This approach simplified development but relied on non-standard extensions, and now considers it superseded, recommending migration to standard C++ alternatives for new projects. For lower-level control without language extensions, the Windows Runtime C++ Template Library (WRL) offers COM-style wrappers, allowing manual management of WinRT interfaces through templates like RuntimeClass and Implements, which handle activation factories and explicitly. WRL provides fine-grained access suitable for integrating code but requires more boilerplate than higher-level projections and has been deprecated in favor of modern options, lacking full support for newer productivity features. The current standard projection is C++/WinRT, a library released in 2017 and integrated into the Windows SDK starting with version 10.0.17134.0 (), designed for idiomatic usage without extensions. It employs std::shared_ptr for object lifetime management, ensuring automatic cleanup and , and supports coroutines for asynchronous operations via winrt::resume_foreground and winrt::resume_background to integrate with WinRT's async patterns. C++/WinRT entered in 2023, receiving bug fixes but no new features, as shifts focus to broader integrations. To author WinRT components in C++, developers use C++/WinRT's winrt::implements template to derive classes from interfaces, enabling implementation of contracts like IInspectable for metadata exposure, while avoiding direct use of namespace attributes like Windows::Foundation::Metadata which are more common in managed projections. Interface Definition Language (IDL) files, compiled with MIDL 3.0, define public contracts in a concise syntax, generating stubs that integrate with C++ code; the cppwinrt.exe tool then processes the resulting metadata to produce header files and a .winmd assembly for distribution. This process ensures binary compatibility across languages, with components built as DLLs that can be referenced via project templates. C++/WinRT integrates seamlessly with , offering project templates for UWP and desktop apps since Visual Studio 2017, and is distributed via packages for easy inclusion in existing projects without SDK dependencies beyond conformance. For example, consuming the Windows::Storage APIs involves including <winrt/Windows.Storage.h> and acquiring a StorageFolder via winrt::single_threaded<>() for initialization, then invoking async methods like GetFileAsync with coroutines to handle file operations efficiently.

.NET Integration

The Windows Runtime (WinRT) integrates with the .NET ecosystem through language projections that enable managed code developers to consume and author WinRT APIs using C# and . Central to this integration is the use of Windows (.winmd) files, which contain type definitions for WinRT components. .NET tools, such as the C# , generate projection assemblies from these .winmd files, creating managed wrappers that map WinRT constructs to familiar .NET equivalents. For instance, WinRT asynchronous operations are projected to .NET's Task and Task types, while WinRT collections like IIterable map to IEnumerable and IVector to IList, facilitating seamless use in managed code without direct interaction with native interfaces. A key advancement in this integration is C#/WinRT, a package introduced in 2020 that provides a modern projection layer for WinRT in C#. Unlike earlier built-in support in the .NET Framework, which was deprecated starting with .NET 5, C#/WinRT generates interop assemblies on-the-fly or at build time, ensuring compatibility with .NET 6 and later versions. This toolkit not only allows consumption of existing WinRT APIs but also supports authoring custom WinRT components directly in C#, offering improved performance over legacy approaches like C++/CX by leveraging standard C# features such as records and . Developers install it via as Microsoft.Windows.CsWinRT, which handles parsing and type projection without requiring additional extensions. In (UWP) applications, .NET integration with WinRT occurs through the Windows SDK, where C# projects reference WinRT namespaces for building apps with XAML-based user interfaces. For example, developers can access Windows.UI.Xaml to create controls like Button or , binding them to .NET data models while using WinRT services for tasks such as notifications or file I/O. However, limitations exist, including restricted on projected WinRT types to maintain and ; attempts to use System. on these types may fail or require explicit directives. UWP apps traditionally compile via .NET Native, a precompilation tool that translates managed IL to native code for faster startup and reduced footprint, though this is distinct from standard .NET execution. Support differs between .NET Framework and modern .NET versions: the .NET Framework (up to 4.8) provided built-in WinRT projections for Windows 8.1-era apps, but .NET Core and .NET 5+ removed direct .winmd consumption, relying instead on C#/WinRT for desktop bridging to access WinRT in non-UWP scenarios like WinForms or WPF applications. This enables desktop apps to leverage WinRT features, such as modern storage , by targeting frameworks like net6.0-windows10.0.19041.0, which includes Windows SDK references. Event handling exemplifies this: WinRT events project to .NET delegates, allowing C# code to subscribe via += operators, as in attaching a handler to a XAML from Windows.UI.Xaml.Controls.

JavaScript and Other Languages

The Windows Runtime provided a dedicated projection for JavaScript, enabling developers to access WinRT APIs directly within HTML and JavaScript-based applications, primarily for Universal Windows Platform (UWP) apps. This projection was extensively used in Windows Store apps (now Microsoft Store), where JavaScript served as the scripting language for UI and logic implementation. Through this projection, WinRT namespaces and types were exposed under the global Windows object, allowing seamless integration with web technologies. Asynchronous operations, which are prevalent in WinRT APIs, were mapped to JavaScript promises, facilitating non-blocking code patterns common in web development; for instance, methods like showAsync on Windows.UI.Popups.MessageDialog returned a promise that resolved upon completion. Collections in WinRT, such as those used for lists or commands, were projected as native JavaScript arrays, supporting familiar operations like push and iteration. A representative example is local data persistence via Windows.Storage.ApplicationData.current.localSettings, which allowed storing key-value pairs in a sandboxed environment, with values accessed through dynamic object properties. The Chakra JavaScript engine, integrated into the Windows runtime, powered script execution, ensuring high performance for WinRT interactions within these apps. However, support for JavaScript UWP apps has been deprecated. As of Visual Studio 2019 and later versions (including 2022), JavaScript UWP projects are no longer supported; developers cannot create or open such projects (files with .jsproj extension). The remains available for maintaining existing legacy apps but is not recommended for new development. As a dynamic language, handled WinRT's static through the projection's mapping, employing for compatibility where types were inferred by behavior rather than declaration; however, this introduced limitations, such as the inability to author WinRT components in JavaScript, restricting it to consumption only. The projection also did not support advanced features like class composition, simplifying but constraining certain WinRT patterns. In mixed-language scenarios, JavaScript was often used for logic in UWP apps, invoking WinRT components authored in C++ or .NET for backend functionality. Beyond the core projections for C++, .NET, and , support for other languages is limited and primarily community-driven or experimental, with no official full projections from . For , the windows crate provides bindings to WinRT , enabling Rust code to call and interact with Windows Runtime types through generated safe wrappers, as part of Microsoft's Rust for Windows initiative. support is available via the Python/WinRT library, which generates projections for most non-XAML WinRT , allowing scripts to invoke them directly; however, this is more suited for scripting and rather than full development, often relying on interop for broader compatibility. These extensions expand WinRT accessibility but lack the native integration and performance optimizations of the primary languages.

Interoperability Bridges

The Windows Runtime (WinRT) provides several mechanisms to enable between its native component model and or non-native codebases, facilitating the of existing applications with WinRT APIs. These bridges allow developers to leverage WinRT's metadata-driven projections while accommodating traditional Win32 applications and cross-language scenarios, though they introduce specific constraints to maintain and security. One primary bridge is the Desktop Bridge, introduced in as part of the Windows 10 Anniversary Update, which enables the packaging of traditional Win32 desktop applications using the MSIX format. This approach allows legacy Win32 code to run within a (UWP) context, granting access to WinRT APIs such as notifications and live tiles while preserving the app's existing functionality. By wrapping the Win32 executable in an MSIX package, the Desktop Bridge provides the app with a package identity, enabling it to call WinRT components that require elevated privileges or store distribution, effectively bridging the gap between classic desktop apps and the UWP ecosystem. WinRT is fundamentally built on the (COM), inheriting its activation and interface mechanisms while extending them for broader language support. All WinRT interfaces derive from IUnknown, the foundational COM interface, with WinRT classes additionally implementing IInspectable, which adds metadata introspection capabilities like querying runtime class names and supported interfaces. This COM foundation enables seamless interop with legacy COM components; for instance, .NET developers can use tools like tlbimp.exe to generate type libraries from WinRT metadata, creating proxies that allow .NET code to consume WinRT objects as if they were native COM interfaces, though with restrictions on certain dynamic features like late binding. Cross-language activation in WinRT relies on brokers and marshaling layers within projections to facilitate calls between different programming s. For example, a JavaScript-based UWP app can and invoke methods on a C++ WinRT component through the 's factory mechanism, where the JavaScript projection marshals parameters via the WinRT , ensuring type coercion and security boundaries are enforced by the broker process. These brokers handle the underlying while abstracting -specific details, such as converting JavaScript promises to asynchronous operations in C++. While official projections cover C++, .NET, and , third-party bridges for languages like or typically rely on foreign function interfaces (FFI) to interact with WinRT's underpinnings, though such integrations remain unofficial and require manual handling of . Developers can extend projections by authoring custom WinRT components that expose FFI-compatible entry points, following Microsoft's guidelines for -compliant interfaces to ensure compatibility. Interoperability in WinRT comes with notable limitations, including the absence of bidirectional support for s, where custom types or interfaces cannot be freely marshaled across projections due to the runtime's strict . Additionally, marshaling introduces overhead, particularly for complex data types crossing language boundaries, as the runtime performs and validation to prevent type mismatches, which can impact scenarios involving frequent interop calls. Optimization techniques, such as minimizing cross-projection boundaries and using value types over references, are recommended to mitigate these costs.

Platform Implementations

Windows Desktop and Server

The Windows Runtime (WinRT) enables integration with traditional Win32 applications starting from , allowing developers to leverage modern system features without fully migrating to a (UWP) model. In C++ projects, this is achieved by including the <winrt/base.h> header from the C++/WinRT library, which provides access to WinRT APIs for functionalities such as toast notifications, file handling, and sensor data. For example, a application can display interactive toast notifications using the Windows.UI.Notifications namespace, enhancing user engagement with minimal code changes. Enhancements in Windows 10 and later versions further support mixing WinRT components directly with Win32 code, including through the Desktop Bridge (also known as MSIX packaging), which embeds UWP controls like XAML Islands into classic applications. This approach, available since for the Visual Layer and version for XAML Islands, allows legacy desktop apps to incorporate modern UI elements and APIs while retaining compatibility with existing Win32 infrastructure. WinRT support was introduced in , where it primarily serves headless services without UI-dependent APIs, emphasizing core functionalities like storage access via the Windows.Storage namespace and networking through Windows.Networking. Many foundational WinRT interfaces, such as IInspectable, require at least as the minimum supported server platform, enabling server-side development for asynchronous operations and system resource management. In server environments, WinRT facilitates use cases such as background tasks for scheduled processing and push notifications via Windows Push Notification Services (WNS) integration, often implemented in console or service applications using C++/WinRT for non-interactive scenarios. .NET Core and later versions support server-side consumption of WinRT APIs through projections like C#/WinRT, a package that generates interop assemblies, although built-in .NET Framework-style WinRT support was removed starting with .NET 5 to allow independent evolution. WinRT continues to be available in current editions, including for hybrid applications that bridge on-premises and cloud workloads, but it typically plays a secondary role to more specialized .NET APIs for server development.

Universal Windows Platform

The (UWP), introduced with in 2015, serves as an application development platform built directly on the Windows Runtime (WinRT), enabling developers to create a single application binary that runs across a wide range of devices including PCs, tablets, consoles, and mixed-reality headsets. This unified approach leverages WinRT's component-based architecture to provide a consistent surface, allowing apps to adapt their dynamically to different form factors through responsive design elements such as universal controls and layout panels that scale based on screen size, resolution, and input methods like touch or . Key features of UWP include AppX packaging, which bundles app code, resources, and metadata into a secure, signed container for reliable deployment and updates; distribution through the , which handles installation, licensing, and monetization options like in-app purchases; and live tiles on the that display dynamic content and notifications to enhance user engagement. WinRT APIs in UWP are extended via contracts—declarative interfaces that enable apps to interact with device-specific capabilities—and are tailored to device families (such as , mobile, or ) through extension SDKs that expose family-appropriate while maintaining core compatibility. UWP app development relies on , which provides dedicated project templates for languages like C#, C++/WinRT, and , along with built-in WinRT projections that map native WinRT components to idiomatic syntax in each language, streamlining access to platform APIs. These tools support adaptive scaling, where apps use effective pixels and vector-based resources to ensure optimal rendering across varying display densities and orientations without manual reconfiguration. UWP has continued to evolve beyond , remaining fully supported in , where apps can run on ARM-based devices either natively or via built-in x86/x64 emulation for broader compatibility. with WinUI 3 allows UWP developers to incorporate modern Fluent Design controls and theming while retaining WinRT foundations. However, UWP imposes a stricter sandboxed environment than traditional desktop applications to enhance and stability, restricting direct access to Win32 APIs and requiring interoperability bridges for legacy code .

Legacy Mobile Platforms

Windows Phone 8, released in 2012, implemented a subset of the Windows Runtime (WinRT) primarily as a bridge for Silverlight-based applications, enabling access to select native capabilities without full convergence. This subset included APIs for device sensors, such as and data via the Windows.Devices.Sensors namespace, and support for push notifications through the Microsoft Push Notification Service (MPNS), which allowed apps to receive remote updates for tiles and toasts. The design prioritized compatibility with existing Silverlight development workflows while introducing WinRT components, often through C++ runtime libraries, to handle hardware interactions that Silverlight alone could not address efficiently. Windows Phone 8.1 marked a significant , achieving full with the WinRT implementation in and serving as a direct precursor to the Universal Windows Platform (UWP). This convergence replaced the Silverlight app model with a native WinRT-based runtime, allowing developers to build universal apps that shared code and XAML across desktop/tablet and platforms using a single solution. Key features included comprehensive XAML support for UI design and integration for graphics-intensive applications, enabling richer experiences like and advanced animations. The shared WinRT surface facilitated portability, with platform-specific extensions handled via conditional compilation, though mobile-specific optimizations ensured compatibility with touch-first interfaces. The transition to in 2015 fully unified WinRT under the UWP framework, allowing apps to target a continuum of devices from phones to desktops with a consistent . This unification extended the WinRT model to include mobile telephony features, such as call management and SIM access via the Windows.Phone.Telephony namespace, while maintaining for apps. However, ended support for on December 10, 2019, ceasing all security updates, bug fixes, and technical assistance thereafter. Developers were advised to migrate existing apps to or platforms, as the ecosystem shifted focus away from dedicated mobile Windows development. A core distinction in these legacy mobile implementations was the tailored API surface to accommodate device constraints, featuring a reduced set of WinRT endpoints compared to versions to optimize for battery life and . For instance, APIs in the .Devices.Power namespace allowed apps to monitor and respond to battery states, minimizing drain during background operations. Telephony-specific APIs, unique to , provided functionalities like retrieval and cellular data control, which were absent or limited in non-mobile WinRT profiles. These adaptations highlighted WinRT's flexibility for scenarios but underscored the platform's mobile origins in balancing performance with hardware limitations. As of 2025, WinRT on legacy platforms remains fully deprecated, with no ongoing updates or maintenance from , serving primarily as a historical for understanding the runtime's initial expansion to portable devices. The absence of support has rendered these implementations obsolete for new development, emphasizing the shift toward cross-platform alternatives.

Current Status

Maintenance and Evolution

The Windows Runtime (WinRT) has seen annual updates through the Windows SDK, aligned with major Windows releases, providing refreshed headers, libraries, and metadata for WinRT APIs. For instance, the Windows SDK version 10.0.26100, released alongside version 24H2 in 2024, included minor extensions to WinRT support, such as updated API projections and compatibility improvements for existing components. Similarly, the Windows SDK updates for version 25H2, released in October 2025, continued these minor extensions and compatibility improvements. These updates maintain while incorporating enhancements tied to the host operating system's evolution, ensuring stability for applications developed against earlier SDKs. C++/WinRT, the standard C++ projection for WinRT, focuses on bug fixes and reliability improvements, with ongoing contributions via its official GitHub repository. The core WinRT runtime itself has remained stable since Windows 10, serving as a foundational component of the operating system with no major architectural changes. Security for WinRT, including its broker processes that enforce app isolation, continues through monthly cumulative updates to Windows 11, which address vulnerabilities across system components. Microsoft has deprecated C++/CX, the earlier C++ language extension for WinRT, in favor of the header-only library, phasing it out to encourage adoption of standard features. No new language projections for WinRT are planned, reflecting the runtime's mature status. Community engagement persists via active repositories, such as the official project, which receives ongoing contributions for fixes and documentation. 2022 provides full built-in support for C++/WinRT, eliminating the need for separate extensions and streamlining development workflows.

Relation to Modern Frameworks

The Windows App SDK, formerly known as Project Reunion, serves as a key modern framework that builds upon the Windows Runtime (WinRT) by providing a unified set of APIs and tools for developing desktop applications targeting Windows 10 version 1809 and later, ensuring consistent behavior across different Windows versions without requiring version-specific adaptations. This abstraction layer exposes WinRT APIs in a stable manner, allowing developers to access platform features reliably regardless of the underlying OS version, and includes both WinRT and native C APIs to support diverse app architectures. Introduced to streamline development beyond traditional UWP constraints, the SDK enables packaged desktop apps that leverage WinRT's component model while decoupling from OS-specific SDK dependencies. A primary integration point is WinUI 3, released in 2021 as part of the , which uses WinRT as its foundational backend to deliver modern user interface controls and styles for both packaged and unpackaged desktop applications. WinUI 3 extends WinRT's XAML-based capabilities, originally designed for UWP, to broader desktop scenarios, allowing developers to create native Windows experiences with features like improved theming and . This enables apps to incorporate contemporary UI elements while maintaining WinRT's projection support for languages such as C# and C++, facilitating seamless interop in mixed-language environments. The framework's decoupling from the Windows SDK further emphasizes WinRT's role in providing a forward-compatible surface. In cross-platform development, .NET (Multi-platform App UI) on Windows utilizes WinRT APIs through platform-specific implementations, enabling access to Windows-exclusive features like notifications, sensors, and integrations directly from MAUI apps. Developers employ partial classes and conditional in MAUI projects to invoke WinRT methods in the Windows folder, bridging the cross-platform abstraction with native WinRT functionality for enhanced performance in Windows-specific scenarios. This approach allows MAUI apps to call high-level WinRT services, such as those for geolocation or device capabilities, while abstracting lower-level details for multi-targeting across , , macOS, and Windows. WinUI further aligns with the , Microsoft's design language for immersive and adaptive user experiences, by building directly on WinRT's XAML controls to implement acrylic materials, parallax effects, and reveal highlights in desktop apps. This integration ensures that WinRT-powered UIs adhere to Fluent principles, promoting consistency with system-level interfaces like the shell. Extensions through the Windows Community Toolkit enhance this by providing additional WinRT-compatible controls and utilities, such as XAML Islands for hosting modern UI in legacy Win32, WPF, or WinForms applications, thereby extending WinRT's reach into hybrid modernization efforts. As of 2025, WinRT remains foundational in AI-driven frameworks, particularly through Windows Machine Learning (Windows ML), which exposes its via the Microsoft.Windows.AI.MachineLearning namespace in the for local on ONNX models using CPUs, GPUs, or DirectML accelerators. This allows developers to integrate features, such as or , into WinRT-based apps without external dependencies, supporting both in-box and distributions for broader compatibility. However, for high-performance scenarios, modern frameworks often supplement WinRT with direct Win32 calls to optimize resource usage and bypass projection overhead.

References

  1. [1]
    Reference for WinRT APIs - Windows UWP applications
    Windows Runtime (WinRT) is a set of application programming interfaces (APIs) that allow developers to create applications for the Windows operating system.
  2. [2]
    Windows Runtime - Reimagining App Development with the ...
    Aug 9, 2015 · The Windows Runtime is part of a reimagining of the developer experience for Windows. It's the modern Windows API surface used to create new Windows Store apps ...
  3. [3]
    Introducing C++/WinRT | Microsoft Learn
    The Windows Runtime (WinRT) is the technology behind the modern Windows API, and the core of the Universal Windows Platform (UWP). The same API can be used ...
  4. [4]
    The Windows Runtime (WinRT) type system - Microsoft Learn
    May 16, 2022 · Describes the Windows Runtime (WinRT) type system, and defines parameterized types, versioning, and other factors.
  5. [5]
    UWP Apps, the Windows Runtime, and the C Run-Time
    Oct 21, 2022 · Universal Windows Platform (UWP) apps are programs that run in the Windows Runtime that executes on Windows 8 and later.
  6. [6]
    Introduction to C++/WinRT - UWP applications | Microsoft Learn
    Nov 18, 2022 · C++/WinRT is an entirely standard modern C++17 language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library.
  7. [7]
    Call Windows Runtime APIs in desktop apps - Microsoft Learn
    Oct 4, 2022 · This topic describes how to set up your desktop app projects to use Windows Runtime (WinRT) APIs provided by the Windows OS.
  8. [8]
    Windows Server 2012 - Microsoft Lifecycle
    Windows Server Essentials released on January 2, 2013. Editions. Datacenter; Essentials; External Connector; for Embedded Systems; Foundation; Standard.
  9. [9]
    AppContainer isolation - Win32 apps | Microsoft Learn
    Jul 8, 2025 · Isolating the application from other windows, the AppContainer environment prevents the application from affecting other application interfaces.Credential Isolation · Device Isolation · File IsolationMissing: Runtime | Show results with:Runtime
  10. [10]
    What's a Universal Windows Platform (UWP) app? - Microsoft Learn
    Aug 21, 2024 · Windows 10 introduced the Universal Windows Platform (UWP), which provides a common app platform on every device that runs Windows. The UWP ...
  11. [11]
    Calling WinRT Components from a Win32 process via the Desktop ...
    Jul 6, 2017 · In today's post, we are covering another step you can take on your journey across the Desktop Bridge: specifically migrating business logic to Windows Runtime ...
  12. [12]
    Support for Windows Phone 8.1 has ended - Microsoft Lifecycle
    Aug 1, 2017 · Microsoft ended support for Windows Phone 8.1 on July 11, 2017. Windows Phone 8.1 users are no longer eligible to receive new security ...Missing: date | Show results with:date
  13. [13]
    Windows 10 Mobile End of Support - Microsoft Lifecycle
    Dec 21, 2018 · Windows 10 Mobile, version 1709 (released October 2017) is the last release of Windows 10 Mobile and Microsoft will end support on December 10, 2019.
  14. [14]
    Build desktop Windows apps with the Windows App SDK
    Jul 14, 2025 · The Windows App SDK will include both WinRT APIs and native C APIs. Consistent experience across Windows versions. As ... © Microsoft 2025.Use the Windows App SDK in... · Install tools for the Windows... · Downloads
  15. [15]
    Type system overview (C++/CX) - Microsoft Learn
    Jan 12, 2022 · By using the Windows Runtime architecture, you can use C++/WinRT, C++/CX, Visual Basic, Visual C#, and JavaScript to write apps and components.
  16. [16]
    Windows Metadata (WinMD) files - Windows UWP applications
    Dec 30, 2021 · Windows Runtime (WinRT) APIs are described in machine-readable metadata files with the extension .winmd (also known as Windows Metadata).
  17. [17]
    Introduction to Microsoft Interface Definition Language 3.0
    Jul 12, 2022 · MIDL 3.0 is a simplified, modern syntax for defining Windows Runtime types inside of Interface Definition Language (IDL) files ( .idl files).Use Cases For Midl 3.0 · Classes · Members
  18. [18]
    Windows.Foundation Namespace - Windows apps | Microsoft Learn
    The Windows.Foundation namespace enables fundamental Windows Runtime functionality, including managing asynchronous operations and accessing property stores. ...
  19. [19]
    MIDLRT and Windows Runtime components - Win32 - Microsoft Learn
    Nov 4, 2020 · Use the MIDLRT compiler to build metadata (.winmd) files for your custom Windows Runtime components. When your metadata files are generated ...
  20. [20]
    Error handling with C++/WinRT - UWP applications | Microsoft Learn
    Oct 20, 2022 · winrt::to_hresult handles exceptions derived from std::exception, and winrt::hresult_error and its derived types. In your implementation, you ...Avoid catching and throwing... · Catching exceptions
  21. [21]
    IAsyncInfo Interface (Windows.Foundation) - Microsoft Learn
    IAsyncInfo is an inherited interface for each of the 4 Windows Runtime interfaces that are used for asynchronous method support.Definition · Remarks
  22. [22]
    Windows.UI.Xaml.Interop Namespace - Microsoft Learn
    Provides basic types for cross-framework integration and interoperation. Notably, this includes interfaces and support types that enable binding patterns.
  23. [23]
    Concurrency and asynchronous operations with C++/WinRT
    Oct 20, 2022 · This introductory topic shows some of the ways in which you can both create and consume Windows Runtime asynchronous objects with C++/WinRT.
  24. [24]
    https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/concurrency
  25. [25]
    IActivationFactory (activation.h) - Win32 apps - Microsoft Learn
    Feb 22, 2024 · Implement the IActivationFactory interface when you create a class that you want Windows Runtime applications to use.
  26. [26]
    Windows Runtime (WinRT) namespaces - Apps - Microsoft Learn
    Provides Windows Runtime projections of Microsoft Direct3D APIs to enable Windows Runtime applications and components to exchange Direct3D surfaces and devices ...
  27. [27]
    Interfaces (Windows Runtime) - Win32 apps - Microsoft Learn
    Jun 22, 2022 · Represents the method that is called when an asynchronous action that reports progress completes. IAsyncInfo, Provides support for ...
  28. [28]
    Naming Guidelines - Framework Design Guidelines | Microsoft Learn
    The goal of this chapter is to provide a consistent set of naming conventions that results in names that make immediate sense to developers.General Naming Conventions · Capitalization Conventions · Names of NamespacesMissing: Runtime | Show results with:Runtime
  29. [29]
    Asynchronous programming - UWP applications - Microsoft Learn
    Oct 20, 2022 · By convention, the names of asynchronous APIs end with "Async" to indicate that part of their execution is likely to take place after control ...<|control11|><|separator|>
  30. [30]
    Windows Runtime components with C++/CX - UWP applications
    Oct 26, 2022 · To learn how to create a Windows Runtime component using C++/WinRT, see Windows Runtime components with C++/WinRT. ... Casing and naming rules.
  31. [31]
    Windows Runtime components with C# and Visual Basic
    Oct 20, 2022 · You can use managed code to create your own Windows Runtime types and package them in a Windows Runtime component.
  32. [32]
    App capability declarations - UWP applications | Microsoft Learn
    Oct 11, 2023 · The teamEditionDeviceCredential restricted capability allows apps to access APIs that request device account credentials on a Surface Hub ...Which kinds of apps do app... · Declaring capabilities
  33. [33]
    Asynchronous Programming in C++ Using PPL - Microsoft Learn
    All potentially blocking or long-running operations in WinRT are defined as asynchronous. By convention, the name of the method ends with “Async” and the return ...Asynchronous Programming... · Task Composition · Error Handling And...Missing: best | Show results with:best
  34. [34]
    C++/CX Language Reference - Microsoft Learn
    Oct 6, 2021 · C++/CX is a set of extensions to the C++ language that enable the creation of Windows apps and Windows Runtime components in an idiom that is as close as ...
  35. [35]
    Windows Runtime C++ Template Library (WRL) | Microsoft Learn
    Oct 17, 2022 · The Windows Runtime C++ Template Library (WRL) is a template library that provides a low-level way to author and use Windows Runtime components.
  36. [36]
    How to: Use existing C++ code in a Universal Windows Platform app
    Aug 3, 2021 · In Windows 10 and later, we recommend the C++/WinRT library instead of C++/CX. ... The WRL is deprecated, and it doesn't support all the ...
  37. [37]
    WinUI Community Call: November 5, 2025 #10851 - GitHub
    Oct 23, 2025 · The reason the issues page only lets you create a bug report is because cppwinrt is in maintenance mode and no longer receiving new feature work ...
  38. [38]
    Author APIs with C++/WinRT - UWP applications | Microsoft Learn
    Dec 18, 2023 · This topic shows how to author C++/WinRT APIs by using the **winrt::implements** base struct, either directly or indirectly.
  39. [39]
    NET mappings of Windows Runtime types - UWP applications
    Oct 20, 2022 · This article lists the mappings that .NET makes between Windows Runtime (WinRT) types and .NET types in Universal Windows Platform (UWP) ...
  40. [40]
    C#/WinRT - Windows apps | Microsoft Learn
    Mar 15, 2023 · C#/WinRT is a NuGet-packaged toolkit that provides Windows Runtime (WinRT) projection support for the C# language.
  41. [41]
    Microsoft.Windows.CsWinRT 2.2.0 - NuGet
    Nov 12, 2024 · C#/WinRT provides packaged WinRT projection support for the C# language. It is compatible with .NET 6 or later, and does not require any built- ...
  42. [42]
    Built-in support for WinRT is removed from .NET - Microsoft Learn
    Apr 2, 2022 · Starting in .NET 5, CoreCLR can no longer consume WinMD files directly. If you attempt to reference an unsupported assembly, you'll get a FileNotFoundException.
  43. [43]
    .NET Native and Compilation - UWP applications - Microsoft Learn
    Oct 20, 2022 · This article compares .NET Native with other compilation technologies available for .NET Framework apps, and also provides a practical overview of how .NET ...
  44. [44]
    JavaScript - Building and Using Controls in Windows Store Apps ...
    WinRT Controls: Controls exposed as Windows Runtime (WinRT) classes projected into JavaScript, such as Windows. UI. Popups.
  45. [45]
    microsoft/xlang - GitHub
    Rust for Windows - Tooling that creates WinRT, Win32 and COM APIs for the Rust programming language. Python. Python/WinRT - Support for calling most (non-XAML) ...
  46. [46]
    https://learn.microsoft.com/en-us/visualstudio/javascript/javascript-in-visual-studio?view=visualstudio
  47. [47]
    https://github.com/microsoft/xlang
  48. [48]
    Windows Runtime components with C++/WinRT - UWP applications
    Oct 20, 2022 · This topic shows how to use C++/WinRT to create and consume a Windows Runtime component—a component that's callable from a Universal Windows app ...
  49. [49]
    Understanding how packaged desktop apps run on Windows - MSIX
    Jun 27, 2023 · This topic describes the types of desktop apps that you can create a Windows app package for, together with some operating system (OS) behaviors.
  50. [50]
    Author COM components with C++/WinRT - UWP applications
    Oct 20, 2022 · C++/WinRT can help you to author classic Component Object Model (COM) components (or coclasses), just as it helps you to author Windows Runtime classes.How C++/WinRT behaves, by... · Enabling classic COM support
  51. [51]
    IInspectable (inspectable.h) - Win32 apps | Microsoft Learn
    Oct 9, 2023 · Provides functionality required for all Windows Runtime classes. Inheritance. The IInspectable interface inherits from the IUnknown interface.
  52. [52]
    Marshal should be able to handle generic types · Issue #4547 - GitHub
    Oct 6, 2015 · At that point not supporting generics is mostly a decision to scope the work, until WinRT came along and we had to support generic interfaces ...
  53. [53]
    Optimizing interop for Windows Runtime components - Microsoft Learn
    Jul 14, 2025 · The Windows Runtime has a library of types that are accessible from any language that can write a Universal Windows Platform app. You use the ...Introduction · Consider Using Types... · Copy Window Runtime Objects...<|separator|>
  54. [54]
    IClosable (windows.foundation.h) - Win32 apps | Microsoft Learn
    Mar 11, 2023 · If your closeable Windows Runtime object exposes an exclusive-use ... Windows Server 2012. Target Platform, Windows. Header, windows ...<|control11|><|separator|>
  55. [55]
    What's new in Windows Server 2025 | Microsoft Learn
    Feb 28, 2025 · This article describes some of the newest developments in Windows Server 2025, which boasts advanced features that improve security, performance, and ...Server 2022 · DTrace on Windows · Mica material
  56. [56]
    [PDF] Introducing Windows 10 for IT Professionals Technical Overview
    With Windows 10 Microsoft introduced the Universal Windows Platform (UWP), a highly evolved descendant of WinRT that provides a common app platform for ...
  57. [57]
    Create a "Hello, World!" UWP app using C++/WinRT - Microsoft Learn
    Oct 20, 2022 · This topic walks you through creating a Windows Universal Windows Platform (UWP) "Hello, World!" app using C++/WinRT.Set Up Visual Studio For... · Create A Blank App... · Runtime Classes
  58. [58]
    https://download.microsoft.com/download/F/4/2/F42AE0AD-A9CB-4EE7-A209-D9A399604A72/Microsoft_Press_eBook_Introducing_Windows_10_PDF.pdf
  59. [59]
    Intro to secure Windows app development - UWP applications
    Jul 8, 2024 · Windows apps have an app model that prevents unauthorized data access between apps, and offers encryption APIs to further secure data on the ...<|control11|><|separator|>
  60. [60]
    Windows 8 - Sharing Code between Windows Phone 8 and ...
    You might initially think you should check the box for Silverlight 5, but it isn't necessary for sharing code between Windows Store and Windows Phone apps. In ...
  61. [61]
    Windows Phone - Upgrading Windows Phone 7.1 Apps to Windows ...
    Upon first launch, you'll notice that it comes with two projects: a Windows Phone 8 project and a Windows Runtime (WinRT) Component in C++. Windows Phone HTML5 ...
  62. [62]
    Introduction to universal Windows apps in Windows 8.1 and ...
    Jul 24, 2014 · Universal Windows apps are there to allow the same app to be written for Windows 8.1 Store and Windows Phone 8.1 with little code changes.Missing: UWP precursors DirectX
  63. [63]
    Modern Apps - Build Universal Apps for the Windows Platform
    If you develop for the Windows platform, you can now write apps that target both Windows 8.1 and Windows Phone 8.1 with a single, shared codebase by creating a ...Modern Apps : Build... · Sharing Code Across Projects · Create Native Uis
  64. [64]
    Windows SDK - Windows app development | Microsoft Developer
    The Windows 10 WinRT API Pack lets you add the latest Windows Runtime APIs support to your .NET Framework 4.5+ and .NET Core 3.0+ libraries and apps. To access ...
  65. [65]
    C++/WinRT is now in maintenance mode. : r/cpp - Reddit
    Aug 8, 2023 · Not to worry, there will be a new standard next week to replace the one that replaced the one that replaced the one that replaced C++/WinRT.making use of C++/WinRT in a C++20 codebase : r/cpp - RedditC++/C# interop for Windows (desktop) applications using WinRTMore results from www.reddit.com
  66. [66]
    C++/WinRT: Transitioning to Maintenance Mode - Dev Radar
    Aug 8, 2023 · The article reveals that C++/WinRT, a popular programming language for Windows development, is now in maintenance mode.Missing: Microsoft | Show results with:Microsoft
  67. [67]
    Windows 11, version 24H2 update history - Microsoft Support
    On the left side of this page, you'll find a list of all the updates released for this version of Windows. You can also find more information about releases ...
  68. [68]
    What's up with error C4838: a WinRT type cannot be a member of a ...
    Sep 15, 2020 · The C++/CX language extension was written back when the latest C++ ... Just one of many reasons why C++/CX is deprecated in favor of C++/WinRT.
  69. [69]
    microsoft/cppwinrt: C++/WinRT - GitHub
    C++/WinRT is an entirely standard C++ language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library.Issues 2 · Actions · Activity
  70. [70]
    VS 2022 VSIX support · Issue #960 · microsoft/cppwinrt - GitHub
    Jun 17, 2021 · We'll continue to support the C++/WinRT marketplace extension for now, but just for VS2019. For VS2022, you get the same functionality right out ...
  71. [71]
    WinUI 3 - Windows apps | Microsoft Learn
    Jul 15, 2024 · WinUI 3 is the native UI platform component that ships with the Windows App SDK (completely decoupled from Windows SDKs).Create your first WinUI 3 project · Design for Windows apps · Microsoft IgniteMissing: WinRT backend
  72. [72]
    https://learn.microsoft.com/en-us/windows/apps/winui/
  73. [73]
    WinUI - Windows apps | Microsoft Learn
    Nov 8, 2024 · WinUI 3 ships as a component of the Windows App SDK framework package, with Visual Studio project templates in the Windows App SDK Visual Studio ...Missing: backend | Show results with:backend
  74. [74]
    Host WinRT XAML controls in desktop apps (XAML Islands)
    Aug 21, 2024 · The XAML Island .NET controls require Windows 10, version 1903, or a later version. To use these controls, install one of the NuGet packages ...Wpf And Windows Forms... · C++ Desktop (win32)... · Window Host Context For Xaml...
  75. [75]
    Get Started with Windows Machine Learning
    ### Summary: Windows ML WinRT APIs, Current Status 2025