WinRTが管理されないのはなぜですか？
Windows 8にはWinRTが導入されています。これは.NETに似ていますが、管理されていません。なぜ管理されないのですか？パフォーマンスの問題ですか？ガベージコレクションが低レベルAPIに適していないということですか？
WinRTは、古いCベースのWinapiのreplacementです。これは、多くのランタイム環境で使用可能でなければならないAPIです。 20年前、C APIは相互運用が比較的簡単でした。それ以来、COMは1990年代後半に普遍的な接着剤になりました。実際、Windowsで一般的に使用されているすべての言語ランタイムはCOMをサポートしています。
ガベージコレクターは、言語ランタイムの実装の詳細です。 .NETのコレクターは、たとえばJavascriptのコレクターとは大きく異なります。どちらかで作成されたネイティブオブジェクトは、コレクターの非常に厳しいルールを遵守する必要があります。これは、各言語ランタイムに固有のWinRTバージョンを作成する必要があったことを意味します。 Microsoftほどの規模の企業であっても、すべての言語バインディングに対して特定のWinRTバージョンを作成してサポートする余裕はありません。これらの言語がすでにCOMをサポートしていることを考えると、必要ではありません。
現在、WinRTの最適なバインディングはC++です。これは、COMが明示的なメモリ管理により効率的に機能するためです。自動化する新しいC++コンパイラ拡張機能の十分な支援により、古い_com_ptr_tと非常によく似ており、C++/CLIのような構文を使用して回避しています。 CLRにはすでに優れたCOM相互運用サポートがあるため、マネージ言語へのバインドは比較的簡単です。 WinRTは.NETのメタデータ形式も採用しました。 Afaik、今日のマネージドコンパイラに関する作業はまったく行われていません。
編集：著名なマイクロソフトプログラマーでありブロガーであるラリーオスターマンは、削除された回答にかなり良いコメントを残しました。保存するためにここで引用します。
OSが管理されていないため、WinRTは管理されていません。また、WinRTを設計どおりに設計することにより、C++、C＃、JSだけでなく、さまざまな言語で表現できるようになります。たとえば、デスクトップで動作するWinRT APIを実装するPerlモジュールのセットを簡単に見ることができました。 .Netで実装した場合、それは非常に困難でした
WinRTは、開発者がアクセスできるWindows用の最低レベルのAPIであるWin32の代替となることを目的としているため、管理されていません。アンマネージAPIは、開発者に公開される可能性のある最も潜在的にパフォーマンスの高いAPIであり、マネージAPIをその上にラップすることが常に可能であるという推論があります。これはまさに「プロジェクション」の機能です。
また、C++開発者は、C++/CLIが導入するフープをジャンプすることなくWinRTを使用できることを意味します（ http://www2.research.att.com/~bs/bs_faq.html#CppCLIを参照してください ）ただし、WinRTを使用する場合は、COMを学習する必要があります。
本当の質問は、「なぜCOMが必要なのですか？なぜマイクロソフトはそれを発明しなければならなかったのですか？」 COMのすべての追加機能を持たない単純なC++は、実際のOOP作業には不十分であり、C++が「移植性」を提供するというStroustrupの主張は、作業の現実に照らして非常に不誠実です。 http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/ を参照してください