Windows 8 运行时(WinRT / Windows 应用商店应用程序 / Windows 10 通用应用程序)与 Silverlight 和 WPF 相比如何?

发布于 2024-12-04 10:20:25 字数 673 浏览 2 评论 0原文

我正在尝试了解用于创建 Metro 风格的应用程序。我知道您可以将它与 XAML 一起使用,并且它基于 .NET,因此 C# 和 VB.NET可以用来编写应用程序,但它似乎与 HTML、CSS、DOM 和 JavaScript 有关。

有人可以用 .NET UI 程序员可以理解的术语用几段话来解释它是什么吗? (我错过了一些理解它所必需的“关键”。)


我们都知道 WPF,Silverlight、Windows 窗体等将在 Windows 8 下继续工作(并且Windows 10)至少在英特尔系统上,所以请不要告诉我......

I am trying to get my head round the new Windows 8 Runtime that is used to create Metro style apps. I know you can use it with XAML and 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.

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.)


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...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

遇到 2024-12-11 10:20:25

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

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

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

然后您将获得几个专门处理 UI 的库 - 大多数这些库是 Windows.UIWindows.UI.Xaml 下的各种命名空间。其中很多与 WPF/Silverlight 命名空间非常相似 - 例如,Windows.UI.Xaml.ControlsSystem.Windows.Controls 密切匹配; Windows.UI.Xaml.Documents 等也是如此。

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

这也不是一个生硬的映射 - CLR 会尽可能使 WinRT 类型适应其等效类型。因此,例如 GUID、日期和 URI 分别变为 System.GuidSystem.DateTimeSystem.Uri; WinRT 集合接口(例如 IIterableIVector 变为 IEnumerableIList)代码>;等等。这是双向的 - 如果您有一个实现 IEnumerable 的 .NET 对象,并将其传递回 WinRT,它会将其视为 IIterable

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

WinRT 本身与 HTML 和 CSS 没有任何关系,它与 JavaScript 的关系只是在某种意义上它也暴露在那里,类似于 .NET 的做法。当您在 .NET Metro 应用程序中使用 WinRT UI 库时,您不需要处理 HTML/CSS/JS(好吧,我猜,如果您真的愿意,您可以托管一个 WebView 控件...)。您的所有 .NET 和 Silverlight 技能在此编程模型中仍然非常相关。

At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements IUnknown and 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.

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.

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.

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

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 /r a .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.

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.DateTime and 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>.

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 using the new namespaces, and tweaking a few places in code where the API was adjusted.

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 WebView control...). All your .NET and Silverlight skills remain very much relevant in this programming model.

微暖i 2024-12-11 10:20:25

来自构建主题演讲:

Keynote stack

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

From the Build keynote:

Keynote stack

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.

国粹 2024-12-11 10:20:25

关键的想法是现在有两个发展轨道——桌面和Metro。

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

一些要点:

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

The key idea is that now there is two development tracks - the Desktop and 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.

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.
旧情别恋 2024-12-11 10:20:25

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

Windows 8 平台和工具(包括 CLR)

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

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

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

我希望这能让您更清楚地了解。阅读一张糟糕的图片值得一千次长时间的讨论。

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 CLR team and modified the picture:

Windows 8 Platform and Tools (including the CLR)

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

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

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

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

孤云独去闲 2024-12-11 10:20:25

Microsoft 此处提供了大量详细信息。

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++ 访问。

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++.

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.

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++.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文