¿Cómo se compara Windows 8 Runtime (aplicaciones WinRT / Windows Store / Windows 10 Universal App) con Silverlight y WPF? [cerrado]

Estoy tratando de entender el nuevo Windows 8 Runtime que se usa para crear aplicaciones de estilo Metro . Sé que puede usarlo con XAML y está basado en .NET, por lo que C # y VB.NET pueden usarse para escribir las aplicaciones, pero parece tener algo que ver con HTML, CSS, DOM y JavaScript.

¿Alguien puede explicar qué es en unos pocos párrafos, en términos que un programador de .NET UI pueda entender? (Me falta algo "clave" que es necesario para entenderlo).

Todos sabemos que WPF, Silverlight , Windows Forms , etc. seguirán funcionando bajo Windows 8 (y Windows 10) al menos en los sistemas Intel, así que no me digas eso ...

En el nivel más bajo, WinRT es un modelo de objetos definido en el nivel ABI. Utiliza COM como base (por lo que cada objeto WinRT implementa IUnknowny realiza el recuento), y construye desde allí. Agrega muchos conceptos nuevos en comparación con los COM de antaño, la mayoría de los cuales provienen directamente de .NET; por ejemplo, el modelo de objetos WinRT tiene delegados y los eventos se realizan al estilo .NET (con delegados y agregar / eliminar suscriptores) métodos, uno por evento) en lugar del antiguo modelo COM de fuentes y sumideros de eventos. De otras cosas notables, WinRT también tiene interfaces parametrizadas ("genéricas").

Otro gran cambio es que todos los componentes WinRT tienen metadatos disponibles para ellos, al igual que los ensamblados .NET. En COM, tenías eso con typelibs, pero no todos los componentes COM los tenían. Para WinRT, los metadatos están contenidos en archivos .winmd. Busque dentro de "C: \ Archivos de programa (x86) \ Windows Kits \ 8.0 \ Windows Metadata \" en Developer Preview. Si hurga, verá que en realidad son ensamblados de CLI sin código, solo tablas de metadatos. Puede abrirlos con ILDASM, de hecho. Tenga en cuenta que esto no significa que WinRT esté administrado, simplemente reutiliza el formato de archivo.

Luego, hay una serie de bibliotecas implementadas en términos de ese modelo de objetos, que definen las interfaces y clases de WinRT. Nuevamente, mire la carpeta "Metadatos de Windows" mencionada anteriormente para ver qué hay allí; o simplemente inicie Object Browser en VS y seleccione "Windows 8.0" en el selector de marco, para ver qué está cubierto. Hay mucho allí, y no se ocupa solo de la interfaz de usuario: también obtienes espacios de nombres como Windows.Data.Json, o Windows.Graphics.Printing, o Windows.Networking.Sockets.

Luego obtienes varias bibliotecas, que se ocupan específicamente de la interfaz de usuario; en su mayoría, estos serían varios espacios de nombres bajo Windows.UIo Windows.UI.Xaml. Muchos de ellos son muy similares a los espacios de nombres de WPF / Silverlight, por ejemplo, Windows.UI.Xaml.Controlscoinciden estrechamente System.Windows.Controls; lo mismo para Windows.UI.Xaml.Documentsetc.

Ahora, .NET tiene la capacidad de hacer referencia directa a los componentes WinRT como si fueran ensamblados .NET. Esto funciona de manera diferente a Interoperabilidad COM: no necesita ningún artefacto intermedio como ensamblajes de interoperabilidad, solo /run archivo .winmd y todos los tipos y sus miembros en sus metadatos se vuelven visibles para usted como si fueran objetos .NET. Tenga en cuenta que las bibliotecas WinRT en sí son completamente nativas (por lo que los programas nativos de C ++ que usan WinRT no requieren CLR en absoluto): la magia para exponer todas esas cosas como se administran está dentro del CLR en sí, y es de nivel bastante bajo. Si ildasm un programa .NET que hace referencia a un .winmd, verás que en realidad se ve como una referencia de ensamblaje externo: no hay un juego de trucos de mano como la incrustación de tipos allí.

Tampoco es un mapeo contundente: CLR intenta adaptar los tipos de WinRT a sus equivalentes, siempre que sea posible. Entonces, por ejemplo, se convierten en GUID, fechas y URI System.Guid, System.DateTimey System.Uri, respectivamente; Interfaces de colección WinRT tales como IIterable<T>y IVector<T>Become IEnumerable<T>y IList<T>; y así. Esto va en ambos sentidos: si tiene un objeto .NET que se implementa IEnumerable<T>y lo devuelve a WinRT, lo verá como IIterable<T>.

En última instancia, lo que esto significa es que sus aplicaciones .NET Metro obtienen acceso a un subconjunto de las bibliotecas .NET estándar existentes, y también a las bibliotecas WinRT (nativas), algunas de las cuales, particularmente Windows.UI, se parecen mucho a Silverlight, API-wise. Todavía tiene XAML para definir su IU, y aún maneja los mismos conceptos básicos que en Silverlight: enlaces de datos, recursos, estilos, plantillas, etc. En muchos casos, es posible portar una aplicación Silverlight simplemente por usinglos nuevos espacios de nombres, y ajustar algunos lugares en el código donde se ajustó la API.

WinRT en sí no tiene nada que ver con HTML y CSS, y tiene relación con JavaScript solo en el sentido de que también está expuesto allí, de manera similar a como se hace para .NET. No necesita lidiar con HTML / CSS / JS cuando usa las bibliotecas WinRT UI en su aplicación .NET Metro (bueno, supongo que si realmente quiere, puede alojar un WebViewcontrol ...). Todas sus habilidades de .NET y Silverlight siguen siendo muy relevantes en este modelo de programación.

De la nota clave de Build :

Proporcionan API comunes tanto para aplicaciones HTML / CSS / JavaScript como para aplicaciones C # / XAML. Se usarán C # y XAML, pero no será WPF o Silverlight exactamente.

La idea clave es que ahora hay dos pistas de desarrollo: Desktop y Metro.

• El escritorio es donde viven las aplicaciones antiguas.
• La nueva clase de aplicaciones, aplicaciones Metro, se puede construir de varias maneras, incluso mediante VB.NET, C # o C ++. Estas tres opciones de idioma pueden usar XAML para construir la interfaz de usuario. La alternativa es usar JavaScript / HTML5 / CSS para el desarrollo de la interfaz de usuario y el código de la aplicación.

Algunos puntos importantes:

• Windows 8 se siente como un sistema operativo de teléfono móvil mejorado.
• En Metro, no hay ventanas superpuestas de nivel superior, como tampoco las hay en un teléfono móvil. Si desea una aplicación de estilo MDI, debe permanecer en el escritorio.
• Las aplicaciones de estilo Metro se suspenden automáticamente cuando no están visibles. Esto se hizo para prolongar la vida útil de la batería. Esto significa que no tendrá sentido que muchas aplicaciones de escritorio existentes, que realizan el procesamiento en segundo plano, incluso cuando el usuario no está interactuando con ellas, sean transportadas a Metro.
• La versión ARM de Windows 8 no admitirá aplicaciones de escritorio. Entonces, si desea escribir una aplicación y quiere que funcione en cualquier versión de Windows, entonces debe ser una aplicación de Metro.

Hay una versión modificada de la arquitectura que seguramente lo ayudará a comprender dónde se encuentran exactamente las cosas. Uno de los ninjas de Telerik conversó con el equipo de CLR y modificó la imagen:

Aquí puede ver dónde se encuentra el CLR. .NET Framework ahora tiene dos perfiles

1- Perfil de .NET Metro (CLR que se ocupa de la aplicación Metro)

2- Perfil de cliente .NET (tiempo de ejecución CLR para aplicaciones C # y VB.NET)

Espero que esto te dé una imagen más clara. Lea el artículo completo en Una mala imagen vale más que mil largas discusiones. .

Muchos detalles de Microsoft aquí .

Windows Runtime se expone mediante metadatos de API (archivos .winmd). Este es el mismo formato utilizado por el marco .NET (Ecma-335). El contrato binario subyacente facilita el acceso a las API de Windows Runtime directamente en el lenguaje de desarrollo que elija. La forma y la estructura de las API de Windows Runtime se pueden entender tanto con lenguajes estáticos como C # como con lenguajes dinámicos como JavaScript. IntelliSense está disponible en JavaScript, C #, Visual Basic y C ++.

En resumen, Windows Runtime es un nuevo conjunto de bibliotecas que expone la funcionalidad de Windows y está disponible para JavaScript / C # / VB / C ++. Se ha hecho que cada idioma los entienda y pueda llamarlos directamente en lugar de tener que pasar por una capa de thunking.

Silverlight y WPF son sabores de XAML que se ejecutan en el CLR. Entre otras funciones, Windows Runtime expone una versión de XAML muy similar a Silverlight, pero lo hace de forma nativa, no a través del CLR. Se puede acceder desde el CLR, pero también desde C ++.