Windows 8ランタイム(WinRT / Windowsストアアプリ/ Windows 10ユニバーサルアプリ)は、SilverlightやWPFと比較してどうですか。[閉まっている]


353

私は、Metroスタイルアプリの作成に使用される新しいWindows 8ランタイムに頭を悩ませています。XAMLで使用でき、.NETに基づいているので、C#とVB.NETを使用してアプリを作成できますが、HTML、CSS、DOM、JavaScriptと何らかの関係があるようです。

誰かがそれが何であるかを.NET UIプログラマーが理解できる言葉で説明できますか?(それを理解するために必要な「キー」が足りない。)


WPF、SilverlightWindows Formsなどが、少なくともIntelシステムのWindows 8(およびWindows 10)で動作し続けることは誰もが知っているので、言わないでください...


22
これは.NETに基づいておらず、公開されているだけです(COM相互運用機能に少し似ていますが、はるかにシームレスです...相互運用機能アセンブリはありません)。
Pavel Minaev 2011

WinRTをプラットフォーム(ABI、オブジェクトモデルなど)として求めていますか?その場合、COMまたは.NETと比較する方が理にかなっていますか?または、UIを含むWinRT標準クラスライブラリについてです。
Pavel Minaev 2011

1
COMなどの基盤となるテクノロジー、オブジェクトモデルなどと、そのテクノロジーを使用して実装された特定のライブラリを区別する必要があることに注意してください。後者の場合でも、すべての標準ライブラリがUIライブラリであるとは限りません。VSのオブジェクトブラウザを見ると、Windows.*名前空間がカバーする幅広い機能を確認できます。WinRTはテクノロジーと標準ライブラリのセット全体の両方を指すため、これまでの用語はここではやや混乱しています。Windows.UI.*ただし、UIライブラリ()だけの簡潔なラベルはないと思います。
Pavel Minaev 2011

@TrueWill:3つすべてを学習する方が理にかなっています。これにより、知識がより包括的になり、特定の問題に最適なソリューションを決定できます。3つのうちの1つを学ぶだけではありません。
Chris Charabaruk、2011

2
@TrueWill:Silverlightは、任意の将来のリリースを持っていません。zdnet.com/blog/microsoft/microsoft-releases-silverlight-5/...
Sabuncu

回答:


479

最低レベルでは、WinRTはABIレベルで定義されたオブジェクトモデルです。COMをベースとして使用するため(すべてのWinRTオブジェクトが実装IUnknownして参照カウントを行います)、そこからビルドします。古いCOMに比べると、かなり多くの新しい概念が追加されています。そのほとんどは.NETから直接来ています。たとえば、WinRTオブジェクトモデルにはデリゲートがあり、イベントは.NETスタイルで行われます(デリゲートとサブスクライバーの追加/削除)イベントソースとシンクの古いCOMモデルではなく、イベントごとに1つのメソッド)。その他の注目すべき点として、WinRTにはパラメーター化された(「汎用」)インターフェースもあります。

もう1つの大きな変更は、.NETアセンブリと同様に、すべてのWinRTコンポーネントがメタデータを利用できることです。COMでは、typelibsでそれが少しありましたが、すべてのCOMコンポーネントがそれらを持っているわけではありません。WinRTの場合、メタデータは.winmdファイルに含まれています-開発者プレビューの「C:\ Program Files(x86)\ Windows Kits \ 8.0 \ Windows Metadata \」の中を見てください。ざっと見てみると、実際には、コードのないメタデータテーブルだけのCLIアセンブリであることがわかります。実際には、ILDASMで開くことができます。これは、WinRT自体が管理されているという意味ではありません。ファイル形式を再利用するだけです。

次に、そのオブジェクトモデルの観点から実装された多数のライブラリがあり、WinRTインターフェイスとクラスが定義されています。もう一度、上記の「Windowsメタデータ」フォルダーを見て、何があるかを確認してください。または、VSでオブジェクトブラウザを起動し、フレームワークセレクタで[Windows 8.0]を選択して、何がカバーされているかを確認します。そこにはたくさんあり、UIだけでは対処できません。また、、、Windows.Data.JsonまたはWindows.Graphics.Printing、などの名前空間も取得しますWindows.Networking.Sockets

次に、特にUIを処理するいくつかのライブラリを取得します。ほとんどのライブラリは、Windows.UIまたはの下のさまざまな名前空間Windows.UI.Xamlです。それらの多くはWPF / Silverlight名前空間に非常によく似ています。たとえばWindows.UI.Xaml.Controls、密接に一致していSystem.Windows.Controlsます。Windows.UI.Xaml.Documentsなどの同上。

現在、.NETは、WinRTコンポーネントを.NETアセンブリであるかのように直接参照する機能を備えています。これは、COM相互運用機能とは異なる動作をします。相互運用機能アセンブリなどの中間アーティファクトは必要ありません/r。.winmdファイルだけで、すべての型とそのメタデータ内のメンバーが、.NETオブジェクトであるかのように表示されます。WinRTライブラリ自体は完全にネイティブであることに注意してください(したがって、WinRTを使用するネイティブC ++プログラムはCLRをまったく必要としません)。管理されているものをすべて公開する魔法はCLR自体の内部にあり、かなり低レベルです。.winmdを参照する.NETプログラムをildasmすると、実際にはexternアセンブリ参照のように見えることがわかります-そこに型を埋め込むなどの巧妙な手口はありません。

また、それは鈍いマッピングでもありません-CLRは、可能な場合、WinRTタイプを同等のものに適合させようとします。だから、例えばのGUID、日付とURIはなるSystem.GuidSystem.DateTimeSystem.Uriそれぞれ。このようなWinRTの収集インターフェースIIterable<T>IVector<T>なるIEnumerable<T>IList<T>。等々。これは両方の方法で行われます-を実装する.NETオブジェクトがありIEnumerable<T>、それをWinRTに返す場合、それはと見なされIIterable<T>ます。

最終的に、これが意味することは、.NET Metroアプリが既存の標準.NETライブラリのサブセット、および(ネイティブの)WinRTライブラリにもアクセスできることです。これらのライブラリの一部は、特にWindows.UI、SilverlightとAPIに非常によく似ています。UIを定義するためのXAMLがまだあり、Silverlightと同じ基本概念(データバインディング、リソース、スタイル、テンプレートなど)を処理します。多くの場合、using新しい名前空間だけでSilverlightアプリを移植できます。 APIが調整されたコードのいくつかの場所を微調整します。

WinRT自体は、HTMLやCSSとは何の関係もありません。JavaScriptとの関係は、.NETの場合と同様に、JavaScriptにも公開されているという意味でのみ関係します。.NET MetroアプリでWinRT UIライブラリを使用する場合は、HTML / CSS / JSを処理する必要はありません(そうしたい場合は、WebViewコントロールをホストできます...)。.NETとSilverlightのスキルはすべて、このプログラミングモデルとの関連性が非常に高くなっています。


WPF-WinRT互換性についてはどうですか?WPF-Silverlightのような矛盾はありますか?
Den

5
@Den WPFは、ここでの比較の良いベースポイントではありません-APIは、Silverlightにはるかに近いです。そのように見ると、2つの間に矛盾がありますが、スケールはSilverlight対WPFではなく、デスクトップ対WP7 Silverlightに近いです。
Pavel Minaev 2011

11
すばらしい答えです。WinRTはNTカーネルに直接アクセスしますか(OSサポートが必要な場合)、Win32を経由しますか?
ティモア2009


66

ビルドの基調講演から:

キーノートスタック

HTML / CSS / JavaScriptアプリとC#/ XAMLアプリの両方に共通のAPIを提供しています。C#とXAMLが使用されますが、正確にはWPFやSilverlightではありません。


8
新しいXAML ThingはC#と(ネイティブ)C ++の両方で使用できるため、これは少し複雑です。これはWPFでもSilverlightでもありませんが、後者に非常に近いです-基調講演で示されているように、既存のSilverlightコードで使用法やその他の簡単なリファクタリングを変更するだけで済むことがよくあります。WPF / Silverlightの背後にある中心的なアイデア(宣言型マークアップ、リソース、スタイル、テンプレート、データバインディングなど)はすべてそこにあります。ほとんどのコントロールもあります。
Pavel Minaev 2011

2
今朝私が見たより良いグラフィックがそこにありますが、私はそれを再び見つけることができません。編集:この質問に対する別の回答のおかげで見つかりました。dougseven.files.wordpress.com/2011/09/win8-new-platform.png
Chris Charabaruk

1
WPFはスライドのどこに収まりますか?
パパラッツォ

1
右下に.NET / Silverlightの方法でグループ化されています。
BoltClock

1
その画像は、既存の部分に関する限り、かなり不正確です。"Windows Kernel Services"を "Win32 kernel32.dll"に、 "Win32"を "Win32 user32.dll + gdi32.dll"に置き換えることでほぼ修正できますが、IEと.NET / Silverlightを最上位に重ねる必要があります。 user32.dll + gdi32.dllのほか、C / C ++ / Java / Delphi / etcもkernel32.dllに到達します。重要なのは、user32.dllとgdi32.dllがWinRTの基礎になっていないこと、およびWindowsストアアプリが、Win32。
Ben Voigt 2013年

37

重要なアイデアは、デスクトップとメトロの2つの開発トラックがあるということです。

  • デスクトップは、古いアプリが存在する場所です。
  • 新しいクラスのアプリケーションであるMetroアプリケーションは、VB.NET、C#、C ++など、さまざまな方法で構築できます。これらの3つの言語オプションは、UIの構築にXAMLを使用できます。別の方法は、UIとアプリケーションコードの両方の開発にJavaScript / HTML5 / CSSを使用することです。

いくつかの重要なポイント:

  • Windows 8は、高級な携帯電話OSのような感じです。
  • Metroでは、携帯電話にないように、トップレベルのウィンドウが重複することはありません。MDIスタイルのアプリケーションが必要な場合は、デスクトップにとどまる必要があります。
  • Metroスタイルアプリは、表示されない場合は自動的に一時停止されます。これは、バッテリー寿命を延ばすために行われました。つまり、ユーザーが操作していない場合でもバックグラウンド処理を実行する既存のデスクトップアプリの多くをMetroに移植しても意味がありません。
  • ARMバージョンのWindows 8はデスクトップアプリケーションをサポートしません。したがって、アプリを作成して、それをWindowsの任意のバージョンで動作させたい場合は、Metroアプリである必要があります。

2
Metroでは、トップレベルウィンドウが重複することはありません。まだPopupmsdn.microsoft.com/en-us/library/windows/apps/…)あるので、必要に応じてMDIのようなものを作成できます。タッチフレンドリーではないUIになってしまうリスクがあるため、悪用しないことをお勧めします。
Pavel Minaev 2011

@Pavel-おもしろい-それは、トップレベルのウィンドウをいくつか並べて実行できるが、オーバーラップしないことを意味しますか?例えば、タイル張り...たとえば、それぞれ画面の半分を共有しますか?現在取り組んでいるWPFアプリには、この種の機能が必要です。
dodgy_coder、2011

3
どのMetroアプリにも、トップレベルウィンドウは1つしかありません。2つのMetroアプリを並べて実行することができますが、これはユーザーが決定することです。アプリがこの構成を強制する方法はありません。さらに、2つのアプリを並べて実行している場合でも、通信して調整することはできません(「共有先」などの明示的なユーザージェスチャーを除く)。
Pavel Minaev 2011

1
一方、もちろん、独自の単一のトップレベルウィンドウを必要な数の領域に分割し、それらのサイズを変更するための移動可能な仕切りを提供できます。 。ただし、アプリスイッチャーではこれらは1つのものとして表示されます(ただし、おそらくそれを望んでいますか?)。
Pavel Minaev 2011

3
Martyn Lovellによれば、そのための意図的なメカニズムはなく、それに使用できるものは意図的に制限されています。たとえば、名前付きパイプは存在せず、メモリマップファイルも存在しません。ソケット(サーバーソケットを含む)がありますが、に接続するときlocalhostは、同じアプリにしか接続できません。共有「既知のフォルダー」(ドキュメント、画像など)の1つで通常のファイルを使用することもできますが、これはかなり粗雑なハックであり、ポーリングを必要とし、ユーザーに表示されます。
Pavel Minaev 2011

24

確かに物事がどこにあるのかを理解するのに役立つアーキテクチャの修正バージョンがあります。Telerik忍者の1人がCLRチームとチャットし、画像を変更しました。

Windows 8プラットフォームとツール(CLRを含む)

ここで、CLRの位置を確認できます。.NETフレームワークに2つのプロファイルが追加されました

1- .NET Metroプロファイル(Metroアプリケーションを扱うCLR)

2- .NETクライアントプロファイル(C#およびVB.NETアプリケーションのCLRランタイム)

これにより、より明確な画像が得られることを願っています。「悪い絵」の記事全体を読むには、何千もの長い議論の価値があります。


17

マイクロソフトの詳細はこちらから。

Windowsランタイムは、APIメタデータ(.winmdファイル)を使用して公開されます。これは、.NETフレームワーク(Ecma-335)で使用されているものと同じ形式です。基になるバイナリコントラクトにより、選択した開発言語で直接WindowsランタイムAPIに簡単にアクセスできます。WindowsランタイムAPIの形状と構造は、C#などの静的言語とJavaScriptなどの動的言語の両方で理解できます。IntelliSenseは、JavaScript、C#、Visual Basic、およびC ++で使用できます。

つまり、Windowsランタイムは、Windowsの機能を公開し、JavaScript / C#/ VB / C ++で利用できる新しいライブラリのセットです。各言語は、いくつかのサンク層を経由する必要がなく、それらを直接理解して呼び出すことができるように作られています。

SilverlightとWPFは、CLRで実行されるXAMLの一種です。他の機能の中でも、WindowsランタイムはSilverlightに非常によく似たバージョンのXAMLを公開しますが、CLR経由ではなく、ネイティブな方法で公開します。CLRからアクセスできますが、C ++からもアクセスできます。


2
「サンク層」が存在する場合があります-たとえば、CLRは実際にRCWを使用しますが、これは実装の詳細です。開発者の観点からは、WinRT .winmdファイルを直接参照し、内部の型を直接操作します。
Pavel Minaev 2011

3
サンクレイヤーはRCWを使用しますが、WindowsランタイムのRCWは古いP / Invoke RCWよりも軽量です。
ReinstateMonica Larry Osterman
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.