Wie vergleicht sich Windows 8 Runtime (WinRT / Windows Store-Apps / Windows 10 Universal App) mit Silverlight und WPF? [geschlossen]

Ich versuche, mich mit der neuen Windows 8-Laufzeit vertraut zu machen, mit der Apps im Metro- Stil erstellt werden. Ich weiß, dass Sie es mit XAML verwenden können und es auf .NET basiert, sodass C # und VB.NET zum Schreiben der Apps verwendet werden können, aber dann scheint es etwas mit HTML, CSS, DOM und JavaScript zu tun zu haben.

Kann jemand in ein paar Absätzen erklären, was ein .NET UI-Programmierer verstehen kann? (Mir fehlt ein „Schlüssel“, der notwendig ist, um ihn zu verstehen.)

Wir alle wissen, dass WPF, Silverlight , Windows Forms usw. unter Windows 8 (und Windows 10) zumindest auf Intel-Systemen weiterhin funktionieren. Sagen Sie mir also bitte nicht, dass ...

Auf der untersten Ebene ist WinRT ein Objektmodell, das auf ABI-Ebene definiert ist. Es verwendet COM als Basis (also implementiert IUnknownund führt jedes WinRT-Objekt eine Nachzählung durch) und erstellt von dort aus. Im Vergleich zu alten COM-Konzepten, von denen die meisten direkt aus .NET stammen, werden viele neue Konzepte hinzugefügt. Das WinRT-Objektmodell verfügt beispielsweise über Delegaten, und Ereignisse werden im .NET-Stil ausgeführt (mit Delegaten und Abonnenten hinzufügen / entfernen) Methoden, eine pro Ereignis) anstelle des alten COM-Modells für Ereignisquellen und -senken. Von anderen bemerkenswerten Dingen hat WinRT auch parametrisierte ("generische") Schnittstellen.

Eine weitere große Änderung besteht darin, dass für alle WinRT-Komponenten Metadaten verfügbar sind, genau wie für .NET-Assemblys. In COM hatten Sie das irgendwie mit Typelibs, aber nicht jede COM-Komponente hatte sie. Für WinRT sind die Metadaten in .winmd-Dateien enthalten. Sehen Sie in der Entwicklervorschau unter "C: \ Programme (x86) \ Windows Kits \ 8.0 \ Windows-Metadaten \" nach. Wenn Sie herumstöbern, werden Sie feststellen, dass es sich tatsächlich um CLI-Assemblys ohne Code handelt, sondern nur um Metadatentabellen. Sie können sie tatsächlich mit ILDASM öffnen. Beachten Sie, dass dies nicht bedeutet, dass WinRT selbst verwaltet wird - es verwendet einfach das Dateiformat.

Dann gibt es eine Reihe von Bibliotheken, die in Bezug auf dieses Objektmodell implementiert sind und WinRT-Schnittstellen und -Klassen definieren. Sehen Sie sich erneut den oben genannten Ordner "Windows-Metadaten" an, um zu sehen, was sich dort befindet. oder starten Sie einfach den Objektbrowser in VS und wählen Sie "Windows 8.0" in der Framework-Auswahl, um zu sehen, was behandelt wird. Es gibt viel, und es geht nicht nur um die Benutzeroberfläche - Sie erhalten auch Namespaces wie Windows.Data.Json, oder Windows.Graphics.Printing, oder Windows.Networking.Sockets.

Dann erhalten Sie mehrere Bibliotheken, die sich speziell mit der Benutzeroberfläche befassen - meistens handelt es sich dabei um verschiedene Namespaces unter Windows.UIoder Windows.UI.Xaml. Viele von ihnen sind den WPF / Silverlight-Namespaces sehr ähnlich - z. B. stimmen sie Windows.UI.Xaml.Controlseng überein System.Windows.Controls; das Gleiche gilt für Windows.UI.Xaml.Documentsetc.

Jetzt kann .NET WinRT-Komponenten direkt referenzieren, als wären sie .NET-Assemblys. Dies funktioniert anders als bei COM Interop - Sie benötigen keine Zwischenartefakte wie Interop-Assemblys, sondern nur /reine .winmd-Datei, und alle Typen und ihre Mitglieder in ihren Metadaten werden für Sie sichtbar, als wären sie .NET-Objekte. Beachten Sie, dass die WinRT-Bibliotheken selbst vollständig nativ sind (und daher native C ++ - Programme, die WinRT verwenden, überhaupt keine CLR benötigen) - die Magie, all das verwaltete Material verfügbar zu machen, befindet sich in der CLR selbst und ist ziemlich niedrig. Wenn Sie ein .NET-Programm verwenden, das auf eine .winmd-Datei verweist, werden Sie feststellen, dass es tatsächlich wie eine externe Assembly-Referenz aussieht - es gibt keine handlichen Tricks wie das Einbetten von Typen.

Es ist auch keine stumpfe Zuordnung - CLR versucht, WinRT-Typen nach Möglichkeit an ihre Entsprechungen anzupassen. So zB GUIDs, Termine und URIs werden System.Guid, System.DateTimeund System.Urisind; WinRT-Erfassungsschnittstellen wie IIterable<T>und IVector<T>werden IEnumerable<T>und IList<T>; und so weiter. Dies geht in beide Richtungen: Wenn Sie ein implementiertes .NET-Objekt IEnumerable<T>haben und es an WinRT zurückgeben, wird es als angezeigt IIterable<T>.

Dies bedeutet letztendlich, dass Ihre .NET Metro-Apps Zugriff auf eine Teilmenge der vorhandenen Standard-.NET-Bibliotheken sowie auf (native) WinRT-Bibliotheken erhalten, von denen einige - insbesondere Windows.UI- Silverlight in Bezug auf die API sehr ähnlich sehen. Sie haben immer noch XAML, um Ihre Benutzeroberfläche zu definieren, und Sie beschäftigen sich immer noch mit denselben Grundkonzepten wie in Silverlight - Datenbindungen, Ressourcen, Stile, Vorlagen usw. In vielen Fällen ist es möglich, eine Silverlight-App einfach über usingdie neuen Namespaces zu portieren. und Optimieren einiger Stellen im Code, an denen die API angepasst wurde.

WinRT selbst hat nichts mit HTML und CSS zu tun und hat nur in dem Sinne eine Beziehung zu JavaScript, dass es auch dort verfügbar gemacht wird, ähnlich wie es für .NET gemacht wird. Sie müssen sich nicht mit HTML / CSS / JS befassen, wenn Sie WinRT-UI-Bibliotheken in Ihrer .NET Metro-App verwenden (ich denke, wenn Sie wirklich wollen, können Sie ein WebViewSteuerelement hosten ...). Alle Ihre .NET- und Silverlight-Kenntnisse bleiben in diesem Programmiermodell sehr relevant.

Aus der Build- Keynote:

Sie bieten gemeinsame APIs sowohl für HTML / CSS / JavaScript-Apps als auch für C # / XAML-Apps. C # und XAML werden verwendet, aber es wird nicht genau WPF oder Silverlight sein.

Die Schlüsselidee ist, dass es jetzt zwei Entwicklungspfade gibt - den Desktop und den Metro.

• Auf dem Desktop leben die alten Apps.
• Die neue Klasse von Anwendungen, Metro-Anwendungen, kann auf verschiedene Arten erstellt werden, unter anderem durch VB.NET, C # oder C ++. Diese drei Sprachoptionen können XAML zum Erstellen der Benutzeroberfläche verwenden. Die Alternative besteht darin, JavaScript / HTML5 / CSS für die Entwicklung der Benutzeroberfläche und des Anwendungscodes zu verwenden.

Einige wichtige Punkte:

• Windows 8 fühlt sich wie ein hochskaliertes Betriebssystem für Mobiltelefone an.
• In Metro gibt es keine überlappenden Fenster der obersten Ebene, so wie es keine auf einem Mobiltelefon gibt. Wenn Sie eine Anwendung im MDI-Stil wünschen, müssen Sie auf dem Desktop bleiben.
• Apps im Metro-Stil werden automatisch angehalten, wenn sie nicht sichtbar sind. Dies wurde durchgeführt, um die Batterielebensdauer zu verlängern. Dies bedeutet, dass es nicht sinnvoll ist, viele vorhandene Desktop-Apps, die eine Hintergrundverarbeitung durchführen, auch wenn der Benutzer nicht mit ihnen interagiert, auf Metro zu portieren.
• Die ARM-Version von Windows 8 unterstützt keine Desktopanwendungen. Wenn Sie also eine App schreiben möchten und möchten, dass sie unter einer beliebigen Windows-Version funktioniert, muss es sich um eine Metro-App handeln.

Es gibt eine modifizierte Version der Architektur, die Ihnen sicherlich hilft zu verstehen, wo genau die Dinge liegen. Einer der Telerik-Ninjas unterhielt sich mit dem CLR- Team und änderte das Bild:

Hier können Sie sehen, wo die CLR steht. Das .NET Framework verfügt jetzt über zwei Profile

1- .NET Metro-Profil (CLR, die sich mit Metro-Anwendungen befasst)

2- .NET-Client-Profil (CLR-Laufzeit für C # - und VB.NET-Anwendungen)

Ich hoffe, das gibt Ihnen ein klareres Bild. Lesen Sie den vollständigen Artikel in Ein schlechtes Bild ist tausend lange Diskussionen wert. .

Viele Details von Microsoft hier .

Die Windows-Laufzeit wird mithilfe von API-Metadaten (.winmd-Dateien) verfügbar gemacht. Dies ist das gleiche Format, das vom .NET Framework (Ecma-335) verwendet wird. Der zugrunde liegende Binärvertrag erleichtert Ihnen den Zugriff auf die Windows Runtime-APIs direkt in der Entwicklungssprache Ihrer Wahl. Die Form und Struktur der Windows Runtime-APIs kann sowohl von statischen Sprachen wie C # als auch von dynamischen Sprachen wie JavaScript verstanden werden. IntelliSense ist in JavaScript, C #, Visual Basic und C ++ verfügbar.

Kurz gesagt, Windows Runtime ist eine neue Reihe von Bibliotheken, die Windows-Funktionen verfügbar machen und für JavaScript / C # / VB / C ++ verfügbar sind. Jede Sprache wurde dazu gebracht, sie zu verstehen und direkt anrufen zu können, anstatt eine dicke Schicht durchlaufen zu müssen.

Silverlight und WPF sind XAML-Varianten, die auf der CLR ausgeführt werden. Windows Runtime stellt unter anderem eine Version von XAML zur Verfügung, die Silverlight sehr ähnlich ist, dies jedoch auf native Weise und nicht über die CLR. Der Zugriff erfolgt über die CLR, aber auch über C ++.