Comment Windows 8 Runtime (WinRT / applications Windows Store / Windows 10 Universal App) se compare-t-il à Silverlight et WPF? [fermé]

353

J'essaie de me familiariser avec le nouveau Windows 8 Runtime qui est utilisé pour créer des applications de style Metro . Je sais que vous pouvez l'utiliser avec XAML et il est basé sur .NET, donc C # et VB.NET peuvent être utilisés pour écrire les applications, mais il semble que cela ait quelque chose à voir avec HTML, CSS, DOM et JavaScript.

Quelqu'un peut-il expliquer ce que c'est en quelques paragraphes, en termes qu'un programmeur d'interface utilisateur .NET peut comprendre? (Il me manque quelque chose de «clé» qui est nécessaire pour le comprendre.)

Nous savons tous que WPF, Silverlight , Windows Forms , etc. continueront de fonctionner sous Windows 8 (et Windows 10) sur au moins les systèmes Intel, alors ne me le dites pas ...

wpf windows-runtime windows-store-apps windows-10 win-universal-app Ian Ringrose
la source
22
Il n'est pas basé sur .NET, seulement exposé à lui (un peu comme COM interop, mais beaucoup plus transparent ... par exemple pas d'assemblys interop).
Pavel Minaev,
Demandez-vous WinRT comme plate-forme (ABI, modèle d'objet, etc.) - auquel cas il est plus logique de le comparer à COM ou .NET - ou à propos des bibliothèques de classes standard WinRT, y compris celles pour l'interface utilisateur?
Pavel Minaev,
1
Notez que vous devez distinguer la technologie sous-jacente, le modèle d'objet, etc. - similaire à COM par exemple - et les bibliothèques spécifiques implémentées à l'aide de cette technologie. Même dans ce dernier cas, toutes les bibliothèques standard ne sont pas des bibliothèques d'interface utilisateur - si vous regardez dans l'Explorateur d'objets dans VS, vous pouvez voir l'étendue des fonctionnalités Windows.*couvertes par les espaces de noms. Jusqu'à présent, la terminologie est quelque peu confuse, car WinRT fait référence à la fois à la technologie et à l'ensemble des bibliothèques standard. Je ne pense pas qu'il y ait une étiquette concise pour seulement les bibliothèques d'interface utilisateur ( Windows.UI.*).
Pavel Minaev,
@ TrueWill: il est plus logique d'apprendre les trois, afin que vos connaissances soient plus complètes et que vous puissiez décider quelle solution est la meilleure pour un problème donné. Ne vous contentez pas d'apprendre l'un des trois.
Chris Charabaruk
2
@TrueWill: Silverlight n'aura aucune version future: zdnet.com/blog/microsoft/microsoft-releases-silverlight-5/…
Sabuncu

Réponses:

479

Au niveau le plus bas, WinRT est un modèle objet défini au niveau ABI. Il utilise COM comme base (donc chaque objet WinRT implémente IUnknownet effectue le recomptage) et construit à partir de là. Il ajoute beaucoup de nouveaux concepts par rapport à COM des anciens, dont la plupart proviennent directement de .NET - par exemple, le modèle d'objet WinRT a des délégués, et les événements sont effectués de style .NET (avec des délégués et ajout / suppression d'abonné méthodes, une par événement) plutôt que l'ancien modèle COM de sources et récepteurs d'événements. Parmi d'autres choses notables, WinRT a également des interfaces paramétrées ("génériques").

Un autre grand changement est que tous les composants WinRT ont des métadonnées disponibles pour eux, tout comme les assemblys .NET. Dans COM, vous en aviez en quelque sorte avec les listes de types, mais tous les composants COM n'en avaient pas. Pour WinRT, les métadonnées sont contenues dans des fichiers .winmd - regardez à l'intérieur de "C: \ Program Files (x86) \ Windows Kits \ 8.0 \ Windows Metadata \" dans Developer Preview. Si vous fouillez, vous verrez que ce sont en fait des assemblys CLI sans 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 est géré - il réutilise simplement le format de fichier.

Ensuite, il existe un certain nombre de bibliothèques implémentées en termes de ce modèle d'objet - définissant les interfaces et les classes WinRT. Encore une fois, regardez le dossier "Windows Metadata" mentionné ci-dessus pour voir ce qu'il y a; ou lancez simplement l'Explorateur d'objets dans VS et sélectionnez "Windows 8.0" dans le sélecteur de framework, pour voir ce qui est couvert. Il y a beaucoup de choses là-bas, et cela ne concerne pas uniquement l'interface utilisateur - vous obtenez également des espaces de noms tels que Windows.Data.Json, ou Windows.Graphics.Printing, ou Windows.Networking.Sockets.

Ensuite, vous obtenez plusieurs bibliothèques, qui traitent spécifiquement de l'interface utilisateur - la plupart du temps, il s'agirait de divers espaces de noms sous Windows.UIou Windows.UI.Xaml. Beaucoup d'entre eux sont très similaires aux espaces de noms WPF / Silverlight - par exemple, ils Windows.UI.Xaml.Controlscorrespondent étroitement System.Windows.Controls; idem pour Windows.UI.Xaml.Documentsetc.

Désormais, .NET a la possibilité de référencer directement les composants WinRT comme s'il s'agissait d'assemblages .NET. Cela fonctionne différemment de COM Interop - vous n'avez pas besoin d'artefacts intermédiaires tels que des assemblys d'interopérabilité, vous n'avez qu'un /rfichier .winmd, et tous les types et leurs membres dans ses métadonnées deviennent visibles pour vous comme s'il s'agissait d'objets .NET. Notez que les bibliothèques WinRT elles-mêmes sont entièrement natives (et donc les programmes C ++ natifs qui utilisent WinRT ne nécessitent pas du tout CLR) - la magie pour exposer tout ce qui est géré se trouve à l'intérieur du CLR lui-même, et est assez bas. Si vous identifiez un programme .NET qui fait référence à un .winmd, vous verrez qu'il ressemble en fait à une référence d'assembly externe - il n'y a aucun tour de passe-passe tel que l'incorporation de type.

Ce n'est pas non plus un mappage brutal - CLR essaie d'adapter les types WinRT à leurs équivalents, si possible. Ainsi, par exemple, les GUID, les dates et les URI deviennent respectivement System.Guid, System.DateTimeet System.Uri; Interfaces de collecte WinRT telles que IIterable<T>et IVector<T>deviennent IEnumerable<T>et IList<T>; etc. Cela va dans les deux sens - si vous avez un objet .NET qui implémente IEnumerable<T>et le transmettez à WinRT, il le verra comme IIterable<T>.

En fin de compte, cela signifie que vos applications .NET Metro ont accès à un sous-ensemble des bibliothèques .NET standard existantes, ainsi qu'à des bibliothèques WinRT (natives), dont certaines - en particulier Windows.UI- ressemblent beaucoup à Silverlight, au niveau de l'API. Vous avez toujours XAML pour définir votre interface utilisateur, et vous traitez toujours les mêmes concepts de base que dans Silverlight - liaisons de données, ressources, styles, modèles, etc. Dans de nombreux cas, il est possible de porter une application Silverlight simplement par usingles nouveaux espaces de noms, et peaufiner quelques endroits dans le code où l'API a été ajustée.

WinRT lui-même n'a rien à voir avec HTML et CSS, et il n'a de relation avec JavaScript que dans le sens où il y est également exposé, de la même manière que cela est fait pour .NET. Vous n'avez pas besoin de gérer HTML / CSS / JS lorsque vous utilisez les bibliothèques d'interface utilisateur WinRT dans votre application .NET Metro (enfin, je suppose que si vous le voulez vraiment, vous pouvez héberger un WebViewcontrôle ...). Toutes vos compétences .NET et Silverlight restent très pertinentes dans ce modèle de programmation.

Pavel Minaev
la source
Qu'en est-il de la compatibilité WPF-WinRT? Y aura-t-il des incohérences de type WPF-Silverlight?
Den
5
@Den WPF n'est pas un bon point de comparaison ici - l'API est beaucoup, beaucoup plus proche de Silverlight. Si vous le regardez de cette façon, il y a des incohérences entre les deux, mais l'échelle est plus proche du bureau vs WP7 Silverlight, pas Silverlight vs WPF.
Pavel Minaev,
11
Très bonne réponse. Est-ce que WinRT accède directement au noyau NT (quand il a besoin du support du système d'exploitation) ou passe-t-il par Win32?
Timores
4
Légère correction / addition: un composant WinRT implémente l'interface IInspectable, qui dérive de IUnknown ...
Martin Ba
66

Extrait du discours d'ouverture de Build :

Pile de notes d'identification

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.

RandomEngy
la source
8
C'est un peu plus compliqué, car le nouveau truc XAML est disponible pour C # et C ++ (natif). Ce n'est ni WPF ni Silverlight, mais très proche de ce dernier - comme démontré dans le discours, vous pouvez souvent vous en sortir en changeant simplement un tas d'utilisations et d'autres refactorisations triviales dans le code Silverlight existant. Les idées fondamentales derrière WPF / Silverlight - balisage déclaratif, ressources, styles, modèles, liaisons de données, etc. - sont toutes là. La plupart des contrôles sont également présents.
Pavel Minaev,
2
Il y a un meilleur graphique que j'ai vu ce matin, mais je ne le trouve plus. EDIT: Trouvé, grâce à une autre réponse à cette question. dougseven.files.wordpress.com/2011/09/win8-new-platform.png
Chris Charabaruk
1
Où WPF tient-il sur la diapositive?
paparazzo
1
Il est regroupé avec la méthode .NET / Silverlight en bas à droite.
BoltClock
1
Cette image est grossièrement incorrecte, en ce qui concerne les pièces existantes. Vous pouvez presque le corriger en remplaçant "Windows Kernel Services" par "Win32 kernel32.dll" et "Win32" par "Win32 user32.dll + gdi32.dll" ... mais IE et .NET / Silverlight devraient être superposés principalement sur le dessus de user32.dll + gdi32.dll, et ceux ainsi que C / C ++ / Java / Delphi / etc atteignent également kernel32.dll. Ce qui est important, c'est que user32.dll et gdi32.dll ne sous-tendent PAS WinRT, et que les applications du Windows Store ne peuvent pas atteindre WinRT directement à la pleine puissance de kernel32.dll.
Ben Voigt
37

L'idée clé est qu'il existe désormais deux pistes de développement: le bureau et le métro.

  • Le bureau est l'endroit où vivent les anciennes applications.
  • La nouvelle classe d'applications, les applications Metro, peut être construite de différentes manières, notamment par VB.NET, C # ou C ++. Ces trois options de langue peuvent utiliser XAML pour créer l'interface utilisateur. L'alternative consiste à utiliser JavaScript / HTML5 / CSS pour le développement de l'interface utilisateur et du code d'application.

Quelques points importants:

  • Windows 8 ressemble à un système d'exploitation de téléphone mobile mis à l'échelle.
  • Dans Metro, il n'y a pas de fenêtres de niveau supérieur qui se chevauchent, tout comme il n'y en a pas sur un téléphone mobile. Si vous voulez une application de style MDI, vous devez rester sur le bureau.
  • Les applications de style Metro sont automatiquement suspendues lorsqu'elles ne sont pas visibles. Cela a été fait pour prolonger la durée de vie de la batterie. Cela signifie que cela n'aura aucun sens pour de nombreuses applications de bureau existantes, qui effectuent un traitement en arrière-plan même lorsque l'utilisateur n'interagit pas avec elles, pour être portées sur Metro.
  • La version ARM de Windows 8 ne prend pas en charge les applications de bureau. Donc, si vous souhaitez écrire une application et que vous souhaitez qu'elle fonctionne sur n'importe quelle version de Windows, il doit s'agir d'une application Metro.
dodgy_coder
la source
2
Dans Metro, il n'y a pas de fenêtres de niveau supérieur qui se chevauchent . Il y en a encore Popup( msdn.microsoft.com/en-us/library/windows/apps/… ), donc si vous le souhaitez, vous pouvez préparer quelque chose de similaire à MDI. Évidemment, il n'est pas recommandé d'en abuser, car vous risquez de vous retrouver avec une interface utilisateur non tactile.
Pavel Minaev,
@ Pavel - c'est intéressant - cela signifie-t-il que vous pouvez avoir quelques fenêtres de niveau supérieur fonctionnant côte à côte, mais sans se chevaucher? par exemple carrelé ... partageant la moitié de l'écran chacun par exemple? L'application WPF sur laquelle je travaille a maintenant besoin de ce type de fonctionnalité.
dodgy_coder
3
Chaque application Metro n'a qu'une seule fenêtre de niveau supérieur. Vous pouvez avoir deux applications Metro fonctionnant côte à côte, mais c'est quelque chose que l'utilisateur décide - il n'y a aucun moyen pour l'application de s'imposer dans cette configuration. De plus, même si vous avez deux applications qui s'exécutent côte à côte, elles ne peuvent pas communiquer pour se coordonner (sauf par le biais de gestes explicites de l'utilisateur tels que «Partager vers»).
Pavel Minaev
1
D'un autre côté, vous pouvez, bien sûr, subdiviser votre propre fenêtre de niveau supérieur en autant de zones que vous le souhaitez, et fournir un séparateur mobile pour les redimensionner - qui, du point de vue de l'utilisateur, ressemblerait à deux fenêtres de niveau supérieur carrelées . Cependant, ils apparaîtront toujours comme une seule chose dans le sélecteur d'application (mais vous le voudriez probablement?).
Pavel Minaev,
3
Selon Martyn Lovell, il n'y a pas de mécanisme délibéré pour cela, et certains qui pourraient être utilisés pour cela sont intentionnellement limités. Les canaux nommés ne sont pas là, par exemple, ni les fichiers mappés en mémoire. Il existe des sockets (y compris des sockets serveur), mais lors de la connexion à localhost, vous ne pouvez vous connecter qu'à la même application. Vous pouvez utiliser des fichiers normaux dans l'un des "dossiers connus" partagés (documents, images, etc.), mais c'est un hack assez grossier qui nécessite une interrogation et est visible pour l'utilisateur.
Pavel Minaev,
24

Il existe une version modifiée de l'architecture qui vous aidera sûrement à comprendre où se trouvent exactement les choses. L'un des ninjas Telerik a discuté avec l' équipe du CLR et a modifié l'image:

Plateforme et outils Windows 8 (y compris le CLR)

Ici, vous pouvez voir où se trouve le CLR. Le framework .NET a maintenant deux profils

1- Profil Metro .NET (CLR qui traite de l'application Metro)

2- Profil client .NET (runtime CLR pour les applications C # et VB.NET)

J'espère que cela vous donne une image plus claire. Lisez l'article complet dans Une mauvaise image vaut mille longues discussions. .

vendettamit
la source
17

Beaucoup de détails de Microsoft ici .

Windows Runtime est exposé à l'aide de métadonnées API (fichiers .winmd). Il s'agit du même format utilisé par le framework .NET (Ecma-335). Le contrat binaire sous-jacent vous permet d'accéder facilement aux API Windows Runtime directement dans le langage de développement de votre choix. La forme et la structure des API Windows Runtime peuvent être comprises par les langages statiques tels que C # et les langages dynamiques tels que JavaScript. IntelliSense est disponible en JavaScript, C #, Visual Basic et C ++.

En bref, Windows Runtime est un nouvel ensemble de bibliothèques exposant les fonctionnalités de Windows et disponible pour JavaScript / C # / VB / C ++. Chaque langue a été conçue pour les comprendre et pouvoir les appeler directement plutôt que d'avoir à passer par une couche de thunking.

Silverlight et WPF sont des versions de XAML qui s'exécutent sur le CLR. Entre autres fonctionnalités, Windows Runtime expose une version de XAML très similaire à Silverlight, mais le fait de manière native, pas via le CLR. Il est accessible depuis le CLR, mais aussi depuis C ++.

Steve Rowe
la source
2
La "couche thunking" peut être présente - par exemple, CLR utilise réellement des RCW - mais c'est maintenant un détail d'implémentation. Du point de vue des développeurs, vous référencez directement les fichiers WinRT .winmd et travaillez directement avec les types à l'intérieur.
Pavel Minaev,
3
Alors que la couche thunking utilise des RCW, les RCW pour l'exécution de Windows sont plus légers que les anciens RCW P / Invoke.
ReinstateMonica Larry Osterman,