Windows Runtime ( WinRT ) es una arquitectura de aplicaciones y componentes independiente de la plataforma que se introdujo por primera vez en Windows 8 y Windows Server 2012 en 2012. Está implementado en C++ y admite oficialmente el desarrollo en C++ (a través de C++/WinRT , C++/CX o WRL), Rust/WinRT , Python/WinRT , JavaScript - TypeScript y los lenguajes de código administrado C# y Visual Basic (.NET) (VB.NET).
WinRT no es un entorno de ejecución en el sentido tradicional, sino más bien una interfaz binaria de aplicación independiente del lenguaje basada en COM para permitir que las API orientadas a objetos se consuman desde múltiples lenguajes, con servicios generalmente proporcionados por un entorno de ejecución completo, como la activación de tipos. [1] Es decir, WinRT es un "sistema de entrega de API". Las aplicaciones que utilizan Windows Runtime pueden ejecutarse dentro de un entorno aislado para permitir una mayor seguridad y estabilidad y pueden soportar de forma nativa tanto x86 como ARM . [2] [3] Los componentes de WinRT están diseñados teniendo en cuenta la interoperabilidad entre múltiples lenguajes y API, incluidos los lenguajes nativos, administrados y de scripting. Las API integradas proporcionadas por Windows que utilizan la ABI de WinRT se conocen comúnmente como API de WinRT; sin embargo, cualquiera puede usar la ABI de WinRT para sus propias API.
WinRT se implementa en el lenguaje de programación C++ [4] y está orientado a objetos por diseño. [4] Su tecnología subyacente, la API de Windows (API Win32), está escrita principalmente en el lenguaje C. [5] Es una interfaz binaria de aplicación no administrada basada en el Modelo de objetos componentes (COM) que permite la interacción desde múltiples lenguajes, al igual que COM. Sin embargo, las definiciones de API se almacenan en archivos, que están codificados en formato de metadatos ECMA 335 , que .NET Framework también usa con algunas modificaciones. Para los componentes WinRT implementados en código nativo, el archivo de metadatos solo contiene la definición de métodos, clases, interfaces y enumeraciones y la implementación se proporciona en una DLL separada. [6] [7] [8] Este formato de metadatos común facilita el consumo de API de WinRT desde aplicaciones .NET con una sintaxis más simple que P/Invoke . [9] [ ¿ fuente poco confiable? ] Windows proporciona un conjunto de API integradas que se basan en la ABI de WinRT y que proporcionan todo, desde la biblioteca WinUI basada en XAML y acceso a dispositivos como cámara, micrófono, etc..winmd
El lenguaje C++/CX (Extensiones de componentes) anterior, que toma prestada cierta sintaxis de C++/CLI , se introdujo para escribir y consumir componentes WinRT con menos código de unión visible para el programador, en relación con la programación COM clásica en C++, e impone menos restricciones en relación con C++/CLI en la mezcla de tipos. Las extensiones de componentes de C++/CX se recomiendan para su uso solo en el límite de la API, no para otros fines. [10] El C++ normal (con disciplina específica de COM) también se puede utilizar para programar con componentes WinRT, [11] con la ayuda de la biblioteca de plantillas C++ de Windows Runtime (WRL), que es similar en propósito a lo que proporciona la biblioteca de plantillas activas para COM. [12] En 2019, Microsoft desaprobó C++/CX a favor de la biblioteca de encabezados C++/WinRT . [13]
La mayoría de las aplicaciones WinRT se ejecutan en un entorno aislado y necesitan la aprobación explícita del usuario para acceder a funciones críticas del sistema operativo y al hardware subyacente. De manera predeterminada, el acceso a los archivos está restringido a varias ubicaciones predeterminadas, como los directorios Documentos o Imágenes. [14]
Las aplicaciones WinRT se empaquetan en el formato de archivo .appx y más tarde en el .msix ; basado en las Convenciones de Empaquetado Abierto , utiliza un formato ZIP con archivos XML agregados. [15] Las aplicaciones WinRT se distribuyen principalmente a través de una tienda de aplicaciones llamada Microsoft Store , donde los usuarios pueden comprar y descargar aplicaciones de Windows (denominadas aplicaciones de Windows Store ). Inicialmente, las aplicaciones WinRT solo se podían cargar desde fuera de Windows Store en sistemas Windows 8 o RT que son parte de un dominio de Windows , o equipados con una clave de activación especial obtenida de Microsoft. [16] [17] [18] [19] Sin embargo, estas restricciones se levantaron en la Actualización de noviembre de Windows 10, donde los usuarios pueden cargar libremente cualquier aplicación firmada con un certificado de confianza habilitando una configuración. [20]
En una desviación importante de Win32 y de manera similar a .NET Framework 4.5 , la mayoría de las API que se espera que tarden un tiempo significativo en completarse se implementan como asincrónicas. Al llamar a una función asincrónica de Windows Runtime, la tarea se inicia en otro hilo o proceso y la función regresa inmediatamente, liberando a la aplicación para realizar otras tareas mientras espera los resultados. [21] El modelo asincrónico requiere nuevas construcciones de lenguaje de programación. Cada lenguaje proporciona su propia forma de consumir API asincrónicas. Las partes de la API incorporada que necesitan acceso asincrónico incluyen mensajes y cuadros de diálogo en pantalla, acceso a archivos, conectividad a Internet, sockets, transmisiones, dispositivos y servicios, y calendario, contactos y citas.
Los metadatos describen las API escritas con la ABI de WinRT. Definen un modelo de programación que permite escribir código orientado a objetos que se puede compartir entre lenguajes de programación y habilita servicios como la programación reflexiva (reflexión).
Herb Sutter , experto en C++ de Microsoft , explicó durante su sesión sobre C++ en la conferencia Build 2011 que los metadatos de WinRT tienen el mismo formato que los metadatos de CLI . [10] El código nativo (es decir, el código de máquina específico del procesador) no puede contener metadatos, por lo que se almacena en un archivo de metadatos separado que se puede reflejar como ensambles CLI ordinarios . [22] Dado que es el mismo formato que los metadatos de CLI, las API de WinRT se pueden usar desde lenguajes CLI administrados como si fuera solo una API .NET.
WinRT tiene un sistema de tipos basado en clases y orientado a objetos que se basa en metadatos. Admite construcciones con construcciones correspondientes en el marco .NET: clases , métodos , propiedades , delegados y eventos .
Una de las principales adiciones a WinRT en relación con COM es la interfaz binaria entre aplicaciones (ABI), genéricos de estilo .NET . Solo las interfaces y los delegados pueden ser genéricos, las clases de tiempo de ejecución y los métodos en ellos no pueden. Las interfaces genéricas también se conocen como interfaces parametrizadas. En C++/CX, se declaran utilizando la palabra clave genericcon una sintaxis muy similar a la de keyword template. Las clases WinRT (clases de referencia) también se pueden genericizar utilizando plantillas C++, pero solo las instancias de plantilla se pueden exportar a metadatos .winmd (con algo de alteración de nombres ), a diferencia de los genéricos WinRT que conservan su genericidad en los metadatos. WinRT también proporciona un conjunto de interfaces para contenedores genéricos que son paralelos a los de la biblioteca estándar de C++ , y los lenguajes proporcionan algunas funciones de conversión recíproca (de ida y vuelta). El consumo de colecciones WinRT en lenguajes .NET (por ejemplo, C# y VB) y en JavaScript es más transparente que en C++, con asignaciones automatizadas en sus equivalentes naturales que ocurren detrás de escena. Al crear un componente WinRT en un lenguaje administrado, se deben seguir algunas reglas adicionales de estilo COM, por ejemplo, los tipos de colección del marco .NET no se pueden declarar como tipos de retorno, sino que solo las interfaces WinRT que implementan se pueden usar en el límite del componente.
Las clases que se compilan para apuntar a WinRT se denominan componentes WinRT . Son clases que se pueden escribir en cualquier lenguaje compatible y para cualquier plataforma compatible. La clave son los metadatos. Estos metadatos hacen posible la interacción con el componente desde cualquier otro lenguaje WinRT. El entorno de ejecución requiere que los componentes WinRT que se compilan con .NET Framework utilicen los tipos de interfaz definidos o las interfaces de tipo .NET, que se asignan automáticamente a la primera nombrada. La herencia aún no se admite en los componentes WinRT administrados, excepto para las clases XAML. [23]
Los programas y bibliotecas destinados al entorno de ejecución de WinRT se pueden crear y utilizar desde varias plataformas y lenguajes de programación. En particular, C / C++ (ya sea con extensiones de lenguaje que ofrecen compatibilidad de primera clase con los conceptos de WinRT o con una biblioteca de plantillas de nivel inferior que permite escribir código en C++ estándar), .NET ( C# y Visual Basic (.NET) (VB.NET)) y JavaScript . Esto es posible gracias a los metadatos. En la terminología de WinRT, un enlace de lenguaje se denomina proyección de lenguaje.
El C++ estándar es un ciudadano de primera clase de la plataforma WinRT. A partir de Windows 10, versión 1803, el SDK de Windows contiene C++/WinRT. C++/WinRT es una proyección de lenguaje C++17 completamente estándar y moderna para las API de Windows Runtime (WinRT), implementada como una biblioteca basada en archivos de encabezado y diseñada para proporcionar acceso de primera clase a la API de Windows moderna. Con C++/WinRT, las API de Windows Runtime se pueden crear y consumir utilizando cualquier compilador de C++17 compatible con estándares. WinRT es una plataforma nativa y admite cualquier código C++ nativo (y estándar), de modo que un desarrollador de C++ puede reutilizar bibliotecas nativas de C/C++ existentes. Con C++/WinRT, no hay extensiones de lenguaje.
Existen otras dos opciones heredadas para usar WinRT desde C++: Windows Runtime C++ Template Library (WRL), una biblioteca de plantillas de estilo ATL (similar a Windows Template Library o WTL), y C++/CX (C++ con extensiones de componentes) que se parece a C++/CLI. [24] Debido a los requisitos de consumo interno de Microsoft, WRL no tiene excepciones, lo que significa que su disciplina de valor de retorno está basada en HRESULT al igual que la de COM. [25] Por otro lado, C++/CX envuelve las llamadas a WinRT con código que realiza la verificación de errores y lanza excepciones según corresponda. [26]
C++/CX tiene varias extensiones que permiten la integración con la plataforma y su sistema de tipos. La sintaxis se parece a la de C++/CLI, aunque produce código nativo (aunque no estándar) y metadatos que se integran con el entorno de ejecución. Por ejemplo, los objetos WinRT pueden asignarse con ref new, que es el equivalente de gcnewde C++/CLI. El operador hat ^conserva su significado, sin embargo, en el caso en que tanto el llamador como el llamador estén escritos en C++ y vivan en el mismo proceso, una referencia hat es simplemente un puntero a un vptr a una tabla de métodos virtuales (vtable, VMT). [26]
Junto con C++/CX, en relación con la programación COM tradicional en C++, existen clases parciales , nuevamente inspiradas en .NET. Estas permiten que el código XAML de WinRT de instancia se traduzca a código C++ mediante herramientas y luego se combine con código escrito por humanos para producir la clase completa, al tiempo que se permite una separación clara de las partes generadas por la máquina y editadas por humanos de una implementación de clase en archivos diferentes.
El .NET Framework y el Common Language Runtime (CLR) están integrados en WinRT como una subplataforma. Ha influido y establecido los estándares para el ecosistema a través del formato de metadatos y las bibliotecas. El CLR proporciona servicios como código de compilación JIT y recolección de basura . Las aplicaciones WinRT que utilizan lenguajes .NET utilizan WinUI basado en XAML y están escritas principalmente en C#, VB.NET y, por primera vez para XAML, con código nativo que utiliza C++/CX. Aunque todavía no se admite oficialmente, los programas también se pueden escribir en otros lenguajes .NET. Con .NET 5, Microsoft eliminó el soporte integrado de WinRT y en su lugar creó CsWinRT, una herramienta que genera código de interoperabilidad para acceder a las API de Windows Runtime de manera similar a cómo funciona C++/WinRT. [27] [28]
Las clases definidas en componentes WinRT que se crean en lenguajes .NET administrados deben declararse como sealed, por lo que no se pueden derivar de ellas. Sin embargo, las clases WinRT no selladas definidas en otro lugar se pueden heredar de .NET, sus métodos virtuales se pueden anular, etc.; pero la clase administrada heredada aún debe estar sellada.
Los miembros que interactúan con otro lenguaje deben tener una firma con tipos WinRT o un tipo administrado que sea convertible a estos. [23]
Las aplicaciones WinRT también se pueden codificar usando HTML con JavaScript en código subyacente , que se ejecutan utilizando el motor de renderizado Trident y el motor de JavaScript Chakra , ambos utilizados también por Internet Explorer . Al codificar una aplicación WinRT en JavaScript, sus características se adaptan para seguir las convenciones de nombres de JavaScript y los espacios de nombres también se asignan a objetos de JavaScript.
Microsoft está en proceso de proyectar las API de WinRT a lenguajes distintos de C++. Un ejemplo es Rust/WinRT, una interfaz para que los programas escritos en Rust consuman y creen API de WinRT. [29] Rust/WinRT es parte de Windows App SDK (anteriormente Project Reunion), un esfuerzo de Microsoft para reconciliar el escritorio tradicional de Windows y el modelo de aplicación UWP. [30]
Con la introducción de la Plataforma universal de Windows (UWP), la plataforma ha recibido muchos puentes API que permiten que los programas desarrollados originalmente para otras plataformas se puedan portar fácilmente mientras se aprovechan las características de UWP. Microsoft ha proporcionado puentes para Android (desaparecido desde 2016), iOS ( Cocoa Touch ), Progressive Web Apps , Silverlight , así como las aplicaciones de escritorio tradicionales de Windows (que utilizan el empaquetado MSIX del Windows App SDK ).
WinRT incluye una interfaz de programación de aplicaciones (API) en forma de biblioteca de clases que expone las características de Windows 8 para el desarrollador, como su API de interfaz inmersiva. Es accesible y consumible desde cualquier lenguaje compatible.
Las clases de Windows Runtime son un conjunto de SDK que brindan acceso a todas las funciones, desde el analizador XAML hasta la función de cámara. Los SDK se implementan como bibliotecas nativas de C/C++ (no administradas).
Las convenciones de nombres para los componentes (clases y otros miembros) en la API están fuertemente influenciadas por las convenciones de nombres de .NET que utilizan CamelCase (específicamente PascalCase). Microsoft recomienda a los usuarios que sigan estas reglas en caso de que no se indiquen otras.
Estas convenciones se proyectan de forma diferente en algunos lenguajes, como JavaScript, que las convierte a sus convenciones y viceversa. Esto es para brindar una experiencia nativa y consistente independientemente del lenguaje de programación.
Dado que Windows Runtime está diseñado para varios lenguajes, existen algunas restricciones sobre los tipos de datos fundamentales para poder alojar todos esos lenguajes. Los programadores deben tener cuidado con el comportamiento de esos tipos cuando se utilizan con acceso público (para parámetros de métodos, valores de retorno de métodos, propiedades, etc.). [31]
Numbersolo puede representar hasta 53 bits de precisión.null. Esto se debe a que la palabra clave de JavaScript nullse representa como un objeto null. Se producen resultados similares cuando se pasa undefineda WinRT desde JavaScript.+=el operador.addEventListenerla función o on<EventName>propiedad de configuración se utiliza para suscribirse a eventos.<Verb>[<Noun>]Async. Para la biblioteca de tiempo de ejecución completa, todos los métodos que tienen una probabilidad de durar más de 50 ms se implementan solo como métodos asincrónicos.Windows Phone 8.1 utiliza una versión de Windows Runtime denominada Windows Phone Runtime . Permite desarrollar aplicaciones en C# y VB.NET, y componentes de Windows Runtime en C++/CX. [32] Aunque WP8 trajo soporte limitado, la plataforma finalmente convergió con Windows 8.1 en Windows Phone 8.1 .
Windows Phone 8 tiene un soporte limitado para desarrollar y consumir componentes de Windows Runtime a través de Windows Phone Runtime . Muchas de las API de Windows Runtime en Windows 8 que manejan funciones básicas del sistema operativo han sido trasladadas a Windows Phone 8. [33] Se ha agregado soporte para desarrollar juegos nativos usando C++/CX y DirectX, a pedido de la industria de desarrollo de juegos.
Sin embargo, el marco XAML de Windows Phone todavía se basa en el mismo marco Microsoft Silverlight que en Windows Phone 7, por compatibilidad con versiones anteriores. Por lo tanto, a partir de 2016 [actualizar], el desarrollo XAML es imposible en C++/CX. El desarrollo con HTML5 o WinJS no es compatible con Windows Phone 8.
La compatibilidad de Windows Runtime en Windows Phone 8.1 converge con Windows 8.1. La versión incorpora una API completa de Windows Runtime a la plataforma, que incluye compatibilidad con WinRT XAML y enlaces de lenguaje para C++/CX y HTML5 - JavaScript . También hay un tipo de proyecto llamado Aplicaciones universales para permitir que las aplicaciones compartan código entre las versiones 8.1 de Windows Phone y Windows.
Se ha actualizado el marco Silverlight de Windows Phone 8. [¿ cuándo? ] Puede aprovechar algunas de las nuevas características de Windows Runtime.
Windows Phone Runtime utiliza el formato de paquete AppX de Windows 8, después de utilizar anteriormente Silverlight XAP .
Para habilitar la instalación local en un equipo con Windows 8 Enterprise que no esté unido a un dominio o en cualquier equipo con Windows® 8 Pro, debe usar una clave de activación de producto de instalación local. Para habilitar la instalación local en un dispositivo con Windows® RT, debe usar una clave de activación de producto de instalación local. Para obtener más información sobre la instalación local de claves de activación de producto, consulte Licencias por volumen de Microsoft.