WinRTは、もう一つの抽象層ではない。ちょうど Win32 APIようにカーネルの真上にあるものだ。これは、1993年にWindows NT によってWin32が導入されて以来、Windowsのコアに始めての大変化を記すものである。WinRTは、Win32とは非常に違ったセマンティックによる、新しいアプリケーション実行環境を意味する。
Cを念頭に設計されたWin32とは違って、WinRT APIはC++で書かれており、最初からオブジェクト指向設計である。一貫性、使い易さ、パフォーマンスが新しいランタイムAPIの主要な特徴である。WinRT API におけるあらゆるオブジェクトは、リフレクションをサポートしているので、JavaScriptのような動的言語でさえ、それらを効率良く使うことができる。これと一緒に、C++ベースのライブラリには珍しい 、統一されたオブジェクトモデルが導入される。
備考： Win32 APIは、なくならない。これまでのアプリケーション実行環境を使っている古いアプリケーションは、当然これまで通り動く。
C++ 開発
C++でのユーザーインターフェースは、主にXAMLで書かれるだろう。XAMLと動くこのライブラリは、全てC++に移植され、ネイティブなx86にコンパイルされている。XAML と C++で書かれた Metroアプリケーションは、.NET上では動かない、これらは、他のVisual C++アプリケーションと全く同様に、直接x86にコンパイルされる。
UIコントロールへの呼び出しメソッドは、ちょうどC++におけるあらゆる他のオブジェクトへの呼び出しメソッドと同様である。マシンコードレベルで、スタックにこのポインターをプッシュし、次に v-tableを介して関数を呼び出す。このお陰で、低パワーのデバイスでも可能な最高のパフォーマンスが出せる。
Boostのような最新のC++アプリケーションで使用されているライブラリがサポートされている。
オーバーラップするウィンドウはもはや存在しない
以前のバージョンのWindowsの中核概念であるダイアログボックスは、WinRTには存在しない。パフォーマンスコストと使用性の懸念は、もはや単純にMicrosoftが正当化できるものではない。このパターンを使いたいと思うアプリケーションは、メッセージボックスのような物事を表現するための他の方法を開発しなければならない。
WinRTに入らないもう一つのライブラリは、GDIである。もしアプリケーションがMetroインターフェースを使うなら、全てをそうする必要があり、Metroとこれまでのユーザーインターフェースを混ぜるのは不可能なようだ。
PlayTo コントラクト
もう一つ眼につくコントラクトがPlayTo である。これによってアプリケーションは、オーディオやビデオのようなメディアファイルをチャーム(Charm)へ送ることができる。次にチャームによって、ユーザーはそのファイルを見るのに使いたいと思うアプリケーションを選ぶことができる。恐らく、これらは単なる物理的なファイルだけではなく、データストリームとして表現できるどのようなメディア形式でもよい。
C#/VB: P/Invokeの終焉
.NETからネイティブ関数を呼ぶには普通、構造体をを作って、ポインターを操作する。WinRTでは、全てのAPIは、C#やVBが直接消費できるオブジェクトとして見える。これで、.NET開発者は、C++開発者と同じ立ち位置になる。
アプリケーションの反応性は、Microsoftにとって非常に重要である。このことを開発者に告げるために、50ms以上かかる全OSレベルのAPIコールは、非同期操作に見えることになる。
JavaScript
Windows 8の第4番目の主要言語はJavaScriptである。それはXAMLを使わないが、ネイティブあるいは、.NETアプリケーションと全く同じように、下層の WinRT APIに直接アクセスする。これは PhoneGapのような単なるコンテナではなく、JavaScript開発者は、他の開発者が使う、同じリッチなAPIを使える。
これはJavaScriptなので、選択できるUIツールキットはXAMLでなくHTML と CSSである。 Internet Explorer 10が使うのと同じレンダリングエンジンが Metro JavaScriptアプリケーションによって使われる。ただそれらはブラウザ内で走らないだけである。JavaScriptアプリケーションは、他のMetroアプリケーションと全く同じように見える。
JavaScriptのUIコントロールは、 C++ や .NETのそれらとほとんど同じである。あるコントロールは、HTMLレンダリングエンジン固有であり、他のものはJavaScriptで書かれている。これらJavaScriptベースのコントロールはdivベースで、 jQueryを使って作成されたコントロールとよく似たものである。
Appコンテナとアプリケーション パーミッション
Metroアプリケーションは、「Appコンテナ」として知られているものの中で走る。これがWin32ベースのアプリケーションによって使われているウィンドウ環境を置き換えるようだ。
ほとんどのAPIコールは、下層のカーネルに直接送られる。しかしあるモノは、システムブローカーを通して送られる。システムブローカーは、アプリケーションがアクセスできるフィーチャは、ユーザーが認めたものだけであることを確実にする。例えば、アプリケーションが最初にカメラにアクセスしようとした時に、サービスブローカーはユーザーに承認を催促する。アプリケーションは、必要となる制限されたサービスの全てを示したマニフェストを含める必要がある。このモデルは、モバイルデバイス開発者に大変馴染みものである。
全Metroアプリケーションは、WinRTのappコンテナ内で走り、このようにシステムブローカーによって監視される。たとえC++で書かれていてもである。システムにダメージを与えるアプリケーションの機能を制限しよう、との考えである。恐らく不可能ではないが、WinRTでマルウェアを作るのはWin32よりずっと難しいだろう。
全Metroアプリケーションはデジタルサインされなければならない。
匿名のアプリケーションは許されない。アプリケーションはテストのために自己サインできるが、アプリケーションストアに登場するまでには、本当の証明書を使ってサインされている必要がある。