En palabras sencillas, Windows Runtime Library (WinRT) es la interfaz de programación de aplicaciones (API) por defecto que utiliza Windows 8. No sustituye a la API Win32 que ha estado funcionando debajo de todas las aplicaciones de Windows, sino que la aumenta. Es una API nativa no administrada que puede ser aprovechada desde muchos lenguajes diferentes a través de un mecanismo llamado proyección de lenguaje (puedes leer más sobre las proyecciones más adelante en mi respuesta).
Características de Windows Runtime:
- Todas las partes de la API están diseñadas para ser asíncronas.
- La API es sandboxed y está diseñada para la fácil creación de aplicaciones autónomas o listas para la tienda de aplicaciones.
- It exposes the WPF/Silverlight XAML UI model to developers.
- The API definitions are in a metadata format, which is the same as the one used for .NET (ECMA 335).
- It wraps both the Win32 API and the new UI system together.
- It has a simple programming model for creating UIs. It is especially tailored for Windows developers who do not need to learn the Win32 API or terms like LPARAM or WndProc.
- The Silverlight/WPF XAML UI model is exposed to developers.
- It implements the look of Windows (formerly known as Metro)
WinRT consists of 109 new namespaces. These namespaces share the Windows. prefix. They seem to be logically grouped under the following 14 categories:
- ApplicationModel
- Data
- Devices
- Foundation
- Globalization
- Graphics
- Management
- Media
- Networking
- Security
- Storage
- System
- UI
- Web
More about WinRT:
Proyecciones de WinRT
Lo que nosotros llamamos "bindings" Microsoft lo llama ahora "proyecciones". Las proyecciones son el proceso de exponer las APIs a tres entornos: Nativo (C y C++), HTML/Javascript y .NET.
Si creas un componente en C++ o en un lenguaje .NET, su API se almacenará en un archivo WinMD y podrás consumirlo desde los tres entornos (Nativo, JavaScript y .NET). Incluso en C++ no está expuesto a COM. El uso de COM se esconde detrás de las herramientas de proyección de C++. Se utiliza lo que parece y se siente como una API orientada a objetos de C++.
Para soportar las diversas construcciones de WinRT, la plataforma subyacente define un conjunto básico de tipos y sus mapeos a varios entornos. En particular, los objetos de colección en WinRT se mapean a construcciones que son nativas de cada entorno.
Asynchronous APIs
Microsoft considera que cuando a un desarrollador se le da la posibilidad de elegir entre una API sincrónica y una asincrónica, los desarrolladores elegirán la simplicidad de una API sincrónica. El resultado suele funcionar bien en el sistema del desarrollador, pero es terrible cuando se utiliza en la naturaleza.
Con WinRT, Microsoft ha seguido una regla sencilla: si se espera que una API tarde más de 50 milisegundos en ejecutarse, la API es asíncrona.
La idea, por supuesto, es garantizar que cada aplicación de Metro esté diseñada para responder siempre a la entrada del usuario y que no se cuelgue, se bloquee o proporcione una mala experiencia de usuario.
La programación asíncrona ha sido históricamente un proceso engorroso, ya que las devoluciones de llamada y el estado deben estar en cascada en docenas de lugares y la gestión de errores (normalmente una mala gestión de errores) está salpicada en múltiples capas de código.
Para simplificar este proceso, C# y VB se han extendido para soportar el patrón await/async inspirado en F#, convirtiendo la programación asíncrona en una alegría. C++ consiguió una configuración que es tan buena como se puede conseguir con las lambdas de C++ y Javascript utiliza promesas y "then ()".
¿Es .NET o no?
Algunos desarrolladores están confundidos en cuanto a si .NET está ahí o no en primer lugar, ya que no todas las APIs de .NET están presentes (File I/O, Sockets), muchas fueron movidas y otras fueron introducidas para integrarse con WinRT.
Cuando usas C# y VB, estás usando el framework completo de .NET. Pero han optado por exponer un subconjunto más pequeño de la API a los desarrolladores para impulsar la nueva visión de Windows 8.
Y esta nueva visión incluye sistemas de seguridad/sandbox y programación asíncrona. Por eso no tienes acceso directo al sistema de archivos ni acceso a los sockets y por eso las APIs síncronas que estabas acostumbrado a consumir no están expuestas.
Ahora, te das cuenta de que he dicho "expuestas" y no "desaparecidas".
Lo que han hecho es que sólo han expuesto al compilador un conjunto de APIs cuando apuntas al perfil Metro. Así tu aplicación no llamará accidentalmente a File.Create por ejemplo. Sin embargo, en tiempo de ejecución, el CLR cargará la biblioteca de clases completa, la misma que contiene File.Create, por lo que internamente, el CLR podría llamar a algo como File.Create, sólo que tú no tendrás acceso a ello.
Esta división es similar a lo que se ha hecho en el pasado con Silverlight, donde no se exponían todas las APIs, y donde a mscorlib se le daban derechos que tu aplicación no tenía para garantizar la seguridad del sistema.
Podrías estar pensando que puedes usar algún truco (referenciar la librería GAC en lugar de la referencia del compilador o usar reflection para llegar a las APIs privadas, o P/Invoking into Win32). Pero todos esos usos serán capturados por la aplicación de revisión de la AppStore y no podrás publicar tu aplicación a través de la tienda de Microsoft.
Todavía puedes hacer cualquier feo hack que te plazca en tu sistema. Simplemente no será posible publicar eso a través de la AppStore.
Por último, el equipo de .NET ha aprovechado esta oportunidad para hacer algo de limpieza de primavera. mscorlib.dll y System.dll se han dividido en varias bibliotecas y han movido algunos tipos alrededor.
Fuentes: WinRT demystified, What is WinRT?, DevExpress Data Blog, Page on Metrocompanionapps.com.