Winrt что это в windows 10

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Microsoft Windows Runtime

Windows Runtime

A component of Microsoft Windows
Details
Other names	WinRT
Type	API
Included with	Microsoft Windows Server 2012, Microsoft Windows 8, Microsoft Windows RT, Microsoft Windows 8.1, Microsoft Windows Server 2012 R2, Microsoft Windows 10, Microsoft Windows Server 2016
Related components
Microsoft Windows Store, Microsoft Windows API

Windows Runtime (WinRT) − модель программирования от Microsoft, впервые введенную в Windows 8 и Windows Server 2012 в 2012 году. WinRT поддерживает разработку на C++ (обычно с использованием расширения языка Component Extensions, C++/CX), управляемых языках C# и VB.NET, а также JavaScript. Компоненты WinRT разработаны с функциональной совместью между несколькими языками и API-интерфейсов, в том числе родной, управляемый и скриптовый языки.

Windows Phone 8.1 использует версию Windows Runtime под названием Windows Phone Runtime. Это позволяет разрабатывать приложения в C# и VB.NET, а также компоненты Windows Runtime в C++/CX. [1]

Содержание

Технология

Новый C++/CX (Component Extensions) язык, который заимствует часть синтаксиса C++/CLI, позволяет писать и использовать компоненты WinRT с меньшим количеством связующего кода, видимого для программиста, по сравнению с классическим COM программированием на C++, и накладывает меньше ограничений по сравнению с C++/CLI при смешении типов. Компонентные Расширения C++/CX рекомендуются для использования только в API-boundary, а не для других целей. Стандартный C++ также может быть использован для программирования с компонентами WinRT, с помощью Windows Runtime C++ Template Library (WRL), которая аналогична по назначению тому, что Active Template Library обеспечивает COM.

WinRT приложения выполняются в песочнице и требуют прямого разрешения пользователя для доступа к критически важным функциям операционной системы и базового оборудования. Доступ к файлам ограничивается несколькими заранее определенными местами, такими как каталоги, документы или изображения.

Сервисы

Метаданные

Метаданные описывает код, написанный для платформы WinRT. Они определяет модель программирования, которая позволяет писать объектно-ориентированный код, который может быть поделен между языками программирования, а также дает возможность предоставлять сервисы, подобные рефлексии.

Герб Саттер, эксперт по C++ в Microsoft, объяснил во время своей сессии по C++ на конференции Build 2011, что метаданные WinRT это метаданные CLI. Машинный код (т.е. машинный код процессора) не может содержать метаданные и поэтому хранится в отдельных WINMD-файлах, которые могут быть отображенны как обычные CLI сборки.

Так как это метаданные CLI, код, написанный на родном языке WinRT можно использовать с управляемыми CLI языками.

Тип системы

Компоненты WinRT

Интерфейсы программирования

В терминологии WinRT, языковая привязка называется языковой проекцией.

C++ (WRL, Component Extensions)

Пользователи, которые взаимодействуют с другим языком должен иметь подпись с типами WinRT или управляемый тип, который конвертируется.

JavaScript

Приложения WinRT также могут быть закодированы с использованием HTML с JavaScript в code-behind, которые выполнены с помощью движка рендеринга Trident и движока Chakra JavaScript, оба из которых также используются Internet Explorer. При кодировании приложения WinRT в JavaScript, его особенности адаптируются, чтобы следовать схемам наименования JavaScript и пространства имен также отображаются на объекты JavaScript.

WinRT поставляется с интерфейсом прикладного программирования (API) в виде библиотеки классов, который предоставляет возможности Windows 8 для разработчиков,как и его многонаправленный интерфейс API. Он доступен и используется из любого поддерживаемого языка.

Классы Runtime

Классы Windows Runtime представляют собой набор пакетов SDK, которые обеспечивают доступ ко всем функциям из из XAML парсера для функции камеры. В SDK реализованы как родные библиотеки C/C++ (неуправляемые).

Схемы наименования

Ограничения и правила

Поскольку Windows Runtime проецируется на различных языках, некоторые ограничения основных типов данных существуют для того, чтобы разместить все эти языки. Программисты должны быть осторожны с поведением этих типов при использовании с открытым доступом (для параметров метода, метод возвращаемых значений, свойств и т.д.)

История версий

Версия Windows
Windows 8	Windows Runtime
Windows 8.1
Windows 10	Universal Windows Platform (UWP)

Windows Phone Runtime

Начиная с Windows Phone 8 можно разрабатывать приложения, используя версию Windows Runtime, под названием Windows Phone Runtime (WPRT). Несмотря на то,что WP8 принес ограниченную поддержку, платформа действительно в конечном счете сходится с Windows 8.1 в Windows Phone 8.1.

Windows Phone 8

Windows Phone 8.1

Поддержка Windows Runtime на Windows Phone 8.1 сходится с Windows 8.1. Релиз привносит на платформу полный API Windows Runtime, включая поддержку среды выполнения Windows Runtime XAML Framework и привязки к языку для C++/CX и HTML5-JavaScript. Существует также тип проекта под названием Универсальные приложения, позволяющие приложениям совместно использовать код через версии 8.1 Windows Phone и Windows.

Обновлена версия Windows Phone 8 Silverlight Framework. Она может использовать некоторые новые функции в среде выполнения Windows.

Windows Phone Runtime использует формат пакета AppX из Windows 10, ранее использовав Silverlight XAP.

Источник

Простое приложение WinRT

Пользовательский интерфейс Windows 8 реализует новую парадигму проектирования, которая с большой вероятностью будет отражена в приложениях Windows Store. Эта парадигма, отчасти вдохновленная городскими вывесками, ставит на первое место содержание, а не программный «хром»; для нее характерно использование простых шрифтов, четкого и открытого стиля оформления, интерфейса на базе плиток и переходных анимаций.

Одной из важных характеристик новой рабочей среды является ее ориентированность на многопальцевый сенсорный ввод, кардинально изменивший отношения между человеком и компьютером. Собственно, определение «многопальцевый» стало лишним, поскольку практически все новые сенсорные устройства реагируют на одновременные касания нескольких пальцев. В одной из частей нового интерфейса программирования приложений Windows 8 ввод с сенсорного экрана, мыши и пера рассматривается универсально, так что приложения автоматически готовы к использованию со всеми тремя источниками ввода.

Windows Phone 8 является конкурентом для популярных мобильных операционных систем, таких как Android и iOS. Для разработки бесплатных программ на айпад и айфон используются совершенно другие языки программирования и платформы (Java для Android и Objective-C для iOS). В настоящее время для приложений Windows 8 существуют три основных варианта программирования, каждый из которых основан на определенном языке программирования и языке разметки:

C# или Visual Basic и XAML;

JavaScript и HTML5.

В этой и последующих статьях мы будем использовать второй вариант. Давайте создадим простой пример, чтобы продемонстрировать возможности WinRT. Предполагается, что на вашем компьютере установлена система Windows 8 или Windows 8.1, а также новейшая версия Microsoft Visual Studio, поддерживающая создание приложений Windows 8. Запустите Visual Studio со стартового экрана Windows 8. Пора браться за программирование!

Первый проект

Visual Studio создаст решение с именем WinRTTestApp, проект WinRTTestApp в этом решении, а также набор файлов в проекте. Эти файлы перечислены в окне Solution Explorer в правой части экрана Visual Studio. Каждое решение Visual Studio содержит хотя бы один проект, но решение может содержать дополнительные проекты приложений и библиотек.

В список файлов этого проекта входит файл с именем MainPage.xaml. Щелкнув маленькой стрелке рядом с этим файлов вы увидите файл с именем MainPage.xaml.cs смещенный вправо от MainPage.xaml:

Файлы MainPage.xaml и MainPage.xaml.cs включены в окно Solution Explorer, потому что каждый из них вносит свой вклад в определение класса MainPage. В простых программах, таких как наша, класс MainPage определяет все визуальные аспекты и пользовательский интерфейс приложения.

Большое место в этом файле занимают директивы using для всех пространств имен, которые, как предполагается, понадобятся для работы программы. Впрочем, в большинстве файлов MainPage.xaml.cs нужны не все перечисленные пространства имен, а во многих файлах требуются дополнительные пространства.

Пространства имен делятся на две общие категории по префиксу имени:

Как можно предположить по виду списка директив using, пространства имен, начинающиеся с Windows.UI.Xaml, играют важную роль в работе Windows Runtime.

Документация Windows 8 API упорядочена по пространствам имен. Если вы хотите найти документацию класса Page, информация о пространстве имен, в котором этот класс определен, упростит поиск. Наведите указатель мыши на имя Page в исходном коде MainPage.xaml.cs; вы увидите, что класс Page находится в пространстве имен Windows.UI.Xaml.Controls (вы можете нажать клавишу F1 в Visual Studio для загрузки описания класса на MSDN).

Конструктор класса MainPage вызывает метод InitializeComponent() (о котором мы вскоре поговорим подробнее).

Обратите внимание на ключевое слово partial в определении класса MainPage. Это ключевое слово обычно означает, что определение класса продолжается в другом файле с исходным кодом C#. Как вы вскоре убедитесь, в нашем случае дело обстоит именно так, однако недостающей частью класса MainPage является не другой файл с кодом C#, а файл MainPage.xaml:

Атрибут x:Class может присутствовать только в корневом элементе файла XAML. Этот конкретный атрибут означает «класс с именем MainPage в пространстве имен WinRTTestApp определяется как производный от Page». Он означает то же, что и определение класса в файле C#!

Далее следуют объявления пространств имен XML. Как обычно, эти URI не подразумевают фактического обращения к веб-страницам, а служат уникальными идентификаторами, поддерживаемыми некоторыми компаниями или организациями. Первые два пространства особенно важны:

Первое объявление пространства имен без префикса относится к открытым классам, структурам и перечислениям, определенным в Windows Runtime; в эту категорию входят все элементы управления и вообще все, что может включаться в файл XAML, включая классы Page и Grid конкретного файла. Слово представление (presentation) в URI относится к визуальному пользовательскому интерфейсу, и это отличает его от других типов приложений, использующих XAML. Например, при использовании XAML для Windows Workflow Foundation (WF) в конце URI пространства имен по умолчанию стояло бы слово «workflow».

Второе объявление пространства имен связывает префикс «x» с элементами и атрибутами, принадлежащими XAML. Только девять из них могут использоваться в приложениях Windows Runtime; и конечно, самым важным является атрибут x:Class.

Третье объявление пространства имен выглядит интереснее:

Оно связывает префикс XML local с пространством имен WinRTTestApp данного конкретного приложения. Если вы создадите в своем приложении пользовательские классы, для обращения к ним в XAML будет использоваться префикс local. Если вам потребуется обращаться к классам из библиотек программного кода, вы определите дополнительные объявления пространств имен XML с указанием имен сборок и пространств имен этих библиотек. Позднее вы увидите, как это делается.

Оставшиеся объявления пространств имен предназначены для Microsoft Expression Blend. Expression Blend может вставлять собственную разметку, которая должна игнорироваться компилятором Visual Studio; отсюда атрибут ignorable, требующий еще одного объявления пространства имен. В любой программе из последующих примеров три последних строки корневого элемента Page можно удалить.

Для вывода абзаца текста в Windows Runtime обычно используется элемент управления TextBlock (еще один класс, определенный в пространстве имен Windows.UI.Xaml.Controls). Давайте разместим элемент TextBlock в Grid с одной ячейкой и назначим ему набор атрибутов. В действительности эти атрибуты являются свойствами, определяемыми классом TextBlock:

Порядок следования атрибутов роли не играет, как, разумеется, и отступы. Если вы очень торопитесь, все атрибуты, кроме Text, можно опустить. В процессе ввода текста функция Visual Studio IntelliSense предлагает имена атрибутов и возможные значения. Часто достаточно выбрать нужный вариант из списка. А когда вы завершаете ввод TextBlock, в представлении конструирования (конструктор представления, design view) Visual Studio отображается внешний вид страницы.

Также можно обойтись вообще без ввода, просто перетащить TextBlock из палитры инструментов Toolbox в Visual Studio, а затем задать свойства в таблице, но я так поступать не стану. Процесс создания программ будет описываться так, словно мы с вами вводим код и разметку с клавиатуры, как настоящие программисты.

У элемента TextBlock есть свойства Width и Height, но обычно задавать их не обязательно. Более того, задание свойств Width и Height в этом конкретном случае может привести к отсечению части текста или нарушению выравнивания текста по центру страницы. Элемент TextBlock умеет определять свои размеры лучше вас.

Чтобы завершить выполнение программы, нажмите клавиши Shift+F5 в Visual Studio или выберите команду Stop Debugging в меню Debug. Вы увидите, что программа не только была выполнена, но и стала доступной на начальном экране. Если вы сами создали проект, плитка выглядит не слишком впечатляюще, однако плитки программы хранятся в каталоге Assets проекта, так что при желании вы можете украсить их. Программу можно повторно запустить вне отладчика Visual Studio прямо с начального экрана Windows 8.

Графическое приветствие

Традиционные программы «Hello world» выводят приветствие в текстовом виде, но это не единственный вариант. Давайте используем растровое изображение с моего веб-сайта при помощи крошечного фрагмента разметки XAML:

Загрузка растрового изображения по сети зависит от наличия сетевого подключения, и даже при его наличии может потребовать некоторого времени. Чтобы гарантировать доступность изображения, лучше включить его в само приложение. Windows Runtime поддерживает популярные графические форматы BMP, JPEG, PNG и GIF, а также некоторые менее распространенные форматы. Для таких изображений, как наше, чаще всего используется формат PNG; сохраните его под именем win8logo.png.

Обычно для хранения растровых изображений, используемых проектом, используется каталог с именем Images. В окне Solution Explorer щелкните правой кнопкой мыши на имени проекта, выберите команды Add и New Folder. (Или если проект выделен в Solution Explorer, выберите команду New Folder в меню Project.) Введите имя папки, например, Images.

Файл XAML со ссылкой на изображение очень похож на аналогичный файл для обращения к изображению в Интернете:

Обратите внимание: в свойстве Source указывается папка и имя файла. Некоторые программисты предпочитают хранить графику, используемую в приложении, в папке с именем Assets. В стандартный проект включается папка Assets с изображениями логотипа приложения; вы можете использовать ее для своих изображений, вместо того чтобы создавать отдельную папку.

Источник

C#/WinRT

Обоснование для использования C#/WinRT

C#/WinRT также поддерживает компоненты в пакете SDK для приложений для Windows, включая WinUI 3. Пакет SDK для приложений для Windows выводит из ОС собственные элементы управления пользовательским интерфейсом Майкрософт и другие собственные компоненты. Это позволяет разработчикам приложений использовать новейшие элементы управления и компоненты в Windows 10 версии 1809 и выше.

Новое

Последние выпуски C#/WinRT можно найти на странице заметок о выпуске в репозитории GitHub.

Использование

Создание и распространение сборки взаимодействия

Ссылка на сборку взаимодействия

Как правило, на сборки взаимодействия C#/WinRT ссылаются проекты приложений. Однако на них также могут ссылаться промежуточные сборки взаимодействия. Например, сборка взаимодействия WinUI ссылается на сборку взаимодействия Windows SDK.

Если вы распространяете сторонний компонент WinRT без официальной сборки взаимодействия, для создания собственных частных источников проекции в проекте приложения можно выполнить процедуру создания сборки взаимодействия. Мы не рекомендуем использовать этот подход, так как он может привести к конфликтам проекций одного и того же типа в рамках одного процесса. Для предотвращения таких ситуаций используются пакеты NuGet, созданные по схеме семантического версионирования. Предпочтительно использовать официальную сборку взаимодействия стороннего производителя.

Поддержка внедрения для типов WinRT (предварительная версия)

Дополнительные сведения см. в документации по встраиванию C#/WinRT в нашем репозитории.

Активация типа WinRT

C#/WinRT поддерживает активацию типов WinRT, размещенных в операционной системе, а также сторонних компонентов, например Win2D. Поддержка активации сторонних компонентов в классическом приложении включается путем активации WinRT без регистрации, доступной в Windows 10 версии 1903 и более поздних. Если компонент создан специально для приложений UWP, для нее также может потребоваться пакет серверов пересылки VCRT.

C#/WinRT также предоставляет резервный путь активации, если Windows не удается активировать тип, как описано выше. В этом случае C#/WinRT пытается определить расположение собственной библиотеки DLL реализации на основе полного имени типа, постепенно удаляя элементы. Например, резервная логика попытается активировать тип Contoso.Controls.Widget из перечисленных ниже модулей в такой последовательности:

C#/WinRT использует для поиска библиотеки DLL реализации альтернативный порядок поиска LoadLibrary. Пакет приложения, в котором предусмотрено использование такого резервного способа, наряду с модулем приложения должен включать библиотеку DLL реализации.

Распространенные ошибки и их устранение

Ошибка: «Windows Metadata not provided or detected» (Метаданные Windows не предоставлены или не обнаружены).

Error CS0246: The type or namespace name «Windows» could not be found (are you missing a using directive or an assembly reference?) (Ошибка CS0246. Не удалось найти тип или имя пространства имен Windows (возможно, отсутствует директива using или ссылка на сборку)).

Сообщение об ошибке или предупреждающее сообщение	Причина
Предупреждение MSB3277. Обнаружены конфликты между разными версиями WinRT.Runtime или Microsoft.Windows.SDK.NET, разрешить которые не удалось.	Это предупреждение сборки возникает при ссылке на библиотеку, которая предоставляет типы Windows SDK на своей поверхности API.
Ошибка CS1705. Сборка «AssemblyName1» использует «TypeName» более поздней версии, чем сборка «AssemblyName2», на которую дается ссылка	Эта ошибка компилятора сборки возникает при указании и использовании типов Windows SDK, представленных в библиотеке.
System.IO.FileLoadException	Эта ошибка среды выполнения может возникнуть при вызове определенных API в библиотеке, которая не предоставляет типы Windows SDK.

Известные проблемы

Известные проблемы и критические изменения указаны в репозитории C#/WinRT в GitHub.

Источник

Что нового в C++/WinRT

В этой статье описаны возможности и изменения, реализованные в новых версиях C++/WinRT.

Сводка по последним улучшениям и дополнениям за март 2020 г.

Время сборки сократилось на 23 %

Разработчики C++/WinRT вместе с разработчиками компилятора C++ сделали все возможное, чтобы сократить время на сборку. Мы корпели над анализом работы компилятора в попытке понять, как можно изменить структуру внутренних компонентов C++/WinRT, чтобы компилятор C++ быстрее выполнял компиляцию, и как улучшить работу компилятора C++ с библиотекой C++/WinRT. В результате мы оптимизировали C++/WinRT для компилятора, а компилятор — для C++/WinRT.

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

Версия	Размер PCH (в байтах)	Время (с)
C++/WinRT (за июль) с Visual C++ 16.3	3 004 104 632	31
C++/WinRT версии 2.0.200316.3 с Visual C++ 16.5	2 393 515 336	24

Уменьшение размера на 20 % и сокращение времени сборки на 23 %

Улучшенная поддержка MSBuild

Мы приложили немало усилий, чтобы улучшить поддержку MSBuild с учетом большого количества различных сценариев.

Ускорено кэширование фабрики

Мы оптимизировали метод встраивания критических путей в кэше фабрики, чтобы ускорить выполнение.

это улучшение не влияет на размер кода, как описано ниже в разделе оптимизированный код EH. если в приложении используется интенсивная обработка исключений C++, можно сжать двоичный файл с помощью параметра, который по умолчанию включен в новые проекты, созданные с помощью Visual Studio 2019 16,3 и более поздних версий.

Повышена эффективность упаковки-преобразования

Повышена эффективность winrt::box_value при использовании с приложениями XAML (см. статью Упаковка-преобразование и распаковка-преобразование скалярных значений в IInspectable с помощью C++/WinRT). Вы наверняка заметите уменьшение размера кода в приложениях, часто выполняющих упаковку-преобразование.

Поддержка реализации COM-интерфейсов, реализующих IInspectable

Теперь с помощью C++/WinRT вы можете реализовать COM-интерфейс (не для среды выполнения Windows), который реализует IInspectable. Дополнительные сведения см. в статье о поддержке реализации COM-интерфейсов, реализующих IInspectable.

Улучшения блокировки модулей

Функции управления блокировкой модулей теперь поддерживают сценарии размещения и позволяют устранить блокировку на уровне модулей. Дополнительные сведения см. в статье Улучшения блокировки модулей.

Поддержка вывода сведений об ошибках, не относящихся к среде выполнения Windows

Некоторые API (даже некоторые API среды выполнения Windows) сообщают об ошибках, не используя интерфейсы API для определения источников ошибок в среде выполнения Windows. Для таких случаев в C++/WinRT снова используется COM-интерфейс вывода сведений об ошибках. См. статью о поддержке в C++/WinRT вывода сведений об ошибках, не относящихся к WinRT.

Поддержка модуля C++

Модуль C++ снова поддерживается, но только в экспериментальном режиме. Эта функция пока что не готова для компилятора C++.

Более эффективное возобновление работы сопрограмм

В C++/WinRT уже налажена работа сопрограмм, но мы продолжаем искать способы их улучшения. См. статью Улучшение масштабируемости при возобновлении работы сопрограмм.

Добавлены асинхронные вспомогательные функции when_all и when_any

Вспомогательная функция when_all создает объект операции IAsyncAction, которая выполняется после завершения всех указанных ожидающих операций. Вспомогательная функция when_any создает объект операции IAsyncAction, которая выполняется после завершения всех указанных ожидающих операций.

См. статьи о добавлении асинхронных вспомогательных функций when_any и when_all.

Другие оптимизации и дополнения

Кроме того, в этой версии исправлено множество ошибок, выполнена некоторая оптимизация и внесены дополнения, включая различные улучшения для упрощения отладки, оптимизации внутренних компонентов и реализаций по умолчанию. Полный список см. по этой ссылке: https://github.com/microsoft/xlang/pulls?q=is%3Apr+is%3Aclosed.

Новости и изменения в C++/WinRT 2.0

Изменения в C++/WinRT Visual Studio Extension (VSIX) для версии 2.0

Изменения в пакете Microsoft.Windows.CppWinRT NuGet для версии 2.0

Изменения в C++/WinRT для версии 2.0

Открытый код

Библиотеки xlang

Меньше зависимостей

Все эти библиотеки DLL доступны не только в Windows 10, но и в более ранних версиях вплоть до Windows 7, а также в Windows Vista. Теперь при необходимости можно запустить cppwinrt.exe для создания заголовков C++ проекта на старом сервере сборки под управлением Windows 7. Приложив немного усилий, можно даже запустить C++/WinRT в Windows 7, если вам это требуется.

Сравните приведенный выше список с зависимостями cppwinrt.exe 1.0.

Атрибут среды выполнения Windows noexcept

C++/WinRT использует это преимущество, создавая реализации C++ noexcept как потребляющего кода, так и кода разработки. Если у вас есть безотказные методы или свойства API, и вас беспокоит размер кода, можете исследовать этот атрибут.

Создание оптимизированного кода

C++/WinRT теперь генерирует еще более эффективный исходный код C++, поэтому компилятор C++ может создавать более компактный и эффективный двоичный код. Многие из улучшений направлены на снижение затрат на обработку исключений за счет отказа от ненужной очистки информации. Для двоичных файлов, использующих большие объемы кода C++/WinRT, ожидаемое сокращение размера кода составит примерно 4 %. Код также более эффективен (работает быстрее) благодаря меньшему количеству команд.

Эти улучшения основаны на новой функции взаимодействия, которая также доступна для вас. Все типы C++/WinRT, являющиеся владельцами ресурсов, теперь содержат конструктор для назначения владельца напрямую, вместо предыдущей двухэтапной схемы.

Создание оптимизированного кода обработки исключений (EH)

Это изменение дополняет работу, проделанную командой оптимизаторов Microsoft C++, чтобы снизить затраты на обработку исключений. Если в своем коде вы интенсивно используете двоичные интерфейсы приложений (ABI) (такие как COM), то увидите, что этот шаблон используется довольно часто.

C++/WinRT генерирует этот шаблон для каждого реализованного API. При наличии тысяч функций API любая оптимизация может быть существенной. В прошлом оптимизатор не обнаруживал, что все блоки catch идентичны, поэтому дублировал большое количество кода каждого ABI (что, в свою очередь, способствовало убеждению, что использование исключений в системном коде приводит к созданию больших двоичных файлов). Однако, начиная с Visual Studio 2019, компилятор C++ сворачивает все эти функции catch и сохраняет только те, которые являются уникальными. В результате размер кода для двоичных файлов, которые в значительной степени зависят от этого шаблона, будет в целом сокращен на 18%. Теперь не только код EH более эффективен, чем использование кодов возврата, но и ушла в прошлое проблема больших двоичных файлов.

Улучшения добавочной сборки

Инструмент cppwinrt.exe теперь сравнивает выходные данные созданного файла заголовка / исходного файла с содержимым любого существующего файла на диске и записывает файл, только если файл действительно изменился. Это значительно экономит время на дисковых операциях ввода-вывода и гарантирует, что компилятор C++ не считает файлы «грязными». В результате во многих случаях повторная компиляция исключается или уменьшается.

Теперь создаются универсальные интерфейсы

Оптимизации компонентов

Универсальная конструкция и прямой доступ к реализации

Эти две оптимизации позволяют вашему компоненту иметь прямой доступ к его собственным типам реализации, даже если он использует только проектируемые типы. Нет необходимости использовать make, make_self или get_self, если необходимо просто использовать общедоступную область API. Ваши звонки будут скомпилированы для прямых звонков в реализацию, они также могут даже быть полностью встроенными.

Затираемые типы фабрик

Умнее и эффективнее module.g.cpp для больших проектов с несколькими библиотеками

Поддержка соподпрограмм

Вот пример поддержки — DispatcherQueue.

Справка по диагностике прямого выделения (выделения стека)

Поскольку имена прогнозируемого класса и класса реализации (по умолчанию) одинаковы и различаются только по пространству имен, можно ошибочно принять одно за другое и случайно создать реализацию в стеке вместо того, чтобы использовать семейство вспомогательных приложений make. В некоторых случаях это может быть трудно диагностировать, потому что объект может быть уничтожен, пока выдающиеся ссылки все еще выполняются. Теперь утверждение выбирает его для отладочных сборок. Хотя утверждение не определяет выделение стека внутри соподпрограммы, тем не менее, оно помогает обнаруживать большинство таких ошибок.

Дополнительные сведения см. в статье Diagnosing direct allocations (Диагностика прямых выделений).

Улучшенные вспомогательные приложения захвата и делегаты variadic

Это обновление устраняет ограничение с помощью вспомогательных приложений захвата, а также поддерживает проектируемые типы. Время от времени это происходит с API взаимодействия среды выполнения Windows, когда они возвращают спроектированный тип.

Это обновление также добавляет поддержку get_strong и get_weak при создании делегата variadic (не для среды выполнения Windows).

Поддержка для отложенного удаления и безопасного QI во время уничтожения

Достаточно часто деструктор для объекта класса среды выполнения вызывает метод, который временно увеличивает значение счетчика ссылок. Когда счетчик ссылок сбрасывается до нуля, объект уничтожается повторно. В приложении XAML вам может потребоваться выполнить в деструкторе QueryInterface (QI), чтобы вызвать определенную реализацию очистки вверх или вниз по иерархии. Но счетчик ссылок объекта уже сбросился до нуля, поэтому QI тоже считается срабатыванием счетчика ссылок.

Это обновление позволяет предотвращать ложные срабатывания счетчика ссылок, гарантируя, что после сбрасывания до нуля его больше невозможно будет восстановить. Так вы сможете выполнять QI для любого временного объекта, который требуется во время уничтожения. Эта процедура неизбежна в некоторых приложениях/элементах управления XAML, и C++/WinRT теперь устойчив к ней.

Вы можете отложить уничтожение, указав статическую функцию final_release в типе реализации. Последний оставшийся указатель на объект в виде std::unique_ptr передается в final_release. После этого вы можете передать владение таким указателем другому контексту. Вы можете использовать метод QI с указателем без вызова двойного уничтожения. Но во время уничтожения объекта чистое изменение счетчика ссылок должно быть равно нулю.

В приведенном ниже примере после освобождения MainPage (для конечного времени) вызывается final_release. Эта функция тратит пять секунд на ожидание (в пуле потоков), а затем возобновляет работу, используя Диспетчер страницы (для работы которого требуется QI/AddRef/Release). Затем она удаляет ресурс в таком потоке пользовательского интерфейса. Наконец, она очищает unique_ptr, что приводит к фактическому вызову деструктора MainPage. Даже в таком деструкторе вызывается DataContext, который требует выполнения QI для IFrameworkElement.

Вам не нужно реализовывать final_release в качестве сопрограммы. Но это работает и позволяет очень просто перенести уничтожение в другой поток, что и происходит в этом примере.

Дополнительные сведения см. в разделе Отложенное удаление.

Улучшено поддержку единого интерфейса наследования в стиле COM

Как и для программирования среды выполнения Windows, C++/WinRT также используется для разработки и использования интерфейсов API только для COM. Это обновление позволяет реализовать COM-сервер, где существует иерархия интерфейса. Это не требуется для среды выполнения Windows; но необходимо для некоторых реализаций COM.

Правильная обработка параметров out

Может быть сложно работать с параметрами out ; особенно массивами среды выполнения Windows. С этим обновлением C++/WinRT значительно более надежный и устойчив к ошибкам, когда речь идет о параметрах и массивах out ; не имеет значения, поступают ли эти параметры через языковую проекцию или от разработчика COM, который использует необработанный ABI и который совершает ошибку, не согласовывая переменные последовательно. В любом случае C++/WinRT теперь поступает правильно, когда дело доходит до передачи проектируемых типов в ABI (не забывая высвобождать любые ресурсы) и когда речь идет об обнулении или очистке параметров, поступающих строку ABI.

События теперь надежно обрабатывают недопустимые токены

Реализация winrt::event теперь корректно обрабатывает регистр, когда его метод remove вызывается с недопустимым значением токена (значением, которого нет в массиве).

Локальные переменные сопрограммы теперь уничтожаются до возвращения сопрограммы

Традиционный способ реализации типа сопрограммы может позволить уничтожение локальных переменных внутри сопрограммы после возврата или завершения выполнения сопрограммы (а не до окончательной приостановки). Возобновление работы любого официанта теперь отложено до окончательного приостановления, чтобы избежать этой проблемы и получить другие преимущества.

Новости и изменения в пакете SDK для Windows версии 10.0.17763.0 (Windows 10, версия 1809)

Таблица ниже содержит новости и изменения для C++/WinRT в пакете SDK для Windows версии 10.0.17763.0 (Windows 10, версия 1809).

Новые или измененные возможности	Дополнительные сведения
Критическое изменение. Для его компиляции C++/WinRT не зависит от заголовков из пакета SDK для Windows.	См. статью Изоляция из файлов заголовков пакета SDK для Windows ниже.
Формат системы проекта Visual Studio изменился.	См. статью Как перенастроить проект C++/WinRT на более позднюю версию пакета SDK для Windows ниже.
Существуют новые функции и базовые классы, которые помогут передать объект коллекции в функцию среды выполнения Windows или реализовать собственные свойства и типы коллекций.	См. раздел Коллекции из C++/WinRT.
Вы можете использовать расширение разметки со своими классами среды выполнения C++/WinRT.	Дополнительные сведения и примеры кода см. в разделе Общие сведения о привязке данных.
Поддержка отмены соподпрограммы позволяет зарегистрировать обратный вызов отмены.	Дополнительные сведения и примеры кода приведены в разделе Отмена асинхронной операции и обратные вызовы отмены.
При создании делегата, указывающего на функцию-член, можно установить сильную или слабую ссылку на текущий объект (вместо необработанного этого указателя) в точке регистрации обработчика.	Дополнительные сведения и примеры кода см. в подразделе Если вы используете функцию-член в качестве подраздела делегата раздела Безопасный доступ кэтому указателю с делегатом с обработкой событий.
Исправлены ошибки, которые были обнаружены улучшенным соответствием Visual Studio стандарту C++. Набор инструментов LLVM и Clang также лучше используется для проверки соответствия стандартам C++/WinRT.	Вы больше не столкнетесь с проблемой, описанной в статье Почему мой новый проект не компилируется? Я использую Visual Studio 2017 (версии 15.8.0 или выше) и пакет SDK версии 17134

Важные изменения были внесены в расширение C++/WinRT Visual Studio (VSIX), как в версии 1.0.181002.2, так и позже в версии 1.0.190128.4. чтобы получить подробные сведения об этих изменениях и их влиянии на существующие проекты, Visual Studio поддержку C++/WinRT и более ранних версий расширения VSIX.

Изоляция из файлов заголовков пакета SDK для Windows

Это — потенциально критическое изменение для кода.

Для его компиляции C++/WinRT больше не зависит от файлов заголовков из пакета SDK для Windows. Файлы заголовков в библиотеке среды выполнения C (CRT) и стандартной библиотеке шаблонов C++ (STL) также не содержат заголовков пакета SDK для Windows. Это улучшает соответствие стандартам, позволяет избежать непреднамеренных зависимостей и значительно уменьшает количество макросов, от которых вы должны защищаться.

Эта независимость означает, что C++/WinRT теперь стал более переносным и совместимым со стандартами, а это расширяет возможности его превращения в кросс-компилятор и кроссплатформенную библиотеку. Это также означает, что заголовки C++/WinRT не оказывают негативного влияния на макросы.

Если вы ранее оставили C++/WinRT для включения любых заголовков Windows в свой проект, то теперь нужно будет включить их самостоятельно. При таких обстоятельствах всегда лучше явно включать заголовки, от которых вы зависите, и не оставлять их для включения в другой библиотеке.

В настоящее время единственными исключениями для изоляции файла заголовка пакета SDK для Windows являются встроенные функции и числовые значения. Нет никаких известных проблем с этими последними оставшимися зависимостями.

В случае необходимости вы можете повторно включить в проекте взаимодействие с заголовками пакета SDK для Windows. Например, вы можете захотеть реализовать интерфейс COM (с корнем в IUnknown). Для этого примера добавьте unknwn.h перед тем, как включать заголовки C++/WinRT. Это приводит к тому, что базовая библиотека C++/WinRT позволяет различным обработчикам поддерживать классические интерфейсы COM. Пример кода см. в разделе Создание компонентов COM с помощью C++/WinRT. Точно так же явно включите любые другие заголовки пакета SDK для Windows, которые объявляют типы и/или функции, которые нужно вызвать.

Как изменить целевую платформу на C++/WinRT проекта до более поздней версии пакета SDK для Windows

Однако есть два других способа перенаправления проекта в Visual Studio.

При возникновении ошибок компилятора или компоновщика после использования любого из этих двух методов можно попробовать очистить решение (создать решение очистки и (или) вручную удалить все временные папки и файлы) перед повторной попыткой сборки.

Если компилятор C++ создает «Error C2039: ‘ IUnknown ‘: не является членом» «глобального пространства имен» «, добавьте в начало pch.h файла (перед включением любых заголовков C++/WinRT).

Если компоновщик C++ создаетошибку LNK2019: неразрешенный внешний символ _WINRT_CanUnloadNow@0 ссылками в функции _VSDesignerCanUnloadNow@0«, это можно разрешить, добавив в pch.h файл.

Источник