Windowsランタイム

概要

WinRTはC++言語によって実装された、オブジェクト指向設計にもとづく近代的なAPIである（なお前身となる旧来のWin32 APIは、C言語のインターフェイスを持つAPIとして設計され、C/C++両方から利用することができた）。また、COMに基づいたネイティブ（アンマネージ）APIであり、COMのように複数の言語から利用することができる。
従来のCOMとの違いのひとつとして、WinRT APIの定義は".winmd"ファイルに格納されており、ECMA 335メタフォーマットでエンコードされている。同じフォーマットはいくらかの改変を加えた形で.NETでも用いられている。この共通のメタフォーマットにより、従来のP/Invokeと比較して非常に小さなオーバーヘッドでWinRTを.NETアプリケーションから呼び出すことが可能になる。また従来のCOMコンポーネントを.NET言語から直接利用するためには、.NET用にCOMタイプライブラリをインポートするか、COMインターフェイス定義を.NET言語で明示的に記述してラッパーを作成する必要があったが、WinRTではその必要がなくなり、ラッパーを作成することなくWinRTコンポーネントを.NET言語から直接利用できるようになる。また、その逆もしかりであり、.NET言語で作成したWinRTコンポーネントをC++/CXで直接利用することも可能である。文法もよりシンプルになる。
新しいC++/CX (Component Extensions) 言語はC++/CLIの文法をいくつか借用しており、C++によるクラシックなCOMプログラミングよりも少ないグルーコードでWinRTコンポーネントの作成や利用が可能である。また、C++/CLIと比較して、純粋C++型（class/struct）とWinRT型（ref class/ref struct/value class/value struct）が混在する場合において課される制約がほとんどない（C++/CLIにおいては、ガベージコレクションにかかわることから、ネイティブ型にマネージ型のインスタンスを含める場合、gcrootクラステンプレートによるラップが必要になるなどの制約がある）。ただし、C++/CXは常用するべきものではなく、純粋なC++言語で書かれたコードをWinRTアプリケーションで再利用するためにラップする場合など、境界面においてのみ使用することが推奨されている。例えばC++/CXによるコンポーネント拡張はABI境界でのみ使用されることが勧められている。通常の（COM準拠の規約つきの）C++も、新しいテンプレートライブラリであるWindows Runtime C++ Template Library (WRL) で補助することでWinRTコンポーネントをプログラミングする際に利用可能である。目的としては、WRLはCOM用にATLが提供しているものに似ている。しかしながらMSDNではWRLの利用ではなくC++/CXによるプログラミングを推奨している。
例えば従来のデスクトップアプリケーションの場合、C#コードからC++コードを再利用するときや、あるいはC++コードからC#コードを再利用するときは、いずれもP/Invoke、COM相互運用、もしくはマネージ言語であるC++/CLIによるラッパーを介する必要があったが、WinRTの場合はネイティブ拡張であるC++/CXを介することで相互運用可能なコンポーネントを作成・利用できるため、明示的にP/Invokeやマネージ言語を介する必要がなくなる。

歴史

WinRTは、2011年9月12日のMicrosoft Buildカンファレンスで明らかになり、Windows 8の開発者プレビューに含まれていた。また、最初のC++/CXとWinRT開発環境のサポートは、Visual Studio 2012のプレビュー版であるVisual Studio 11に含まれていた。正式版となったVisual Studio 2012にはWindows 8向けのWinRT開発環境が、そして後継のVisual Studio 2013にはWindows 8.1向けのWinRT開発環境が含まれている。Visual Studio 2013ではWindows 8向けのWinRTアプリケーションを開発することはできないが、Visual Studio 2012と2013は共存可能である。
Visual Studio 2015にはWindows 10（Universal Windows Platform, UWP）向けのWinRT開発環境が含まれている。Visual Studio 2015では、引き続きWindows 8.1向けのWinRTアプリケーション開発もサポートされる。

技術

WinRTコンポーネントは、ネイティブ、マネージコード、スクリプティングを含む複数の言語とABIの間の相互運用性を視野に入れて設計されている。
WinRTアプリケーションはサンドボックス内で実行される。そのため、従来のデスクトップアプリケーションと比べてインストールや動作に関する制約が設けられるものの、セキュリティ面での安全性は向上する。WinRT APIは、従来のデスクトップ版Win32 APIと一部を共有するWin32 APIサブセットの上に構築されており、Win32 APIの代替というよりはむしろ高レベルのラッパーであるといえる。これは内部実装にWin32 APIを利用しているMicrosoft .NET Frameworkで使われているのと同じアプローチである。

メタデータ

WinRTメタデータはWinRTに対して書かれたコードを補足する。プログラミング言語にかかわらずオブジェクト指向的なプログラミングモデルを定義し、リフレクションなどの機能も提供する。 マイクロソフトのC++専門家であるハーブ・サッターのBUILDカンファレンスにおいての説明によると、WinRTメタデータは.NETメタデータと同じ物である。ネイティブコードにはメタデータを含めることはできず、別にWINMDファイルとして保存される。その場合でもリフレクションは.NETアセンブリ同様に動作する。
.NETメタデータと同じものなので、WinRTに対してネイティブ言語で開発されたコードは.NET上のプログラミング言語からも利用することができる。

型システム

WinRTはメタデータに基づいた、リッチなオブジェクト指向のクラスベース型システムを持っている。WinRTは.NET Frameworkにみられるような、クラス、メソッド、プロパティ、デリゲートおよびイベントといった構成概念に対応するものをサポートする。
One of the major additions to WinRT relative to COM is the cross-ABI, .NET-style generics. In C++/CX these are declared using the generic keyword with a syntax very similar to that of the template keyword. WinRT classes (ref classes) can also be genericized using C++ templates but only template instantiations can be exported to .winmd metadata (with some name mangling), unlike WinRT generics which preserve their genericity in the metadata. WinRT also provides a library of generic containers that parallel those from the C++ standard library, as well as some back-and-forth conversion functions. The consumption of WinRT collections in .NET languages (e.g. C# and VB) as well as in JavaScript is more transparent than in the case of C++, with automated mappings into their natural equivalents taking place behind the scenes. When authoring a WinRT component in a managed language, some extra, COM-style rules need to be followed, e.g. .NET framework collection types cannot be declared as return types, but only the WinRT interfaces that they implement can be used at the component boundary.

WinRT コンポーネント

Classes that are compiled to target the WinRT are called WinRT components. They are classes that can be written in any supported language and for any supported platform. The key is the metadata. This metadata makes it possible to interface with the component from any other WinRT language. The runtime requires WinRT components that are built with .NET Framework to use the defined interface types or .NET type interfaces, which automatically map to the first named. Inheritance is as yet not supported in managed WinRT components, except for XAML classes.

プログラミングインターフェイス

Programs and libraries targeted for the WinRT runtime can be created and consumed from a number of platforms and programming languages. Notably C/C++ (either with language extensions offering first-class support for WinRT concepts, or with a lower-level template library allowing to write code in standard C++), .NET (C# and VB.NET) and JavaScript. This is made possible by the metadata.
In WinRT terminology, a language binding is referred to as a language projection.

C++ (WRL, コンポーネント拡張)

Native C++ is a first-class citizen of the WinRT-platform. To use WinRT from C++ two supported options are available: WRL—an ATL-style template library—and C++/CX (C++ with Component Extensions) which resembles C++/CLI. Because of the internal consumption requirements at Microsoft, WRL is exception-free, meaning its return-value discipline is HRESULT-based just like that of COM. C++/CX on the other hand wraps-up calls to WinRT with code that does error checking and throws exceptions as appropriate.
C++/CX has a number of extensions that enable integration with the platform and its type system. The syntax resembles the one of C++/CLI although it produces native code and metadata that integrates with the runtime. For example WinRT objects may be allocated with ref new, which is the counterpart of gcnew from C++/CLI. The hat operator (^) retains its meaning, however in the case where both the caller and callee are written in C++ and living in the same process, a hat reference is simply a pointer to a vptr to a vtable.
An addition to C++/CX relative to traditional C++ COM programming are partial classes, again inspired from .NET. These allow for instance XAML code to be translated into C++ code by tools and then combined with human-written code to produce the complete class while allowing clean separation of the machine-generated and human-edited parts of a class implementation into different files.
WinRT is a native platform and supports any native C++ code. A C++ developer can reuse existing native C/C++ libraries with the only need to use the language extensions when writing code that is interfacing with the runtime.

JavaScript

Microsoft initially announced that HTML5 and JavaScript would be integrated as part of the development experience for Windows 8. The "Chakra" JavaScript engine which was developed for Internet Explorer 9 integrates with WinRT. That makes JavaScript a first-class citizen in the WinRT ecosystem.
The JavaScript environment does some tricks under the hood. It adapts WinRT features to follow the JavaScript naming conventions to make the developer get the same experience as on the Web-platform. Namespaces are mapped to JavaScript objects and some special members are also added in some cases to make the developer experience similar to any web scenario.
Metro interfaces can be built with HTML5 and CSS and JavaScript in code-behind.
The current version is JavaScript 5.

API

WinRTは、Modern UI（旧称：Metro UI）のような、Windows 8の機能を開発者に公開するクラスライブラリの形でApplication Programming Interface (API) を搭載している。WinRTはサポート対象となるあらゆる言語から利用可能である。

Windows classes

The Windows classes are native C/C++ libraries (unmanaged) that are exposed by the WinRT. They provide access to all functionality from XAML parser to the camera function.

Naming conventions

The naming conventions for the components (classes and other members) in the API are heavily influenced by the .NET naming conventions which uses camel case. Microsoft recommends users to follow these rules in case where no others are given.
These conventions are projected differently in some languages, like JavaScript, which converts it to its conventions and the other way around. This is to give a native and consistent experience regardless of the programming language.