Ответ 1
WinRT является заменой для вековой C-based Winapi. Это api, который должен использоваться во многих средах исполнения. Назад 20 лет назад, C api было относительно легко interop с. С тех пор это произошло, и COM стал универсальным клеем в последней половине 1990-х годов. Практически любой язык, используемый в Windows, поддерживает COM.
Сборщик мусора - это подробная информация о реализации времени выполнения языка. Коллекционер для .NET очень отличается от сборщика для Javascript, например. Собственные объекты, созданные в обоих, должны соблюдать очень строгие правила коллектора. Это, в свою очередь, означает, что им пришлось бы создавать версии WinRT, специфичные для каждой языковой среды исполнения. Этого не будет делать, даже компания, столь же крупная, как Microsoft, не может позволить себе создавать и поддерживать определенную версию WinRT для каждого языкового связывания. Это также не обязательно, учитывая, что эти языки уже поддерживают COM.
В настоящее время лучшим связыванием для WinRT является С++, поскольку COM работает более эффективно с явным управлением памятью. С большой помощью от новых расширений компилятора С++, которые делают его автоматическим, очень похожи на _com_ptr_t старого с синтаксисом С++/CLI, чтобы избежать его. Связывание с управляемыми языками относительно просто, так как CLR уже имеет отличную поддержку COM-взаимодействия. WinRT также принял формат метаданных .NET. Afaik, на сегодняшний день никакой работы не было сделано на управляемых компиляторах.
EDIT: Ларри Остерман, известный программист и блоггер Microsoft, оставил довольно хороший комментарий в теперь удаленном ответе. Я приведу его здесь, чтобы сохранить его:
WinRT неуправляема, поскольку ОС неуправляема. И, создав WinRT так, как он был разработан, он получает способность выражаться на разных языках, а не только на С++, С# и JS. Например, я мог легко увидеть набор модулей Perl, которые реализуют API-интерфейсы WinRT, которые работают на рабочем столе. Если бы мы реализовали его в .Net, это было бы чрезвычайно сложно