Windows desktop runtime что это

Windows Runtime. Система типов и взаимодействие с CLR

С выходом Windows 8 разработчикам стала доступна новая библиотека классов — Windows Runtime. Компоненты WinRT могут использоваться в приложениях Windows Store и настольных приложениях; в неуправляемом коде C/C++, в JavaScript, а также в C# и Visual Basic.

Метаданные Windows Runtime

На внутреннем уровне компоненты WinRT представляют собой компоненты COM (Component Object Model), для описания API которых теперь используются метаданные. Эти метаданные хранятся в файлах с расширением *.winmd и представляют собой обновленную версию метаданных .NET, которые кодируются в соответствие с правилами раздела №2 (Metadata Definition and Semantics) стандарта ECMA-335. Поскольку обычные сборки .NET Framework кодируются с помощью этого же стандарта, это говорит о том, что вы можете использовать знакомые средства (такие как ildasm.exe, Object Browser) для просмотра содержимого этих файлов.
По большей части, просмотр WinMD файла с помощью утилиты ildasm.exe очень похож на просмотр стандартной управляемой сборки. Есть несколько различий, которые могут быть видны — в первую очередь то, что WinMD файлы, в общем, не содержат никаких Intermediate Language (IL) инструкций. Вместо этого, эти файлы описывают API, предоставляемые Windows Runtime. Реализация этих интерфейсов может быть полностью отделена от их определения, и по сути, может быть записана в машинном коде. Тем не менее, для разработчиков управляемых приложений, детали реализации WinRT API не имеют значения, потому что управляемый код должен видеть только определения API, которые он вызывает. За кулисами, Common Language Runtime (CLR) и операционная система Windows соединяют для вас определения API и их реализации.

Например, в файле метаданных Windows.Foundation.winmd (находится в каталоге %WinDir%\System32\WinMetadata) вы можете обнаружить следующий тип Windows.Foundation.Collections.PropertySet, конструктор которого не содержит тела, потому что тип реализуется в native code.

Тем не менее, метаданные, которые описывают этот тип позволяют CLR получить экземпляр реализации при вызове конструктора класса.
При просмотре Windows Runtime метаданных можно также заметить, что определения типов и сборок используют новое ключевое слово WindowsRuntime.

Это ключевое слово является контекстно-зависимым и по разному интерпретируется в зависимости от того, где оно применяется. Например, если ключевым словом помечено определение типа (TypeDef), то этот тип подчиняется правилам системы типов Windows Runtime и вызов этого типа следует рассматривать как вызов WinRT API.

Взаимодействие CLR с компонентами WinRT

CRL поддерживает взаимодействие с COM-компонентами через обертки Runtime Callable Wrapper (RCW) и COM Callable Wrapper (CCW). Таким образом в CLR ссылка на WinRT объект представляет собой ссылку на RCW, которая в свою очередь содержит ссылку на WinRT объект. Соответственно управляемый код взаимодействует с RCW, который по сути является интерфейсом между вашим кодом и WinRT объектом.

Аналогичным образом в Windows Runtime ссылка на объект CLR представляет собой ссылку на CCW, которая в свою очередь содержит ссылку на CLR объект. Windows Runtime при этом взаимодействует с CCW для доступа к функциональности управляемого объекта.

WinRT типы и управляемый код

Основные типы данных, которые кодируются в метаданных с применением того же перечисления ELEMENT_TYPE что и в управляемых сборках. Исключением является тип SByte, который не поддерживается в WinRT.
Проецируемые типы (mapped types), которые кодируются в WinMD файлах как одни типы, но появляются в управляемом коде как их .NET эквиваленты. Например, когда CLR считывает в метаданных тип Windows.Foundation.Uri, вместо него она использует тип System.Uri. То есть CLR скрывает тип WinRT и предоставляет доступ к нему через другой тип. Кроме того CLR маршалирует тип между управляемым и неуправляемым кодом, что позволяет передавать объект System.Uri в Windows Runtime как Windows.Foundation.Uri. Полный список WinRT типов, которые CLR проецирует на типы FCL можно найти здесь.
Все остальные типы. Подавляющее большинство типов WinRT API предоставляются .NET разработчикам как есть. Например, если вы используете класс Windows.UI.Xaml.Controls.Button, CLR не предоставляет специальное представление или маршалинг это типа. В эту категорию также включаются типы, для которых среда CLR предоставляет методы расширения. Например, чтобы использовать объект, реализующий WinRT интерфейс Windows.Storage.IInputStream, с классом .NET Framework, которому необходим тип, производный от System.IO.Stream, следует задействовать методы расширения, которые определены в классе System.IO.WindowsRuntimeStreamExtensions сборки System.Runtime.WindowsRuntime.dll.

Проецирование типов

CLR определяет Windows Runtime тип как частный (private), а не общедоступный (public). Это препятствует тому, чтобы исходный тип был виден управляемому коду. Т.е. с точки зрения управляемого кода единственный тип, который существует — это .NET Framework тип, который является целью отображения.
Все ссылки на исходный тип преобразуются в ссылки на целевой .NET Framework тип.

Базовый тип

Компоненты WinRT не имеют общего базового класса, однако все классы среды выполнения Windows должны реализовывать интерфейс IInspectable, который в свою очередь наследует от интерфейса IUnknown (что не удивительно). Однако, для .NET разработчиков все WinRT типы выглядят как типы производные от System.Object и соответственно наследуют такие методы как Equals, GetHashCode и т.д. Это становится возможным благодаря тому, что CLR осуществляет маршалинг объектов во время выполнения для преобразования типов между WinRT и .NET представлениями.

Структуры

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

К тому же, структуры WinRT не могут определять конструкторы или содержать вспомогательные методы. Однако, некоторые структуры CLR, для удобства, проецирует на свои собственные, тем самым предоставляя разработчикам вспомогательные методы и конструкторы. К таким относятся, например, структура Windows.Foundation.Point, Windows.Foundation.Size и Windows.Foundation.Rect.

Строки

Тип System.String в WinRT представляется как HSTRING. Когда вы вызываете метод среды выполнения Windows, CLR преобразовывает любую .NET Framework строку в HSTRING перед вызовом метода. Аналогично, CLR преобразовывает любые строки, возвращенные из метода среды выполнения в тип System.String. Есть еще одна особенность — система типов WinRT не разрешает строкам принимать значение null. Вместо null для передачи пустой строки следует использовать String.Empty. При попытке передать null в качестве строки в WinRT функцию, CLR выдаст исключение ArgumentNullException. Точно так же вы никогда не увидите, что WinRT функция может вернуть null-строку, это может быть только пустая строка.

Null-совместимые типы

В WinRT API для определения null-совместимого значимого типа используется интерфейс Windows.Foundation.IReference<T>, который CLR проецирует на свой собственный System.Nullable<T>. Например, если метод в файле WinMD имеет следующую сигнатуру:

то в управляемом коде этот метод будет выглядеть следующим образом:

Делегаты

В качестве типа параметра или возвращаемого значения делегата WinRT могут использовать только WinRT-совместимые типы. Так же делегаты с глобальной (public) областью видимости не могут быть объявлены как вложенные (на самом деле это общие правила для среды выполнения Windows в целом). Когда вы передаете объект делегата компоненту Windows Runtime, этот объект упаковывается в обертку CCW, которая не уничтожается сборщиком мусора до тех пор, пока она не будет освобождена компонентом, который ее использует. Интересен так же тот факт, что делегаты WinRT не имеют методов BeginInvoke и EndInvoke.

События

Компоненты WinRT могут определять события, используя только типы делегатов WinRT. Существует тип делегата Windows.Foundation.EventHandler<T>, который CLR проецирует на тип делегата .NET Framework System.EventHandler<TEventArgs>. Когда вы определяете член-событие:

то при компиляции этой строки кода, компилятор превращает ее в следующие инструкции:

Как и прежде, компилятор создает закрытое поле и два метода-аксессора для регистрации и отказа от подписки на событие. Однако тип поля и содержание этих методов отличается от того, к чему мы привыкли (Delegate.Combine и Delegate.Remove). В качестве типа поля используется обобщенный класс EventRegistrationTokenTable<T>, аргументом типа которого является соответствующий тип делегата. Этот класс отвечает за хранения цепочки делегатов, которые представляют обработчики события. При добавлении нового обработчика, возвращается токен EventRegistrationToken, который может использоваться в дальнейшем для удаления обработчика события.

Для того, чтобы вызывать событие, следует воспользоваться свойством InvocationList, возвращающее делегат, список вызовов которого включает в себя все делегаты, добавленные в качестве обработчиков события.

Время и дата

В WinRT время и дата представляются в формате UTC структурой Windows.Foundation.DateTime. CLR проецирует данный тип на структуру System.DateTimeOffset, а не на System.DateTime. Стоит заметить, что DateTime не содержит информацию о часовом поясе. Поэтому дата и время, возвращаемые функциями WinRT в формате UTC, CLR преобразует в локальное время. И наоборот, при передаче структуры DateTimeOffset в WinRT функцию, дата и время преобразуются в UTC формат.

Массивы

WinRT API поддерживает только одномерные массивы. Соответственно следующий код вызовет ошибку времени компиляции:

В управляемом коде массивы передаются по ссылке, при этом изменения элементов массива будут видны любому коду, который имеет ссылку на экземпляр этого массива. Однако, для WinRT это не всегда так, потому что содержимое массива маршалируется только в направлении, которое API определяет в своей сигнатуре, используя System.Runtime.InteropServices.InAttribute и System.Runtime.InteropServices.OutAttribute. Оба атрибута применяются к параметрам метода или возвращаемым значениям и определяют направление маршалинга между управляемой и неуправляемой памятью во время выполнения. В Windows Runtime параметры могут быть либо только для чтения [InAttribute], либо только для записи [OutAttribute] и не могут быть отмечены для чтения и записи одновременно [InAttribute], [OutAttribute]. Это означает, что содержимое массива, передаваемого методу, а также сам массив должны быть предназначены для чтения или для записи. Так, содержимое массива, который помечен атрибутом [InAttribute], копируется в вызываемый метод, поэтому все изменения, которые метод применяет к массиву, не видны вызывающему объекту. Аналогично, содержимое массива, который помечен атрибутом [OutAttribute], устанавливается вызываемым методом и копируется в вызывающий объект, поэтому вызываемый метод не должен делать каких-либо предположений о содержимом исходного массива.

Коллекции

При передачи коллекции CLR упаковывает объект коллекции в обертку CCW и передает ссылку на нее в WinRT API. При этом вызовы через обертку пересекают границу взаимодействия, что отрицательно сказывается на производительности. Однако, в отличие от массивов, возможно выполнение операций без копирования элементов.

Что такое microsoft windows desktop runtime

Национальная библиотека им. Н. Э. Баумана
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.

Модель приложений Windows Runtime

Что такое microsoft windows desktop runtime Наша жизнь наполнена абстракциями. Как разработчики мы часто вынуждены бороться со всяческими проблемами, используя абстракции, о которых мы по большому счету ничего не знаем. Абстракции иногда разваливаются и оказываются не в состоянии полностью скрыть нижележащие сложности. Не поймите меня неправильно, абстракции — великая вещь. Они помогают и пользователям, и разработчикам, но вы здорово облегчите себе жизнь, если вникнете в те абстракции, на которые вы регулярно опираетесь в своей работе, и четко поймете, как именно они действуют. Более того, библиотеки, авторы которых приняли эту реальность, зачастую куда успешнее тех, где этого не сделано, и отчасти это связано с тем, что такие библиотеки позволяют входить в абстракцию при пошаговой отладке, если в том возникает необходимость.

Одна из таких абстракций — Windows Runtime (WinRT), и сегодня я собираюсь проиллюстрировать это, рассмотрев базовую модель приложений WinRT. Она построена вокруг класса CoreWindow, экземпляр которого находится внутри каждого «современного» приложения Windows Store и Windows Phone. Тем не менее, сравнительно немногие знают о его существовании, и еще меньше, как он работает. Видимо, это можно считать критерием успеха абстракции.

Со времени первого объявления Windows 8 API в 2011 году многое было сказано и написано о различных языковых проекциях, предоставляющих абстракцию над Windows Runtime. Однако лучший способ понять Windows Runtime — отказаться от языковых проекций, включая C++/CX, и использовать стандартный C++ в сочетании с традиционной COM. Только C++ позволяет раздвинуть плотные шторы и увидеть, что происходит на самом деле (с технической точки зрения, то же самое можно сделать и на C, но это было бы излишне болезненно). Возможно, вы все равно предпочтете использовать ту или иную языковую проекцию (скорее всего, C++/CX), но по крайней мере у вас будет гораздо более четкое понимание происходящего.

Для начала откройте Visual Studio 2012 и создайте новый проект Visual C++ для приложения Windows Store или Windows Phone. Не важно, какой шаблон вы используете. Как только он загрузится, перейдите в Solution Explorer и удалите все, что не существенно. Если вы выбрали шаблон на основе XAML, удалите все XAML-файлы. Вы также можете удалить все файлы исходного кода на C++. Вероятно, вы предпочтете сохранить предкомпилированный заголовочный файл, но обязательно удалите все его содержимое. У вас должны остаться лишь ресурсы пакета, необходимые для развертывания приложения, изображения, сертификата и XML-манифеста.

Затем откройте страницы свойств проекта и выберите свойства компилятора — узел C/C++ в дереве слева. Найдите строку для ключа компилятора /ZW — Consume Windows Runtime Extension — и укажите No, чтобы отключить языковые расширения C++/CX. Тем самым вы будете уверены, что ничего загадочного, помимо мистических чудес стандартного компилятора C++, не происходит. Там же установите уровень предупреждений компилятора /W4.

Если вы попробуете скомпилировать проект, то должны увидеть приветствие от компоновщика, который сообщает об ошибке из-за того, что не удалось найти функцию точки входа в проект — WinMain. Добавьте в проект новый файл исходного кода на C++ и первым делом поместите в него недостающую функцию WinMain:

Как видите, это традиционная функция WinMain для Windows-приложения на основе C Runtime Libraries (CRT). Конечно, HINSTANCE и PWSTR не являются фундаментальными типами C++, поэтому вам придется включить заголовочный файл windows.h:

Если вы сохранили предкомпилированный заголовочный файл проекта, то можете включить его здесь. Я также буду использовать ComPtr из Windows Runtime C++ Template Library (WRL), поэтому сейчас самое время включить и его:

Подробнее о WRL я буду рассказывать в следующих статьях из этой рубрики. А пока я буду просто использовать шаблон класса ComPtr для поддержки указателя на COM-интерфейс. На этом этапе достаточно знать, что WRL ComPtr — это просто смарт-указатель на COM-интерфейс. Хотя он предоставляет некоторые средства, уникальные для Windows Runtime, я не стану использовать их в этот раз. С тем же успехом вы могли бы задействовать CComPtr из Active Template Library (ATL) или любой другой смарт-указатель на COM-интерфейс по своему выбору. WRL ComPtr определен в пространстве имен Microsoft::WRL:

Я также буду использовать макрос ASSERT и функцию HR для обработки ошибок. Об этом я уже говорил, поэтому не буду повторяться. Если вы не уверены в этих этапах, прочитайте мою статью в этой рубрике за май 2013 г. «Introducing Direct2D 1.1» (msdn.microsoft.com/magazine/dn198239).

Первое, что ожидает модель приложений, — MTA (multithreaded apartment). Правильно, в ней находится COM-модель изоляции потоков (COM apartment model). Windows Runtime предоставляет функцию RoInitialize, которая является тонкой оболочкой CoInitializeEx:

Несмотря на тот факт, что обычно достаточно CoInitializeEx, я предлагаю вам использовать RoInitialize. Эта функция позволит поддерживать будущие усовершенствования в Windows Runtime без потенциальной угрозы поломать традиционную COM. Она аналогична OleInitialize, которая тоже вызывает CoInitializeEx и кое-что еще. Смысл в том, чтобы в основном потоке вашего приложения не было ничего загадочного. Единственное, что может слегка удивить, — это не STA (single-threaded apartment). Не волнуйтесь, окно вашего приложения по-прежнему будет выполняться в STA-потоке, но создавать его будет Windows Runtime. Эта STA — на самом деле Application STA (ASTA), и она немного отличается от чистой STA, но об этом позже.

WindowsCreateString выделяет достаточно памяти для хранения копии исходной строки и null-символа, завершающего строку, а затем копирует исходную строку в этот буфер. Чтобы освободить этот вспомогательный буфер, вы должны вызвать WindowsDeleteString, если только владелец строки не возвращается в вызвавшую функцию:

Располагая HSTRING, вы можете получить указатель на вспомогательный буфер этой строки с помощью функции WindowsGetStringRawBuffer:

Необязательный второй параметр возвращает длину строки. Длина хранится вместе со строкой, избавляя вас от необходимости сканировать строку, чтобы определить ее размер. Прежде чем вы начнете строчить класс-оболочку для C++, стоит отметить, что компилятор C++/CX не возится с WindowsCreateString и WindowsDeleteString при генерации кода для строкового литерала или массива const. Вместо них он использует так называемую быстро передаваемую строку (fast-pass string), позволяющую избегать дополнительных операций выделения памяти и копирования, о которых недавно упоминал. Кроме того, это исключает риск утечки памяти. Создается быстро передаваемая строка функцией WindowsCreateStringReference:

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

RoGetActivationFactory — как раз такая функция, и она используется для получения фабрики активации или статического интерфейса для данного класса. Она аналогична COM-функции CoGetClassObject. Учитывая, что эта функция обычно применяется с массивом const, генерируемым компилятором MIDL, имеет смысл написать простой шаблон-функцию, предоставляющий оболочку быстро передаваемой строки. Как он может выглядеть, показано на рис. 1.

Рис. 1. Шаблон функции GetActivationFactory

Шаблон функции GetActivationFactory автоматически распознает длину строки, исключая необходимость передачи аргумента с длиной буфера (а здесь легко ошибиться) или весьма дорогостоящего сканирования строки в период выполнения. Затем перед вызовом функции RoGetActivationFactory подготавливает быстро передаваемую строку. И здесь шаблон функции вновь логически распознает идентификатор интерфейса и безопасно возвращает конечный указатель на COM-интерфейс, обернутый в WRL ComPtr.

Теперь вы можете использовать эту вспомогательную функцию для получения интерфейса ICoreApplication:

Интерфейс ICoreApplication — это то, что приводит в действие ваше приложение. Чтобы использовать этот COM-интерфейс, вам потребуется включить заголовочный файл модели приложений:

Этот заголовочный файл определяет ICoreApplication в пространстве имен ABI::Windows::ApplicationModel::Core, а также текстовый идентификатор класса CoreApplication. Единственный метод интерфейса, над которым вам придется хорошенько подумать, — это Run.

Прежде чем продолжить, было бы полезно оценить, как Windows Runtime выводит ваше приложение в свет, если так можно выразиться. Как уже упоминалось, Windows Runtime считает вас просто гостем в вашем процессе. Тут полная аналогия с тем, как годами работали Windows-службы. В случае Windows-службы Windows Service Control Manager (SCM) запускает ее, используя функцию CreateProcess или одну из ее вариаций. Затем ждет, когда процесс вызовет функцию StartServiceCtrlDispatcher. Эта функция устанавливает обратную связь с SCM, благодаря чему служба и SCM могут взаимодействовать друг с другом. Если, например, службе не удастся своевременно вызвать StartServiceCtrlDispatcher, SCM будет считать, что возникла какая-то ошибка, и уничтожит процесс. Функция StartServiceCtrlDispatcher возвращает управление только по окончании работы службы, поэтому SCM нужно создавать дополнительный поток для службы, чтобы принимать уведомления об обратных вызовах. Служба просто реагирует на события и находится полностью во власти SCM. Как вы увидите, это во многом напоминает модель приложений WinRT.

Windows Runtime ждет от процесса получения интерфейса ICoreApplication и вызова его метода Run. Если процессу не удается своевременно сделать это, Windows Runtime подобно SCM считает, что что-то пошло не так и завершает процесс. К счастью, если к процессу подключен отладчик, Windows Runtime обнаруживает это и отключает тайм-аут — в отличие от SCM. Однако модель та же. Windows Runtime контролирует процесс и, когда происходят какие-то события, вызывает приложение в потоке, созданном исполняющей средой. Конечно, Windows Runtime основана на COM, поэтому вместо функции обратного вызова (как в случае SCM) эта исполняющая среда (которая в этом деле опирается на Process Lifetime Manager [PLM]) ожидает, что приложение предоставит метод Run с COM-интерфейсом, который можно использовать для вызова приложения.

Ваше приложение должно предоставить реализацию IFrameworkViewSource, который также находится в пространстве имен ABI::Windows::ApplicationModel::Core, и тогда CoreApplication вызовет его единственный метод CreateView, как только создаст UI-поток вашего приложения. На самом деле в IFrameworkViewSource содержится не только метод CreateView. Этот интерфейс наследует от IInspectable, базового интерфейса WinRT. В свою очередь IInspectable наследует от IUnknown, базового интерфейса COM.

WRL обеспечивает обширную поддержку реализации COM-классов, но об этом мы поговорим в следующей статье. А пока я хочу подчеркнуть, что корни Windows Runtime уходят в COM и что нет лучшего способа показать это, чем реализовать IUnknown. Для моих целей будет полезным отметить, что срок жизни C++-класса, который реализует IFrameworkViewSource и несколько других интерфейсов, определяется стеком. По сути, функция WinMain приложения сводится к следующему:

Остается лишь написать класс SampleWindow так, чтобы он должным образом реализовал интерфейс IFrameworkViewSource. Хотя CoreApplication безразлично, где реализуются интерфейсы, ваше приложение, как минимум, должно реализовать не только IFrameworkViewSource, но и интерфейсы IFrameworkView и IActivatedEventHandler. В данном случае класс SampleWindow может просто реализовать их всех:

Интерфейс IFrameworkView также определен в пространстве имен ABI::Windows::ApplicationModel::Core, а с IActivatedEventHandler дело обстоит несколько сложнее. Я определил его сам таким образом:

Если у вас есть некоторый опыт работы с COM, вы могли подумать, что это выглядит весьма не ортодоксально, — и были бы правы. Как и следовало бы ожидать, ITypedEventHandler — это просто шаблон класса, и довольно странно так определять COM-интерфейс; самая очевидная проблема в том, что вы, по-видимому, не смогли бы узнать, каким идентификатором интерфейса нужно его пометить. К счастью, все эти интерфейсы генерируются компилятором MIDL, который берет на себя задачу специализации каждого из них, и этим специализациям он назначает GUID, представляющий идентификатор интерфейса. Каким бы сложным ни выглядело предыдущее выражение typedef, оно определяет COM-интерфейс, который наследует непосредственно от IUnknown и предоставляет единственный метод — Invoke.

Я должен реализовать несколько методов интерфейсов, поэтому займемся делом. Первым идет IUnknown и его могущественный метод QueryInterface. Я не хочу тратить здесь слишком много времени на IUnknown и IInspectable, так как подробно опишу их в следующей статье. На рис. 2 приведена простая реализация QueryInterface для класса, основанного на стеке.

Рис. 2. Метод QueryInterface в SampleWindow

В этой реализации стоит отметить несколько моментов. Прежде всего, метод проверяет, что его аргументы допустимы. Более политкорректная реализация могла бы возвращать E_POINTER, но предполагается, что такие ошибки являются дефектами, которые можно устранить на этапе разработки, поэтому незачем тратить на них лишние процессорные ресурсы в период выполнения. Это обеспечивает наилучшее из возможных поведение, немедленно вызывая ошибку доступа к памяти и создавая аварийный дамп, который довольно легко проанализировать. Если бы вы возвращали E_POINTER, вызвавший дефектный код скорее всего просто проигнорировал бы это. Поэтому лучшая политика — провал на раннем этапе. По сути, такой позиции придерживаются во многих реализациях, включая DirectX и Windows Runtime. Корректная реализация QueryInterface требует уймы усилий. Спецификация COM весьма требовательна к тому, чтобы COM-классы всегда корректно и согласованно обеспечивали определенные гарантии идентификации объектов. Не волнуйтесь, если цепочка выражений if кажется вам устрашающей. В свое время я расскажу и об этом.

И последнее, на что хотелось бы обратить внимание в этой реализации, — она не вызывает AddRef. Обычно перед возвратом управления QueryInterface должен вызывать AddRef применительно к полученному указателю на интерфейс IUnknown. Однако, так как класс SampleWindow находится в стеке, смысла в учете ссылок нет. По той же причине реализация IUnknown-методов AddRef и Release предельно проста:

Результаты этих методов имеют лишь информационный характер, поэтому вы можете использовать преимущество этого факта, и вас устроит любое ненулевое значение. Здесь я должен предупредить вас: возможно, вам понадобится переопределить операторы new и delete, чтобы явным образом указывать на то, что данный класс рассчитан на работу только в стеке. В качестве альтернативы вы могли бы реализовать учет ссылок — так, на всякий случай.

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

Рис. 3. IInspectable-методы в SampleWindow

Далее я должен реализовать IFrameworkViewSource и его метод CreateView. Поскольку класс SampleWindow тоже реализует IFrameworkView, реализация проста. И вновь заметьте, что обычно перед возвратом управления вы должны были бы вызывать AddRef применительно к полученному указателю на интерфейс, производный от IUnknown. Возможно, вы предпочтете на всякий случай вызывать AddRef в теле этой функции:

Интерфейс IFrameworkView — то место, где наконец начинают происходить интересные вещи. После вызова CreateView из приложения для получения указателя на этот интерфейс Windows Runtime вызывает большинство его методов в быстрой последовательности. Важно так же быстро реагировать на эти вызовы, так как все они засчитываются в тот период времени, в течение которого пользователь ожидает запуска вашего приложения. Первым вызывается Initialize, и в нем приложение должно регистрироваться на событие Activated. Это событие уведомляет, что приложение активировано, но вы сами должны активировать его CoreWindow. Метод Initialize довольно прост:

Затем вызывается метод SetWindow, который предоставляет приложению реализацию ICoreWindow, который просто моделирует обычный HWND рабочего стола в Windows Runtime. В отличие от остальных интерфейсов модели приложений ICoreWindow определен в пространстве имен ABI::Windows::UI::Core. В методе SetWindow обязательно делайте копию указателя на интерфейс, так как достаточно скоро он вам понадобится:

Следующий метод — Load; в нем вы должны собрать весь код, отвечающий за подготовку вашего приложения к начальному отображению:

Как минимум, вы должны регистрироваться на события, относящиеся к изменениям размера окна и видимости, а также к изменениям в масштабировании DPI (dots per inch). Кроме того, вы, вероятно, захотите воспользоваться возможностью создать различные объекты фабрики DirectX, загрузить аппаратно-независимые ресурсы и т. д. Это хорошее место для выполнения всех таких операций по той причине, что в этот момент пользователь видит экран-заставку вашего приложения.

Когда метод Load возвращает управление, Windows Runtime считает, что ваше приложение готово к активации, и генерирует событие Activated, которое я буду обрабатывать, реализовав метод Invoke интерфейса IActivatedEventHandler примерно так:

После активации окна приложение наконец готово к выполнению:

Реализовать это можно разными способами. Здесь я просто получаю интерфейс ICoreDispatcher окна, который представляет цикл прокачки сообщений (message pump) для этого окна. Наконец, существует метод Uninitialize, который мог бы вызываться время от времени, но в остальном бесполезен, и его можно безопасно игнорировать:

Вот и все. Теперь вы можете скомпилировать и запустить приложение. Конечно, в данном случае на экране ничего рисоваться не будет. Можете взять копию dx.h с сайта dx.codeplex.com и начать добавлять Direct2D-код для рендеринга (подробности см. в моей статье «A Modern Library for DirectX Programming» в этой рубрике за июнь 2013 г. по ссылке msdn.microsoft.com/magazine/dn201741) или дождаться следующей статьи, где я покажу, как лучше всего интегрировать Direct2D с базовой моделью приложений WinRT.

Кенни Керр (Kenny Kerr) — высококвалифицированный программист. Живет в Канаде. Автор учебных курсов для Pluralsight, обладатель звания Microsoft MVP. Ведет блог kennykerr.ca Кроме того, читайте его заметки в twitter.com/kennykerr.

Выражаю благодарность за рецензирование статьи эксперту Microsoft Джеймсу Макнеллису (James McNellis).

Microsoft Windows desktop runtime что это за программа и нужна ли она

5 способов исправления высокой нагрузки процессом NET Runtime Service

Хотите узнать причину высокой загрузки ЦП, когда вы открываете диспетчер задач и видите службу с именем .NET Runtime Optimization Service, потребляющую много ресурсов ЦП? Что ж, не беспокойтесь – мы нашли решения вашей проблемы.

В этой статье мы обсудим, что такое ошибка .NET framework, причины проблемы и 5 лучших способов исправить ошибку .NET Runtime Optimization.

Что такое служба NET Runtime Optimization

Служба оптимизации времени выполнения, известная как Mscorsvw.exe, используется для быстрого запуска приложений. Как правило, этот процесс не потребляет слишком много памяти. Но, если процесс оптимизации занимает много времени, это может привести к высокой загрузке ЦП.

Вот список распространенных причин, из-за которых вы можете столкнуться с высокой загрузкой процессора службой .NET Runtime Optimization Service в Windows.

Зараженная система. Это означает, что в вашей системе может работать вредоносное ПО, которое скрывается под именем службы .NET Runtime. Чтобы исправить это, рекомендуется использовать антивирусное решение
Повреждена служба Runtime Optimization .NET
Служба Runtime Optimization .NET слишком медленно работает на вашем ПК

Способы исправить высокую загрузку ЦП

Если вы считаете, что лучше всего завершить процесс, позвольте мне сказать, что это не поможет, потому что процесс помогает запускать приложения и игры. Это может даже нанести вред работе системы. Но, беспокоиться не о чем, есть другие способы исправить это. Здесь мы объясним их все по порядку.

Microsoft Window Desktop Runtime .NET 5.0 | How to FiX | Easy Step

Оптимизация NET Runtime Service

Как объяснялось выше, когда служба работает медленно, вы столкнётесь с высокой загрузкой процессора службой оптимизации времени выполнения .NET в Windows.

Чтобы ускорить процесс, нам нужно выполнить следующие команды:

Запустите командную строку от имени администратора.
Введите следующие команды:
Для 32-битных систем: cd C:WindowsMicrosoft.NETFrameworkv4.0.30319
Для 64-битных систем: cd C:WindowsMicrosoft.NETFramework64v4.0.30319

Примечание. Буква C обозначает диск, на котором установлена операционная система. Если она установлена на другом диске, замените её.

Это должно помочь, поскольку команды инструктируют службу .NET на использование всех доступных ядер.

В случае, если это не сработает, вы можете перейти к следующему решению.

Просканируйте систему на наличие инфекций

Ещё одна важная причина высокой загрузки ЦП процессом .NET Runtime Optimization Service – заражение вредоносным ПО.

Ошибка To run this application,you must install .NET.-The framework WindowsDesktop.App was not found

Чтобы решить эту проблему, рекомендуется использовать антивирусное программное обеспечение. Запустите глубокое сканирование и дождитесь результатов.

Запустите официальный скрипт Microsoft

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

Чтобы запустить его, выполните следующие действия:

Посетите GitHub для получения официального скрипта или щелкните здесь
Щелкните правой кнопкой мыши кнопку Raw → выберите Сохранить ссылку как
При сохранении убедитесь, что тип файла – Windows Script File.
Далее запускаем скрипт.
Когда вас попросят выбрать программу, выберите Windows Script Host.

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

Если это не помогает, перейдём к следующему шагу.

Перезапустите службу NET Runtime Optimization

Высокая загрузка процессора, вызванная mscorsvw.exe, может быть устранена перезапуском службы.

Чтобы сделать это, выполните следующие действия:

Нажмите Win + R
Введите services.msc и нажмите OK .
Перейдите к NVIDIA Telemetry Container → щелкните правой кнопкой мыши → Свойства.
Щелкните стрелку вниз рядом с полем «Тип запуска» и выберите «Автоматически» → «Применить» → «ОК».

Теперь перейдите в диспетчер задач, вы больше не должны видеть высокую загрузку ЦП службой NET Runtime.

Однако, если и это не помогло, попробуем выполнить чистую загрузку.

Выполните чистую загрузку Windows

Чтобы выполнить эту задачу, выполните следующие действия:

Нажмите Win + R
Введите msconfig → ОК .
Перейдите на вкладку Службы → установите флажок Не отображать службы Microsoft → затем нажмите Отключить все → ОК .
Вам будет предложено перезагрузить компьютер или сделать это позже. Выберите «Перезагрузить позже».
Откройте «Диспетчер задач» – для этого нажмите Ctrl + Shift + Esc .
Поочередно выберите элементы автозагрузки, которые считаете ненужными → щелкните правой кнопкой мыши → Завершить задачу.
Теперь перезапустите систему и проверьте, решена ли проблема.

Это должно помочь решить проблему.

Ошибка службы оптимизации .NET – частый вопросы

Нужна ли мне служба оптимизации времени выполнения .NET?

Поскольку это служба компонентов Windows, используемая для более быстрого запуска приложений и выполнения программ. Следует сохранить .NET Runtime Optimization Service активной.

Могу ли я отключить службу оптимизации времени выполнения .NET?

Мы не рекомендуем отключать сервис. Однако, если вы столкнулись с высокой загрузкой ЦП из-за этого, вы можете оптимизировать её с помощью команды или можете просканировать систему на предмет заражения, используя антивирус для Windows.

Что представляет собой служба NET Runtime Optimization и mscorsvw.exe?

Mscorsvw.exe – это компонент Windows, используемый для оптимизации компьютеров и более быстрого запуска приложений.

Мы надеемся, что, применив исправления, описанные в этом посте, вы сможете исправить проблему высокой загрузки ЦП службой оптимизации времени выполнения .NET в Windows.

Windows Runtime. Система типов и взаимодействие с CLR

Метаданные Windows Runtime

Реализация этих интерфейсов может быть полностью отделена от их определения, и по сути, может быть записана в машинном коде. Тем не менее, для разработчиков управляемых приложений, детали реализации WinRT API не имеют значения, потому что управляемый код должен видеть только определения API, которые он вызывает. За кулисами, Common Language Runtime (CLR) и операционная система Windows соединяют для вас определения API и их реализации.

Например, в файле метаданных Windows.Foundation.winmd (находится в каталоге %WinDir%System32WinMetadata) вы можете обнаружить следующий тип Windows.Foundation.Collections.PropertySet, конструктор которого не содержит тела, потому что тип реализуется в native code.

Взаимодействие CLR с компонентами WinRT

Windows desktop runtime что это

Windows Runtime. Система типов и взаимодействие с CLR

Метаданные Windows Runtime

Взаимодействие CLR с компонентами WinRT

WinRT типы и управляемый код

Основные типы данных, которые кодируются в метаданных с применением того же перечисления ELEMENT_TYPE что и в управляемых сборках. Исключением является тип SByte, который не поддерживается в WinRT.
Проецируемые типы (mapped types), которые кодируются в WinMD файлах как одни типы, но появляются в управляемом коде как их .NET эквиваленты. Например, когда CLR считывает в метаданных тип Windows.Foundation.Uri, вместо него она использует тип System.Uri. То есть CLR скрывает тип WinRT и предоставляет доступ к нему через другой тип. Кроме того CLR маршалирует тип между управляемым и неуправляемым кодом, что позволяет передавать объект System.Uri в Windows Runtime как Windows.Foundation.Uri. Полный список WinRT типов, которые CLR проецирует на типы FCL можно найти здесь.
Все остальные типы. Подавляющее большинство типов WinRT API предоставляются .NET разработчикам как есть. Например, если вы используете класс Windows.UI.Xaml.Controls.Button, CLR не предоставляет специальное представление или маршалинг это типа. В эту категорию также включаются типы, для которых среда CLR предоставляет методы расширения. Например, чтобы использовать объект, реализующий WinRT интерфейс Windows.Storage.IInputStream, с классом .NET Framework, которому необходим тип, производный от System.IO.Stream, следует задействовать методы расширения, которые определены в классе System.IO.WindowsRuntimeStreamExtensions сборки System.Runtime.WindowsRuntime.dll.

Проецирование типов

CLR определяет Windows Runtime тип как частный (private), а не общедоступный (public). Это препятствует тому, чтобы исходный тип был виден управляемому коду. Т.е. с точки зрения управляемого кода единственный тип, который существует — это .NET Framework тип, который является целью отображения.
Все ссылки на исходный тип преобразуются в ссылки на целевой .NET Framework тип.

Базовый тип

Структуры

Строки

Null-совместимые типы

то в управляемом коде этот метод будет выглядеть следующим образом:

Делегаты

События

то при компиляции этой строки кода, компилятор превращает ее в следующие инструкции:

Время и дата

Массивы

Коллекции

Name already in use

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

.NET Windows Desktop Runtime

This repo contains the code to build the .NET Windows Desktop Runtime for all supported platforms.

How to Engage, Contribute and Provide Feedback

Some of the best ways to contribute are to try things out, file bugs, join in design conversations, and fix issues.

This repo defines contributing guidelines and also follows the more general .NET Core contributing guide.
If you have a question or have found a bug, file an issue.

Reporting security issues and security bugs

Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) secure@microsoft.com. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the Security TechCenter.

.NET Framework issues

Issues with .NET Framework should be filed on VS developer community, or Product Support. They should not be filed on this repo.

Code of Conduct

This project uses the .NET Foundation Code of Conduct to define expected conduct in our community. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project maintainer at conduct@dotnetfoundation.org.

.NET Core (including the WindowsDesktop repo) is licensed under the MIT license.

WinRT — разработка приложений под Windows 8

XYZ School

В целом система Windows 8 рассчитана на тот же класс персональных компьютеров, что и Windows 7, то есть на машины на базе 32- или 64-разрядных микропроцессоров Intel х86. Система существует в обычном издании, называемом просто «Windows 8», и в издании «Windows 8 Pro» с дополнительными возможностями, ориентированными на квалифицированных энтузиастов и профессионалов. Как в Windows 8, так и в Windows 8 Pro могут выполняться программы двух типов:

Новые приложения Windows 8, часто называемые приложениями Windows Store.

Настольные приложения представляют собой традиционные Windows-программы, которые сейчас работают под управлением Windows 7 и взаимодействуют с операционной системой через интерфейс прикладного программирования Windows, называемый Win32 API. Для запуска настольных приложений в Windows 8 включен знакомый рабочий стол Windows. Для их разработки можно использовать, например, WPF (Windows Presentation Foundation).

представляют принципиальный отход от традиционной модели Windows. Эти программы обычно выполняются в полноэкранном режиме (хотя две программы могут совместно использовать экран в режиме Snap View) и, как правило, оптимизируются для планшетов и сенсорных экранов. Эти приложения приобретаются и устанавливаются только из магазина приложений, находящегося под управлением Microsoft. (Разработчик также может развертывать и тестировать приложения непосредственно из Visual Studio.)

Для написания этих приложений был введен новый объектно-ориентированный интерфейс программирования, называемый (не путайте с Windows RT — версией Windows 8 для процессоров ARM). Внутренняя реализация Windows Runtime базируется на модели COM (Component Object Model) с предоставлением интерфейсов через файлы метаданных с расширением .winmd, находящиеся в каталоге /Windows/System32/WinMetadata. С точки зрения внешнего пользователя система в высокой степени объектно-ориентирована.

С точки зрения прикладного программиста Windows Runtime напоминает Silverlight, хотя во внутренней реализации API не является управляемым. Вероятно, для программистов Silverlight самое очевидное различие связано с пространствами имен: пространства имен Silverlight, начинающиеся с System.Windows, были заменены пространствами, начинающимися с Windows.UI.Xaml.

WinRT

Большинство приложений Windows 8 состоит не только из кода, но и из разметки, будь то отраслевой стандарт HTML (HyperText Markup Language) или принятый Microsoft язык XAML (extensible Application Markup Language). В частности, преимуществам разбиения приложения на код и разметку относится возможность распределения процесса разработки между программистами и дизайнерами.

В настоящее время существуют три основных варианта программирования приложений Windows 8, каждый из которых основан на определенном языке программирования и языке разметки:

C# или Visual Basic и XAML;

JavaScript и HTML5.

Во всех трех вариантах задействуется интерфейс Windows Runtime, но он также поддерживается другим интерфейсом программирования для конкретного языка. Хотя смешанное использование нескольких языков в одном приложении невозможно, вы можете создавать библиотеки (типа Windows Runtime Component) с собственными файлами .winmd, доступные из любого языка Windows 8.

Для программистов, работающих на управляемых языках C# или Visual Basic .NET, WinRT выглядит знакомо. Приложения Windows 8, написанные на этих языках, не могут использовать Win32, COM или DirectX API с такой же простотой, как программисты С++, однако такая возможность существует.

Для программистов JavaScript среда Windows Runtime дополняется библиотекой WinJS (Windows Library for JavaScript), предоставляющей ряд функций системного уровня для приложений Windows 8.

После долгих размышлений (и душевных терзаний) я решил, что этот раздел нашего сайта должен быть почти полностью посвящен разработке приложений WinRT на C# и XAML. Меня много лет убеждали в преимуществах управляемых языков для разработки и отладки, и на мой взгляд, C# лучше всех языков подходит для Windows Runtime. Надеюсь, код C# будет достаточно понятен программистам C++ и JavaScript.

RuntimePack — что это за программа и нужна ли она?

Приветствую друзья! Итак, у нас сегодня тема — RuntimePack, моя задача — узнать максимум информации об этой программе и написать все простыми словами, для чего она нужна то! Поехали разбираться))

RuntimePack — что это такое?

Сборка самых необходимых библиотек и компонентов для Windows. То есть это даже не программа, а как бы сборка компонентов, например таких как Microsoft Visual C++, OpenAL, NET Framework, NVIDIA PhysX, DirectX, Java Platform, Microsoft Silverlight, Unity Web Player, Vulkan Runtime и другие.

Зачем нужно? Просто чтобы сэкономить время на установке каждого, можно просто установить все сразу. Нужно, чтобы не было таких ошибок как например нет той DLL-библиотеки или другой, что часто бывает при использовании мультимедийного софта или игр.

Сама сборка существует в двух вариантах — версии Full и Lite. Отличия? Full это все библиотеки, в то время как в версии Lite — Microsoft Visual C++ отсутствует. Версия Lite весит намного меньше.

Простыми словами сборка позволит избавиться от многих ошибок, которые начинаются с.. например с запуск программы невозможен, так как на ПК отсутствует та или иная библиотека..

Устанавливается программа просто — вы скачали, запустили, она все сама сделает, а после — делаете перезагрузку.

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

Если у вас прога идет как x86/x64, то это означает что она поддерживает как 32-битные операционки, так и 64-битные.

Вот собственно и весь процесс установки:

Который заканчивается простым сообщением:

А вот пример ошибки, которую может исправить установка пака RuntimePack:

И таких ошибок, как вы понимаете — может быть много))

Чтобы примерно понимать что входит в пак, то можно глянуть на эту картинку:

Windows desktop runtime что это

Windows Runtime. Система типов и взаимодействие с CLR

Метаданные Windows Runtime

Взаимодействие CLR с компонентами WinRT

WinRT типы и управляемый код

Проецирование типов

Базовый тип

Структуры

Строки

Null-совместимые типы

Делегаты

События

Время и дата

Массивы

Коллекции

Что такое microsoft windows desktop runtime

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

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

Microsoft Windows Runtime

Содержание

Технология

Сервисы

Метаданные

Тип системы

Компоненты WinRT

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

C++ (WRL, Component Extensions)

JavaScript

Классы Runtime

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

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

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

Windows Phone Runtime

Windows Phone 8

Windows Phone 8.1

Модель приложений Windows Runtime

Microsoft Windows desktop runtime что это за программа и нужна ли она

5 способов исправления высокой нагрузки процессом NET Runtime Service

Что такое служба NET Runtime Optimization

Способы исправить высокую загрузку ЦП

Оптимизация NET Runtime Service

Просканируйте систему на наличие инфекций

Запустите официальный скрипт Microsoft

Перезапустите службу NET Runtime Optimization

Выполните чистую загрузку Windows

Ошибка службы оптимизации .NET – частый вопросы

Нужна ли мне служба оптимизации времени выполнения .NET?

Могу ли я отключить службу оптимизации времени выполнения .NET?

Что представляет собой служба NET Runtime Optimization и mscorsvw.exe?

Windows Runtime. Система типов и взаимодействие с CLR

Метаданные Windows Runtime

Взаимодействие CLR с компонентами WinRT

Windows desktop runtime что это

Windows Runtime. Система типов и взаимодействие с CLR

Метаданные Windows Runtime

Взаимодействие CLR с компонентами WinRT

WinRT типы и управляемый код

Проецирование типов

Базовый тип

Структуры

Строки

Null-совместимые типы

Делегаты

События

Время и дата

Массивы

Коллекции

Name already in use

Launching GitHub Desktop

Launching Xcode

Launching Visual Studio Code

Latest commit

Git stats

Files

README.md

WinRT — разработка приложений под Windows 8

RuntimePack — что это за программа и нужна ли она?

RuntimePack — что это такое?

Добавить комментарий Отменить ответ

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