这里有很多微软的细节。

Windows运行时使用API元数据(。winmd文件)。这与. net框架(Ecma-335)使用的格式相同。底层的二进制契约使您可以轻松地直接使用所选的开发语言访问Windows Runtime api。Windows运行时api的形状和结构可以被静态语言(如c#)和动态语言(如JavaScript)理解。智能感知支持JavaScript、c#、Visual Basic和c++。

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

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

有一个修改过的架构版本，它肯定会帮助您了解事情的确切位置。其中一个Telerik忍者和CLR团队聊天，修改了图片:

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

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

2 . net客户端配置文件(CLR运行时为c#和VB。网络应用程序)

我希望这能让你更清楚地了解情况。阅读全文:一张糟糕的图片胜过一千次长时间的讨论。

关键的想法是现在有两个发展轨道-桌面和地铁。

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

以下要点:

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运行时使用API元数据(。winmd文件)。这与. net框架(Ecma-335)使用的格式相同。底层的二进制契约使您可以轻松地直接使用所选的开发语言访问Windows Runtime api。Windows运行时api的形状和结构可以被静态语言(如c#)和动态语言(如JavaScript)理解。智能感知支持JavaScript、c#、Visual Basic和c++。

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

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

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.

然后，根据该对象模型实现了许多库——定义WinRT接口和类。再次，查看上面提到的“Windows元数据”文件夹，看看那里有什么;或者在VS中打开对象浏览器，在框架选择器中选择“Windows 8.0”，看看覆盖了什么。这里有很多内容，而且它不仅仅处理UI—您还可以获得Windows.Data这样的名称空间。Json，或者windows。graphics。打印，或者windows . networking . socket。

然后你会得到几个专门处理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 /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.

这也不是一个生硬的映射——CLR试图在可能的情况下使WinRT类型适应它们的等量物。例如，guid，日期和uri变成了系统。Guid,系统。日期时间和系统。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 using the new namespaces, and tweaking a few places in code where the API was adjusted.

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

在Build主题演讲中:

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