Windows 8 运行时（WinRT/Windows 应用商店应用/Windows 10 通用应用）与 Silverlight 和 WPF 相比如何？

How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF?

提问by Ian Ringrose

I am trying to get my head round the new Windows 8 Runtime that is used to create Metrostyle apps. I know you can use it with XAMLand it is based on .NET so C# and VB.NET can be used to write the apps, but then it seems to have something to do with HTML, CSS, DOM, and JavaScript.

我正在尝试了解用于创建Metro风格应用程序的新 Windows 8 运行时。我知道你可以将它与XAML一起使用，它基于 .NET，所以 C# 和 VB.NET 可用于编写应用程序，但它似乎与 HTML、CSS、DOM 和 JavaScript 有关。

Can someone explain what it is in a few paragraphs, in terms that a .NET UI programmer can understand? (I am missing something “key” that is necessary to understand it.)

有人可以用 .NET UI 程序员可以理解的方式用几段来解释它是什么吗？（我错过了理解它所必需的“关键”。）

---

---

We all know that WPF, Silverlight, Windows Forms, etc. will keep working under Windows 8 (and Windows 10) on at least on Intel systems, so please don't tell me that...

我们都知道 WPF、Silverlight、Windows Forms等将至少在 Intel 系统上继续在 Windows 8（和 Windows 10）下工作，所以请不要告诉我......

回答by Pavel Minaev

At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements IUnknownand does refcounting), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET - for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parametrized ("generic") interfaces.

在最低级别，WinRT 是在 ABI 级别定义的对象模型。它使用 COM 作为基础（因此每个 WinRT 对象都实现IUnknown并执行引用计数），并从那里构建。与旧的 COM 相比，它确实添加了很多新概念，其中大部分直接来自 .NET - 例如，WinRT 对象模型具有委托，并且事件以 .NET 样式完成（具有委托和添加/删除订阅者）方法，每个事件一个）而不是事件源和接收器的旧 COM 模型。在其他值得注意的事情中，WinRT 还具有参数化（“通用”）接口。

One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. In COM you kinda sorta had that with typelibs, but not every COM component had them. For WinRT, the metadata is contained in .winmd files - look inside "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\" in Developer Preview. If you poke around, you'll see that they are actually CLI assemblies with no code, just metadata tables. You can open them with ILDASM, in fact. Note, this doesn't mean that WinRT itself is managed - it simply reuses the file format.

另一个重大变化是所有 WinRT 组件都有可用的元数据，就像 .NET 程序集一样。在 COM 中，类型库有点类似，但并非每个 COM 组件都有。对于 WinRT，元数据包含在 .winmd 文件中 - 在 Developer Preview 中查看“C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\”。如果你四处看看，你会发现它们实际上是没有代码的 CLI 程序集，只是元数据表。事实上，您可以使用 ILDASM 打开它们。请注意，这并不意味着 WinRT 本身是受管理的 - 它只是重用文件格式。

Then there are a number of libraries implemented in terms of that object model - defining WinRT interfaces and classes. Again, look at "Windows Metadata" folder mentioned above to see what's there; or just fire up Object Browser in VS and select "Windows 8.0" in the framework selector, to see what's covered. There's a lot there, and it doesn't deal with UI alone - you also get namespaces such as Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets.

然后根据该对象模型实现了许多库 - 定义 WinRT 接口和类。再次，查看上面提到的“Windows Metadata”文件夹，看看里面有什么；或者直接在 VS 中启动对象浏览器并在框架选择器中选择“Windows 8.0”，以查看所涵盖的内容。那里有很多，它不单独处理 UI - 您还可以获得命名空间，例如Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets。

Then you get several libraries, which are specifically dealing with UI - mostly these would be various namespaces under Windows.UIor Windows.UI.Xaml. A lot of them are very similar to WPF/Silverlight namespaces - e.g. Windows.UI.Xaml.Controlsis closely matching System.Windows.Controls; ditto for Windows.UI.Xaml.Documentsetc.

然后你会得到几个专门处理 UI 的库——大多数是Windows.UI或下的各种命名空间Windows.UI.Xaml。它们中的很多都与 WPF/Silverlight 命名空间非常相似——例如Windows.UI.Xaml.Controls非常匹配System.Windows.Controls；同上Windows.UI.Xaml.Documents等。

Now, .NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop - you don't need any intermediate artifacts such as interop assemblies, you just /ra .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that WinRT libraries themselves are fully native (and so native C++ programs that use WinRT do not require CLR at all) - the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you'll see that it actually looks like an extern assembly reference - there's no sleight of hand trickery such as type embedding there.

现在，.NET 能够直接引用 WinRT 组件，就像它们是 .NET 程序集一样。这与 COM Interop 的工作方式不同 - 您不需要任何中间工件，例如互操作程序集，您只需要/r一个 .winmd 文件，并且所有类型及其元数据中的成员都对您可见，就好像它们是 .NET 对象一样。请注意，WinRT 库本身是完全本机的（因此使用 WinRT 的本机 C++ 程序根本不需要 CLR）——将所有这些内容公开为托管内容的神奇之处在于 CLR 本身，并且是相当低的级别。如果您编写了一个引用 .winmd 的 .NET 程序，您会发现它实际上看起来像一个外部程序集引用 - 那里没有诸如类型嵌入之类的花招。

It's not a blunt mapping, either - CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become System.Guid, System.DateTimeand System.Uri, respectively; WinRT collection interfaces such as IIterable<T>and IVector<T>become IEnumerable<T>and IList<T>; and so on. This goes both ways - if you have a .NET object that implements IEnumerable<T>, and pass it back to WinRT, it'll see it as IIterable<T>.

这也不是一个简单的映射 - CLR 会尽可能将 WinRT 类型调整为对应的类型。因此，例如 GUID、日期和 URI分别变为System.Guid、System.DateTime和System.Uri；WinRT中采集接口，如IIterable<T>和IVector<T>成为IEnumerable<T>和IList<T>; 等等。这是双向的 - 如果您有一个实现 .NET 的对象IEnumerable<T>，并将其传递回 WinRT，它会将其视为IIterable<T>.

Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which - particularly Windows.UI- look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight - data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply by usingthe new namespaces, and tweaking a few places in code where the API was adjusted.

最终，这意味着您的 .NET Metro 应用程序可以访问现有标准 .NET 库的子集，以及（本机）WinRT 库，其中一些 - 特别是Windows.UI- 在 API 方面与 Silverlight 非常相似。您仍然使用 XAML 来定义您的 UI，并且您仍然处理与 Silverlight 中相同的基本概念 - 数据绑定、资源、样式、模板等。在许多情况下，可以简单地通过using新的命名空间来移植 Silverlight 应用程序，并在代码中调整 API 的一些地方。

WinRT itself doesn't have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don't need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app (well, I guess, if you really want to, you can host a WebViewcontrol...). All your .NET and Silverlight skills remain very much relevant in this programming model.

WinRT 本身与 HTML 和 CSS 没有任何关系，它与 JavaScript 的关系仅在于它也在 JavaScript 中公开，类似于它在 .NET 中的处理方式。当您在 .NET Metro 应用程序中使用 WinRT UI 库时，您不需要处理 HTML/CSS/JS（好吧，我想，如果您真的想要，您可以托管一个WebView控件......）。您所有的 .NET 和 Silverlight 技能在此编程模型中仍然非常重要。

回答by RandomEngy

From the Buildkeynote:

来自Build主题演讲：

They're providing common APIs to both HTML/CSS/JavaScript apps and C#/XAML apps. C# and XAML will be used, but it won't be WPF or Silverlight exactly.

他们为 HTML/CSS/JavaScript 应用程序和 C#/XAML 应用程序提供通用 API。将使用 C# 和 XAML，但它不会完全是 WPF 或 Silverlight。

回答by dodgy_coder

The key idea is that now there is two development tracks - the Desktop and Metro.

关键的想法是现在有两个开发轨道 - Desktop 和 Metro。

• The desktop is where the old apps live.
• The new class of applications, Metro applications, can be built in a number of ways, including by VB.NET, C# or C++. These three language options can use XAML for building the UI. The alternative is to use JavaScript/HTML5/CSS for the development of both the UI and application code.

• 桌面是旧应用程序所在的地方。
• 新的应用程序类 Metro 应用程序可以通过多种方式构建，包括通过 VB.NET、C# 或 C++。这三种语言选项可以使用 XAML 来构建 UI。另一种方法是使用 JavaScript/HTML5/CSS 来开发 UI 和应用程序代码。

Some important points:

一些要点：

• Windows 8 feels sort of like an upscaled mobile phone OS.
• In Metro, there are no overlapping top-level windows, just as there are none on a mobile phone. If you want an MDI style application, you need to stay on the desktop.
• Metro style apps are automatically suspended when not visible. This was done to prolong battery life. This means it won't make sense for many existing desktop apps, which perform background processing even while the user is not interacting with them, to be ported to Metro.
• The ARM version of Windows 8 will not support desktop applications. So if you want to write an app and you want it to work on any version of Windows then it has to be a Metro app.

• Windows 8 感觉有点像升级的手机操作系统。
• 在 Metro 中，没有重叠的顶层窗口，就像手机上没有重叠的窗口一样。如果你想要一个 MDI 风格的应用程序，你需要留在桌面上。
• Metro 风格应用程序在不可见时会自动暂停。这样做是为了延长电池寿命。这意味着将许多现有的桌面应用程序移植到 Metro 是没有意义的，即使用户没有与它们交互，它们也会执行后台处理。
• Windows 8 的 ARM 版本将不支持桌面应用程序。因此，如果您想编写一个应用程序并且希望它可以在任何版本的 Windows 上运行，那么它必须是 Metro 应用程序。

回答by vendettamit

There's modified version of the architecture that'll surely help you understand where exactly the things lies. One of the Telerik ninjas had chat with the CLRteam and modified the picture:

架构的修改版本肯定会帮助您了解事物的确切位置。其中一位 Telerik 忍者与CLR团队聊天并修改了图片：

Here you can see where the CLR stands. The .NET framework now has two profiles

在这里您可以看到 CLR 的位置。.NET 框架现在有两个配置文件

1- .NET Metro profile (CLR that deal with Metro application)

1- .NET Metro 配置文件（处理 Metro 应用程序的 CLR）

2- .NET Client profile (CLR runtime for C# and VB.NET applications)

2- .NET 客户端配置文件（C# 和 VB.NET 应用程序的 CLR 运行时）

I hope this gives you a clearer picture. Read the full article in A bad picture is worth a thousand long discussions..

我希望这能给你一个更清晰的画面。阅读一张糟糕的图片值得一千长时间的讨论中的完整文章。.

回答by Steve Rowe

Lots of detail from Microsoft here.

微软这里有很多细节。

The Windows Runtime is exposed using API metadata (.winmd files). This is the same format used by the .NET framework (Ecma-335). The underlying binary contract makes it easy for you to access the Windows Runtime APIs directly in the development language of your choice. The shape and structure of the Windows Runtime APIs can be understood by both static languages such as C# and dynamic languages such as JavaScript. IntelliSense is available in JavaScript, C#, Visual Basic, and C++.

Windows 运行时使用 API 元数据（.winmd 文件）公开。这与 .NET 框架 (Ecma-335) 使用的格式相同。底层二进制合同使您可以轻松地直接使用您选择的开发语言访问 Windows 运行时 API。Windows 运行时 API 的形状和结构可以被静态语言（如 C#）和动态语言（如 JavaScript）理解。IntelliSense 可用于 JavaScript、C#、Visual Basic 和 C++。

In short, Windows Runtime is a new set of libraries exposing Windows functionality and available to JavaScript/C#/VB/C++. Each language has been made to understand and be able to call them directly rather than having to go through some thunking layer.

简而言之，Windows 运行时是一组新的库，公开了 Windows 功能并可用于 JavaScript/C#/VB/C++。每种语言都可以理解并能够直接调用它们，而不必经过一些 thunking 层。

Silverlight and WPF are flavors of XAML that run on the CLR. Among other functionality, Windows Runtime exposes a version of XAML very similar to Silverlight, but does so in a native way, not via the CLR. It can be accessed from the CLR, but also from C++.

Silverlight 和 WPF 是在 CLR 上运行的 XAML 风格。在其他功能中，Windows 运行时公开了一个与 Silverlight 非常相似的 XAML 版本，但以本机方式而不是通过 CLR 公开。它可以从 CLR 访问，也可以从 C++ 访问。