Comment le nouveau Windows 8 Runtime (applications de magasin WinRT / Windows) se compare-t-il à Silverlight et WPF?

Question

Je suis en train d'essayer d'obtenir ma tête autour du Windows 8 Runtime qui est utilisé pour créer Metro style apps. Je sais que vous pouvez l'utiliser avec XAML et il est basé sur .NET C# et VB.NET peut être utilisé pour écrire les applications, mais elle semble avoir quelque chose à faire avec le HTML, CSS, DOM et JavaScript.

Quelqu'un peut m'expliquer ce que c'est, en quelques paragraphes, en des termes qui un .NET de l'INTERFACE utilisateur programmeur peut comprendre? (Je suis absent quelque chose de "clé" qui est nécessaire pour le comprendre)

---

Nous savons tous que WPF et Silverlight et Winforms, etc continuera de fonctionner sous windows 8 au moins sur système Intel, donc s'il vous plaît ne me dites pas que...

Answer 1

Au niveau le plus bas, WinRT est un modèle d'objet défini sur ABI niveau. Il utilise COM comme base (donc tous les WinRT objet implémente IUnknown et ne compteurs refcount), et construit à partir de là. Il n'ajouter beaucoup de nouveaux concepts en comparaison à la COM de vieux, dont la plupart proviennent directement de .NET - par exemple, WinRT modèle d'objet a délégués, et les événements sont fait .NET-style (avec les délégués et les ajouter/supprimer un abonné méthodes, l'une par événement) plutôt que sur l'ancien modèle COM de cas sources et les puits. D'autres notables choses, WinRT a également paramétrées ("générique") interfaces.

Un autre grand changement est que tous les composants WinRT ont métadonnées disponibles pour eux, tout comme .NET assemblées. COM vous un peu sorta avait qu'avec les bibliothèques de types, mais pas chaque composant COM de les avoir. Pour WinRT, les métadonnées contenues dans .fichiers winmd - regarder à l'intérieur "C:\Program Files (x86)\Windows Kits\8.0\Windows Métadonnées\" Developer Preview. Si vous regardez attentivement, vous verrez qu'elles sont réellement CLI assemblées avec pas de code, juste des tables de métadonnées. Vous pouvez les ouvrir avec ILDASM, en fait. Remarque, cela ne signifie pas que WinRT lui-même géré - il réutilise le format de fichier.

Ensuite, il ya un certain nombre de bibliothèques mises en œuvre en termes de modèle d'objet - définition de WinRT d'interfaces et de classes. Encore une fois, regardez Windows "Métadonnées" dans le dossier mentionné ci-dessus pour voir ce qui est là; ou tout simplement le feu au Navigateur d'Objet dans VS et sélectionnez "Windows 8.0" dans le cadre du sélecteur, pour voir ce qui est couvert. Il y en a beaucoup, et qu'il ne s'occupe pas de l'INTERFACE utilisateur seul, vous obtenez également des espaces de noms tels que Windows.Data.Jsonou Windows.Graphics.Printingou Windows.Networking.Sockets.

Ensuite, vous obtenez plusieurs bibliothèques, qui traite spécifiquement de l'INTERFACE utilisateur - la plupart de ces seraient différents espaces de noms sous Windows.UI ou Windows.UI.Xaml. Beaucoup d'entre eux sont très similaires à WPF/Silverlight espaces de noms - par exemple, Windows.UI.Xaml.Controls est en étroite correspondance System.Windows.Controls; idem pour Windows.UI.Xaml.Documents etc.

Maintenant, .NET a la capacité de faire directement référence à WinRT composants comme si elles étaient .NET assemblées. Cela fonctionne différemment de COM Interop - vous n'avez pas besoin d'aucun intermédiaire d'artefacts tels que des assemblys interop, vous venez /r une .winmd fichier, et tous les types et de leurs membres dans ses métadonnées deviennent visibles à vous comme si elles étaient .NET des objets. Notez que WinRT les bibliothèques elles-mêmes sont entièrement native (et donc la native de programmes C++ qui utilisent WinRT ne nécessitent pas de CLR) - la magie d'exposer toutes ces choses est géré à l'intérieur de la CLR lui-même, et il est assez bas niveau. Si vous ildasm un .NET programme qui fait référence à un .winmd, vous verrez qu'il ressemble en fait à un extern assemblée de référence - il n'y a pas de tour de passe-passe de la part de la tricherie comme le type d'incorporation.

Ce n'est pas un bout de cartographie, soit - CLR tente de s'adapter types WinRT pour leurs équivalents, lorsque cela est possible. Donc, par exemple, Guid, les dates et les Uri deviennent System.Guid, System.DateTime et System.Uri, respectivement; WinRT collection des interfaces telles que IIterable<T> et IVector<T> deviennent IEnumerable<T> et IList<T>; et ainsi de suite. Cela va dans les deux sens - si vous avez un .NET objet qui implémente IEnumerable<T>, et de passer à WinRT, il va voir ce qu' IIterable<T>.

En fin de compte, ce que cela signifie, c'est que votre .NET applications Metro obtenir l'accès à un sous-ensemble de la norme existante .Bibliothèques NET, et aussi (native) WinRT bibliothèques, certains - en particulier Windows.UI - très similaire à Silverlight, API, sage. Vous avez encore XAML pour définir votre INTERFACE utilisateur, et vous avez à traiter avec les mêmes concepts de base comme dans Silverlight - liaisons de données, les ressources, les styles, les modèles, etc. Dans de nombreux cas, il est possible de porter une application Silverlight simplement en using les nouveaux espaces de noms, et de les retravailler un peu d'endroits dans le code de l'API a été ajusté.

WinRT lui-même n'a rien à voir avec le HTML et le CSS, et il faut bien le rapport à JavaScript que dans un sens qu'il est également exposée là, semblable à la façon dont c'est fait pour .NET. Vous n'avez pas besoin de traiter avec le HTML/CSS/JS lorsque vous utilisez WinRT de l'INTERFACE utilisateur des bibliothèques dans votre .NET application de Métro (enfin, je suppose que, si vous le voulez vraiment, vous pouvez héberger un WebView de contrôle...). Toutes vos .NET et Silverlight compétences demeurent très pertinent dans ce modèle de programmation.

Answer 2

De la keynote BUILD: Ils fournissent des API communes aux applications HTML / CSS / Javascript et aux applications C # / XAML. C # et XAML seront utilisés, mais ce ne sera pas exactement WPF ou Silverlight.

Answer 3

L'idée clé est que maintenant il y a deux pistes de développement - le Bureau et le Métro.

• Le bureau est l'endroit où l'ancien applications en ligne.
• La nouvelle classe d'applications, de Métro applications, peut être intégré dans un certain nombre de façons, y compris par VB.NET, C# ou C++. Ces trois options de langue peuvent utiliser XAML pour construire l'INTERFACE utilisateur. L'alternative est d'utiliser JavaScript/HTML5/CSS pour le développement de l'INTERFACE utilisateur et le code d'application.

Quelques points importants:

• Windows 8 se sent un peu comme un rehaussement de téléphone mobile système d'exploitation.
• Dans le Métro, il n'y a pas de chevauchement des fenêtres de niveau supérieur, tout comme il n'en existe pas sur un téléphone mobile. Si vous voulez une application de type MDI, vous avez besoin de rester sur le bureau.
• Metro style apps sont automatiquement suspendu lorsqu'il n'est pas visible. Cela a été fait pour prolonger la vie de la batterie. Cela signifie qu'il ne fera pas de sens pour de nombreuses applications de bureau, qui effectuent le traitement en arrière-plan, même lorsque l'utilisateur n'est pas en interaction avec eux, d'être porté à la Métro.
• Le BRAS de la version de Windows 8 ne sera pas le soutien des applications de bureau. Donc, si vous voulez écrire une application et que vous voulez qu'il fonctionne sur n'importe quelle version de Windows, alors, il doit être une application de Métro.

Answer 4

Il y a une version modifiée de l'architecture qui va sûrement vous aider à comprendre exactement où les choses se trouve. L'un des Telerik ninjas avaient chat avec l'équipe CLR et modification de l'image:

Ici vous pouvez voir où le CLR stands. L' .Net framework a maintenant deux profils

1- .Net Métro profil (CLR qui traitent de l'application Metro)

2- .Net profil du Client (CLR runtime pour C#,VB.Net les applications)

J'espère que cela vous donne une image plus claire. Lire l'article complet ici: http://dougseven.com/2011/09/15/a-bad-picture-is-worth-a-thousand-long-discussions/

Answer 5

Beaucoup de détails à partir de Microsoft ici.

L'Exécution de Windows est exposé à l'aide de l'API de métadonnées (.winmd fichiers). C'est le même format utilisé par le .NET framework (Ecma-335). Le sous-jacent binaire contrat, il est facile pour vous d'accéder à l'Api Windows Runtime directement dans le développement de la langue de votre choix. La forme et la structure de l'Api Windows Runtime peut être comprise par les deux statique des langages tels que C# et dynamique des langages tels que JavaScript. IntelliSense est disponible en JavaScript, C#, Visual Basic et C++.

En bref, Windows Runtime est un nouvel ensemble de bibliothèques d'exposer les fonctionnalités de Windows et disponible pour JavaScript/C#/VB/C++. Chaque langue a été faite pour comprendre et être en mesure de les appeler directement, plutôt que d'avoir à passer par un médiateur de la couche.

Silverlight et WPF sont les saveurs de XAML qui s'exécutent sur le CLR. Parmi les autres fonctionnalités, Windows Runtime expose une version de XAML très similaire à Silverlight, mais le fait de façon native, pas par le CLR. Il peut être consulté à partir de la CLR, mais aussi à partir de C++.