What is C++/WinRT exactly?

But what is it really? Is it a new Object oriented replacement for the age-old Win32 API? Is it a replacement for the Qt framework on Windows? Is it a networking library (most examples seem to be about networking). Is it a GUI framework? Is it the preferred way to write new Windows applications? Is it a replacement for the infamous MFC library?

Aydan Haqverdili
asked Feb 1, 2020 at 22:41
Aydan Haqverdili Aydan Haqverdili
416 1 1 gold badge 4 4 silver badges 13 13 bronze badges
See the tag info.
Feb 1, 2020 at 23:43

@user207421 it doesn’t really answer my question. Could you help me see what I am missing? Possibly a small extract from the tag info that answers my question in its entirety?

Feb 1, 2020 at 23:46
Further reading, en.wikipedia.org/wiki/C%2B%2B/WinRT, github.com/Microsoft/cppwinrt
Feb 1, 2020 at 23:58
Looks like it has free COM authoring, would have loved to have that 15 years ago 🙂
Feb 2, 2020 at 0:03

@m.m: It doesn’t. While MIDL 3.0 is a vast improvement over the old MIDL, you’re still required to write your MIDL files if you wish to export types from your components. cppwinrt.exe does generate headers from .winmd files. But that’s not entirely new. We had .TLB’s 15 years ago already.

Feb 2, 2020 at 0:11

2 Answers 2

IInspectable’s answer is factually correct, but a little more context might help as well.

C++/CX (a.k.a. the Visual C++ /ZW switch), Windows Runtime Library (WRL), and C++/WinRT all do basically the same thing: Provide a mechanism for calling «Windows Runtime» style APIs & types from C++ and for authoring «Windows Runtime» style APIs & types.

The OP question gets to a more fundamental question: What is the point of Windows Runtime APIs?

The original Win32 API was designed for a native code world, and most programs were written in C or C++. The Component Object Model (COM) was created as a way to handle runtime versioning (and many other features) using the same basic Application Binary Interface (ABI). C++ is a more natural way to use COM, but you can still technically use C through various macros and what not.

.NET and other managed languages came along later, and use a different calling mechanism. You can use native interop to get to Win32 or COM APIs, but they generally don’t work in a very «C# friendly» way. Various ‘wrapper assemblies’ have been created provide a more C# natural way to access fundamentally C/C++ APIs & types.

With the growth of the Internet and in particular the Worldwide Web, another class of applications are written using HTML5+JavaScript. They don’t have any specific access to Win32 or COM APIs so special modules & libraries are written to cover the functionality gaps.

SO given all three of these major approaches, «Windows Runtime» style is an approach which combines the features of COM with the reflection-rich metadata of .NET. The idea being that an API could be written once and be usable by C++, C#, and HTML5+JavaScript.

Of course there are a lot of issues with using an API beside just being able to call the ABI, and each of those language paradigms are quite different, but from systems programming view that’s the point of it all.

There is also a «Universal Windows Platform» that uses Windows Runtime APIs which itself has three basic ‘appmodels’: XAML, DirectX, and XAML+DirectX. These are the kinds of applications that can make heavy use of C++/WinRT if they are written in C++, but you can also use Windows Runtime APIs from Win32 desktop apps.

WRL is really «ATL 2.0» and was the first attempt at a solution for C++ interop with Windows Runtime APIs. You can use it to consume and author Windows Runtime types but it’s a fair amount of manual work and not documented publicly very well. The primary utility in Win32 desktop applications is the Microsoft::WRL::ComPtr smart-pointer.

If you want to know why C++/CX exists, see this blog series. It was intended to be an easy-to-use model for C++, but it’s often conflated with Managed C++ (it uses the same reserved keywords, but is not at all related to Managed C++ or .NET) and not supported by other compilers.

If you want to know more about the general reason for C++/WinRT, see this MSDN Magazine article. This is intended to be a much more C++-friendly way to use Windows Runtime APIs, is portable to other non-Microsoft compilers, and is increasingly being used both internally and externally for Windows Runtime development. It does require C++17 language features and therefore pushes hard on the quality of your C++ compiler.

Компоненты среды выполнения Windows

Компонент среды выполнения Windows — это автономный программный модуль, который можно создать и использовать в качестве источника информации на любом языке среды Windows, включая C#, C++/WinRT, Visual Basic, JavaScript и C++/CX. Вы можете использовать Visual Studio для создания компонента среды выполнения Windows, который может использоваться либо приложением, использующим пакет SDK для приложений для Windows, либо приложением универсальной платформы Windows (UWP).

Для разработчиков C++ мы рекомендуем использовать C++/WinRT. C++/WinRT — это полностью стандартная проекция языка C++17 для API среды выполнения Windows (WinRT), реализованная как библиотека на основе файлов заголовков и предназначенная для предоставления вам первоклассного доступа к современным интерфейсам API Windows. Сведения о создании компонента среды выполнения Windows с помощью C++/WinRT см. в статье Создание компонентов среды выполнения Windows с помощью C++/WinRT.

Для создания компонента среды выполнения Windows разработчики C#, создающие классические приложения в .NET 6 или более поздней версии, могут использовать C#/WinRT. См. статью Создание компонентов среды выполнения Windows с помощью C#/WinRT.

Раздел	Description
Создание компонентов среды выполнения Windows с помощью C++/WinRT	В этом разделе показано, как с помощью C++/WinRT можно создать и использовать компонент среды выполнения Windows, который можно вызвать из универсального приложения для Windows, созданного с помощью любого языка среды выполнения Windows.
Создание компонентов среды выполнения Windows с помощью C++/CX	В этом разделе показано, как с помощью C++/CX можно создать компонент среды выполнения Windows, который можно вызвать из универсального приложения для Windows, созданного с помощью любого языка для среды выполнения Windows.
Пошаговое руководство по созданию компонента среды выполнения Windows на C++/CX и его вызову с помощью JavaScript или C#	В этом пошаговом руководстве описано, как создать простой компонент среды выполнения Windows, являющийся библиотекой DLL, которую можно вызвать с помощью JavaScript, C# или Visual Basic. Прежде чем приступить к этому пошаговому руководству, убедитесь, что вы понимаете такие понятия, как абстрактный двоичный интерфейс (ABI), классы ссылок и расширения компонентов Visual C++, которые упрощают работу с классами ссылок. Дополнительные сведения см. в разделах Создание компонентов среды выполнения Windows в C++ и Справочник по языку Visual C++ (C++/CX).
Создание компонентов среды выполнения Windows с помощью C# и Visual Basic	Вы можете создавать собственные типы среды выполнения Windows, упакованные в компонент среды выполнения Windows, с помощью управляемого кода. Компонент можно использовать в приложениях универсальной платформы Windows (UWP) с помощью C++, JavaScript, Visual Basic или C#. В данном разделе описываются правила создания компонентов и рассматриваются некоторые аспекты поддержки среды выполнения Windows в .NET. Как правило, такая поддержка разрабатывается таким образом, чтобы быть прозрачной для разработчиков для .NET. Однако при создании компонента для использования с JavaScript или C++необходимо учитывать различия в том, как эти языки поддерживают среду выполнения Windows.
Пошаговое руководство по созданию компонента среды выполнения Windows на C# или Visual Basic и его вызову с помощью JavaScript или C#	В этом пошаговом руководстве описывается, как использовать .NET с Visual Basic или C# для создания собственных типов среды выполнения Windows, упакованных в компонент среды выполнения Windows. В нем также рассказывается, как вызвать этот компонент из универсального приложения для Windows, созданного для Windows с помощью JavaScript.
Создание событий в компонентах среды выполнения Windows	Если компонент среды выполнения Windows вызывает событие определяемого пользователем типа делегата в фоновом потоке (рабочем потоке) и требуется, чтобы JavaScript мог получать событие, можно реализовать и /или вызвать его одним из следующих способов:
Компоненты среды выполнения Windows для неопубликованных приложений UWP, выполняемые через посредник	В этом разделе описывается корпоративная целевая функция, поддерживаемая обновлением Windows 10 и выше, которая позволяет приложениям .NET с сенсорным интерфейсом использовать существующий код, отвечающий за ключевые критически важные операции.

Что такое WinRT и с чем его едят?

Рихтер в своей книге целую главу посвятил данному механизму, но я так и не понял в каких сценариях его имеет смысл применять. Это что-то типа убийцы COM, который нужно применять для межязыкового взаимодействия между управляемым модулем и неуправляемым? Или это вообще какая-то обертка над WinApi?

Отслеживать
задан 24 янв 2018 в 6:59
24.8k 12 12 золотых знаков 63 63 серебряных знака 156 156 бронзовых знаков
24 янв 2018 в 7:24

@Grundy, ну если смотреть краем глаза, то там функциональность стандартного .NET. Всякие потоки я там увидел, например и тп вещи.

24 янв 2018 в 8:32
Это убийца WinAPI. Точнее, модернизированная замена WinAPI для store apps.
24 янв 2018 в 9:38
@VladD Т.е это кастрированный WinAPI или полноценная замена?
24 янв 2018 в 9:40

@iluxa1810 для полноценной замены он еще мало что умеет из возможностей WinAPI, но уже умеет то, чего в WinAPI никогда не было. Короче — игрушка на любителя. Меня пока не впечатлило, пощупайте, может понравится.

24 янв 2018 в 9:43

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

На самом деле, WinRT не является заменой или оберткой для какой либо из предыдущих технологий. WinRT — это принципиально новая технология, направленная на разработку приложений, которые имеют смысл на разных типах устройств. Приложение WinRT может использовать базовый API и работать на всех типах устройств, или использовать расширения API и работать под набором конкретных устройств (например, под ПК и смартфоном, ПК и Xbox и т.п.)

Первоначально эта технология возникла под Windows 8 и называлась WinRT. Позднее в Windows 10 она была заменена на аналогичную технологию UWP, которая охватывает больший набор устройств. Сейчас можно приближенно считать, что это одно и то же.

Приложения UWP/WinRT обладают следующими особенностями:

• Взаимодействие с ОС с помощью специального API Windows Runtime или ограниченного подмножества разрешенных API из Win32/COM и .NET
• Запуск в ограниченной среде, где приложения не имеют прямой доступ к оборудованию, реестру, всей файловой системе и т.п. WinRT приложения имеют доступ только к своей папке данных, а к другим папкам могут получать доступ с явного разрешения пользователя
• Распространение преимущественно через Магазин Windows, подобно распространению мобильных приложений, в противоположность обычному скачиванию инсталляторов с разных сайтов
• Разработка может осуществляться либо на С++ (с расширениями С++/CX для взаимодействия с компонентами WinRT), либо на .NET-языках
• Построение графического интерфейса с помощью XAML-фреймворка, похожего на WPF. В отличие от WPF, приложение строится не как набор окон, а как набор страниц, между которыми пользователь переходит внутри одного окна (как в веб-приложениях). Это позволяет создавать адаптивный интерфейс, имеющий смысл на разных типах устройств.

WinRT не является «убийцей COM», что бы это не значило. COM жив и будет жить, более того, сами компоненты WinRT API внутри представляют из себя COM-объекты. WinRT-приложения, написанные на С++, могут взаимодействовать с ними либо традиционно, как с COM-объектами, либо с использованием специальных расширений языка C++/CX.

WinRT не является «убийцей WinAPI», что бы это не значило. WinRT приложения, написанные на С++, могут как обычно взаимодействовать с подмножеством разрешенных Win32/COM API. Например, функция CreateFile будет доступна, а функции работы с реестром — нет. Конечно, это не позволяет обойти ограничения платформы, т.е. функция CreateFile также будет работать только с файлами в разрешенных папках. Забавный факт: в WinRT нельзя этой функцией открыть устройство NUL, как следствие — код, написанный из предположения, что оно всегда доступно, сломается при портировании под WinRT.

WinRT не является средством для организации взаимодействия между управляемым и неуправляемым кодом (в целом). Тем не менее, расширения языка C++/CX предоставляют возможность организовать взаимодействие между кодом на стандартном С++ и компонентами WinRT.

При подготовке материала использовались источники:
https://stackoverflow.com/questions/60021694/what-is-c-winrt-exactly
https://learn.microsoft.com/ru-ru/windows/uwp/winrt-components/
https://ru.stackoverflow.com/questions/774883/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-winrt-%D0%B8-%D1%81-%D1%87%D0%B5%D0%BC-%D0%B5%D0%B3%D0%BE-%D0%B5%D0%B4%D1%8F%D1%82