В последние годы фокус интересов компании Microsoft сместился в сторону облачных технологий, интернета вещей (IoT) и связанных с ними сервисов. При этом, многие устройства, взаимодействующие с облачными сервисами, имеют у себя на борту операционные системы (ОС). Ярким примером может служить Windows 10, выпущенная в 2015 году, которая претендует на роль универсальной системы практически для любых типов устройств.
Вместе с новой системой появились новые концепции модели приложений, обслуживания и доставки обновлений, а также средства разработки, не имеющие аналогов в предыдущих версиях ОС. Чтобы понять, что привело к радикальным изменениям в Windows 10 (IoT), и какие преимущества это принесет разработчикам встраиваемых устройств, будет интересно проследить историю развития средств разработки образов операционных систем компании Microsoft.
СЕМЕЙСТВО ОПЕРАЦИОННЫХ СИСТЕМ WINDOWS EMBEDDED/IOT
Для применения во страиваемых (т.е. функционально законченных) системах компания Microsoft предлагает отдельное семейство операционных систем Windows Embedded со специальными условиями лицензирования и дополнительными компонентами, предназначенными для упрощения процесса создания встраиваемых решений «из коробки» [1, 2]. Семейство Windows Embedded полностью поддерживает программное обеспечение (ПО), разработанное для версий Windows для компьютеров общего назначения (сказанное не относится к Windows CE/Compact). Работа компонентов ОС, предназначенных для обеспечения бесперебойной работы страиваемых решений, прозрачна и незаметна для прикладного программного обеспечения (ПО).
Семейство ОС Windows Embedded можно условно разделить на следующие группы:
- Windows Embedded Server, двоично полностью аналогичные ОС для компьютеров общего назначения, но предназначенные для применения в специализированных устройствах узкого назначения, со специальными условиями лицензирования. Не содержат специальных возможностей встраивания;
- Windows for Embedded Systems (FES), двоично полностью аналогичные настольным ОС для компьютеров общего назначения, но также для встраиваемого применения. Не содержат специальных возможностей встраивания;
- Windows Embedded CE/Compact (далее Windows CE) — единственные системы Microsoft жесткого реального времени. Имеют минимальный размер образа, двоично не совместимы с другими ОС Windows. Требуют отдельных драйверов под каждую платформу и средства разработки образов. В общем случае разработка образа ОС является достаточно сложной и дорогостоящей, что, однако, компенсируется низкой стоимостью лицензий. В эту же группу можно отнести системы, основанные на ядре CE, такие, как Windows Mobile;
- Windows Embedded Standard — компонентные ОС с возможностями встраивания, такими, как: фильтры записи, клавиатуры, USB и т.п. Совместимы с приложениями и драйверами устройств классических ОС Windows. Требуют разработки образа ОС, заключающейся в выборе нужной комбинации компонентов, позволяя таким образом исключить лишние в данном проекте, уменьшая занимаемый объем на диске и увеличивая стабильность системы. Необходимо специальное средство разработки;
- Windows Embedded POSReady/Industry/IoT — предсобранные версии из группы Standard, содержащие максимальный набор компонентов и не требующие специального средства разработки. Содержат специальные возможности встраивания. В работе с этими ОС используются привычные средства разработки от систем Windows для компьютеров общего назначения.
В связи с комбинацией хорошей совместимости с существующими приложениями и уникальными возможностями встраивания, наибольший интерес для разработчиков обычно представляют две последние группы ОС.
Как видно из изложенного, Windows 10 IoT относится к последней группе. Вместе с тем, имея и черты группы FES и включая в себя специальные возможности встраивания, ОС не требует отдельного конфигурирования, а процесс разработки может сводиться к простейшей установке системы с загрузочного диска. Однако средства разработки (скорее точной кастомизации) для Windows 10 IoT все же существуют и призваны упростить получение готового образа системы, сразу же сконфигурированной конкретные требования проекта.
Заметим, что с появлением Windows 10 IoT создается некоторая неоднозначность в названиях.
Во-первых, у самой Windows 10 IoT существует три разновидности: Enterprise, Mobile Enterprise и Core, имеющие некоторые различия, но основанные, тем не менее, на едином ядре [3]. Система Windows 10 IoT Enterprise при этом может в ряде источников также называться Windows 10 Enterprise LTSB, что связано со специальным способом доставки обновлений на нее (LTSB – Long Term Servicing Branch, означает ветку обслуживания, в которой система автоматически устанавливает только критические обновления и обновления безопасности, а также разрешает отложить установку на длительный срок [4]).
Во-вторых, следует отметить, что название Windows IoT применяется вместо устоявшегося Windows Embedded, что связано с развитием Интернета вещей (Internet of Things, IoT) и ориентации Windows 10 IoT на применение именно в устройствах Интернета вещей, подключаемых к облаку.
РАЗРАБОТКА ДЛЯ WINDOWS
Необходимо пояснить, что когда речь идет о понятии «разработка для Windows», следует выделить следующие типы процессов:
Разработка образа ОС, то есть набора компонентов ОС, которое, будучи развернутыми на файловую систему, составляют готовую к загрузке и использованию ОС с установленными приложениями;
Разработка приложений, выполняющихся в окружении, предоставляемом операционной системой.
Далее мы будем рассматривать только разработку образов ОС, так как именно в случае со встраиваемыми ОС существуют некоторые особенности. Разработка же приложений для них является отработанным процессом и ничем не отличается от разработки таковых для классических ОС общего назначения.
МОДЕЛИ НАСТРОЙКИ ОБРАЗОВ (ДО WINDOWS 10)
Под моделью настройки образов ОС (Customization Framework) понимается определенный путь внесения в образ ОС настроек, связанных с внешним видом системы, способами подключения к сети, взаимодействием с пользователем, элементами брендирования, адаптацией под целевой рынок, на который поставляется устройство. Сюда может относиться также добавление приложений, модификация значков и меню, звуков, сетевых и других настроек системы [5].
До появления Windows 10 для различных ОС Windows Embedded использовались различные модели настройки образов.
В Windows Embedded CE для описания конфигурации образов используется целый ряд файлов в разных форматах, считывая данные из которых, система сборки создает образ ОС [6]. Сюда входят файлы, хранящие перечень компонентов, структуру файловой системы и данные реестра.
Системы Windows Embedded CE по-своему уникальны, и их модель настройки не похожа на другие системы. В отличие от других систем, они не подразумевают сложных процедур обслуживания, так как образ в этом случае фактически является микропрограммой («прошивкой») устройства.
Средством разработки образа в данном случае является Microsoft Visual Studio с установленными дополнениями для Windows Embedded CE.
Начиная с систем Windows Phone 8.1, для мобильных устройств представлена модель настройки Managed Centralized Settings Framework (MCSF) [7]. Она предназначена для производителей мобильных устройств и позволяет им уменьшить число образов, подлежащих постоянной поддержке. Данная модель позволяет, имея единый базовый образ, осуществлять в нем различные настройки, связанные с конкретными условиями использования целевого устройства, например, изменять параметры связи или брендирования.
Настройки MCSF определяются в специальных файлах ответов (Customization Answer Files, CAFs). Эти файлы в формате XML могут быть созданы вручную или с использованием средства разработки, поставляемого с операционной системой. Во время сборки образа такой файл преобразуется в специальный пакет настроек (Customization Package), который встраивается в образ устройства. Существует возможность обновления или изменения таких пакетов в образе.
Для всех остальных систем предназначена модель настройки Unattend Framework [8], которая является наиболее знакомой широкому кругу IT-специалистов, так как она обычно применяется для автоматизации развертывания (установки) в классических ОС Windows для копьютеров общего назначения, чем и обусловлено название (Unattend — необслуживаемое, автоматическое развертывание).
Суть данной модели заключается в так называемых файлах ответов (Answer files, иногда Configuration files), содержащих описание конфигурации конкретного образа ОС в формате XML. Каждый компонент образа ОС включает ряд параметров, которые могут быть использованы для создания подобного файла ответов. Иногда говорят, что файл ответов содержит «ответы» на вопросы мастера установки (по аналогии с ручным вводом ответов на вопросы системы), чем и обусловлено его название и суть подобной автоматизации.
Однако помимо перечисленного, модель Unattend Framework предоставляет и более широкие возможности:
- Перечень настроек в файле ответов шире, чем просто ответы на вопросы мастера установки, например, можно настроить автоматический вход в систему;
- Файл ответов можно использовать при развертывании системы по сети при помощи служб Windows Deployment Services;
- Файл ответов может быть применен уже после развертывания системы для добавления каких-либо компонентов или изменения настроек;
- Файл ответов может быть применен для «запечатывания» образа при помощи утилиты sysprep [9] перед тиражированием, таким образом меняя поведения системы под целевое применение при последующем «распечатывании».
Средством разработки файла ответов является инструмент Windows System Image Manager (SIM) из комплекта Windows Assessment and Deployment Kit (ADK) (рис. 1) [10].
Рис. 1
Для систем Windows Embedded Standard применяется его разновидность Image Configuration Editor (ICE) [11] из соответствующего комплекта средств разработки (рис. 2).
Рис. 2
Для создания файла ответов с использованием данных инструментов необходимо предварительно выбрать образ системы:
- В SIM попытка создания файла ответов приводит к предложению выбрать образ ОС — его можно найти на установочном диске. Далее SIM производит сканирование образа и создает файл каталога для данного образа, содержащий перечень компонентов и настроек, возможных для данного образа. В дальнейшем сканирование образа не требуется, так как файл каталога уже создан;
- В ICE создание файла ответов требует выбора хранилища компонентов (Distribution Share, Catalog), которому будет отвечать целевой файл. В отличие от SIM, концепция, применяемая в ICE, позволяет не только настроить существующие компоненты, но и подобрать их комбинацию, исключив ненужные для целевого устройства. Именно поэтому инструмент ICE был создан специально для компонентных систем.
Таким образом, файл ответов создается для конкретного образа или хранилища компонентов и его совместимость с другими образами или хранилищами не гарантируется.
Важно отметить, что при работе с SIM или ICE разработчик должен понимать, через какие фазы проходит программа установки Windows (всего их 7, но обычная установка включает 4), так как задание параметров компонентов требует явного указания фазы установки (рис. 3).
Рис. 3
Нельзя не упомянуть еще один инструмент, относящийся более к развертыванию, — Microsoft Deployment Toolkit (MDT), имеющий собственные подходы к настройке и ориентированный на сетевое развертывание систем Windows общего назначения. Дополнительная информация о нем может быть найдена по ссылке [12].
Из описания моделей и инструментов разработки видно, что к выходу Windows 10 возникла их большая фрагментированность: существовало несколько моделей настройки и средств разработки, поставлявшихся в нескольких версиях со своими особенностями. Разработчику, осваивавшему новую для себя версию Windows, зачастую необходимо было изучать новые технологические приемы. Назрела необходимость качественного изменения — перехода к универсальной модели и средству разработки, единому для всех ОС Microsoft, что и было выполнено к выходу Windows 10.
МОДЕЛЬ НАСТРОЙКИ ОБРАЗОВ WINDOWS 10
Отметим, в Windows 10 универсальны не только модель настройки и средства разработки, но и сама система и приложения Windows Store. Рассматривая предыдущую версию, Windows 8.1, можно сказать, что приложения в ней не были по-настоящему универсальными. При создании в Visual Studio решения, ориентированного одновременно на Windows 8.1 и Windows Phone 8.1 фактически создавались три связанных проекта (рис. 4):
- Код Windows 8.1;
- Код Windows Phone 8.1;
- Общий код.
Рис. 4
Таким образом, разработчику все же приходилось писать отдельные части кода под конкретную платформу. Интерфейс также разрабатывался раздельно.
В Windows 10 подобное решение содержит уже один единственный проект (рис. 5): приложения действительно универсальны — как за счет ядра системы, единого для большого количества платформ, так и за счет поддержки адаптивного интерфейса пользователя [13]. Разумеется, для достижения качественного результата, средства, обеспечивающие подобную универсальность, должны использоваться грамотно.
Рис. 5
Универсальная модель настройки образов в Windows 10 носит название Provisioning Framework [14]. Соответствующий инструмент разработки Windows Imaging and Configuration Designer (ICD) (рис. 6) из состава комплекта ADK [15] объединяет работу с компонентами, обслуживание и подготовку к развертыванию образов как с использованием графического интерфейса, так и командной строки. В данной модели поддерживаются все редакции Windows 10, включая Mobile и Core.
Рис. 6
В новой модели настройки (рис. 7) применяется схема Provisioning XML, которая определяет структуру настроек компонентов образа. Данная схема имеет средства указания условий, при которых настройки попадают в образ, что позволяет определить зависимость определенной конфигурации образа от его состояния (т.н. многовариантные настройки [16]). Примером изменения состояния образа является, например, изменение региона в настройках устройства.
Рис. 7
Образ любой редакции Windows 10 содержит метаданные (Settings Manifest) с описанием компонентов и их возможных настроек. В процессе разработки образа при помощи ICD все возможные настройки, полученные из этих метаданных, доступны в хранилище настроек (Settings Store).
Из сказанного можно сделать вывод, что разработка образа в Windows 10 заключается не в его покомпонентной сборке из хранилища компонентов, как было в системах Windows Embedded Standard, а фактически в модификации базового образа. Базовый образ состоит из компонентов, но они неразделимы, точно так же, как в системах типа FES.
Из схемы нетрудно увидеть, что в Windows 10 по-прежнему доступны параметры компонентов из предыдущих моделей разработки. Более того, в состав ADK по-прежнему входит инструмент Windows SIM для создания файлов ответов в рамках модели Unattend Framework, что позволяет как использовать знакомые средства разработки, так и постепенно осуществлять переход на новые.
Выполненные в ICD настройки образа сохраняются в новом формате файла ответов, который называется Windows Provisioning Answer File (WPAF). Файл WPAF далее преобразуется в пакет Provisioning Package, который содержит одновременно как сами настройки, так и дополнительные компоненты (Deployment Assets), к которым относятся драйверы, приложения, обновления, языковые пакеты и т.п. Уникальной особенностью такого пакета является то, что он может быть применен как при исходном развертывании образа (на схеме — Imaging Tool), так и уже на работающем образе (с помощью Provisioning Engine). В первом случае из базового образа и файла ответов WPAF создается новый установочный носитель, включающий все выполненные настройки. Во втором — уже на развернутом образе применяются все настройки и осуществляется развертывание дополнительных компонентов.
Совмещение настроек и дополнительных компонентов в одном пакете (Provisioning Package) решает одну из проблем Unattend Framework, когда дополнительные компоненты и файл ответов, содержащий путь к ним, были разделены, что создавало потенциальные сложности, когда файл по указанному пути в момент применения файла ответов был недоступен, например, из-за ошибок и неточностей в проектировании. Данная проблема решалась, например, применением наборов конфигураций и папок OEM (Configuration Sets, OEM Folders) [17] или пользовательских модулей в Windows Embedded Standard 8 [18]. Другим способом решения проблемы было использование образов данных [19] или ручное добавление необходимого ПО уже на развернутом образе и последующие его запечатывание и тиражирование. Перечисленные способы не всегда были удобны.
Как и любой новый и универсальный инструмент, ICD не во всех ситуациях оказывается наиболее подходящим средством для решения задачи. Так, замечено, что некоторые разработчики [20] рекомендуют использовать SIM вместо ICD, так как ICD «хорошо работает с Windows 10 IoT Core, но не с IoT Enterprise», «перспективен, но станет стабильным через несколько выпусков», «запечатывание системы было проблематичным».
Действительно, ICD никак не может помочь в запечатывании образа с файлом ответов, т.к. утилита sysprep, используемая для запечатывания, ожидает файл ответов модели Unattend Framework, а ICD может сохранить настройки только в WPAF. На наш взгляд, это связано с тем, что ICD не ориентирован на классическую модель тиражирования образов «развернуть-настроить-запечатать-захватить», когда большое количество настроек выполняется непосредственно на работающем образе.
Мы считаем, что вместо этого ICD предлагает цикл «настроить-развернуть», не предполагающий выполнение настроек на работающем образе с последующим его тиражированием. Таким образом, каждый раз получается уже настроенная система с «чистой» установки. В совокупности с существующими сложностями встраивания классических Win32-приложений непосредственно на этапе развертывания (ниже мы дадим пояснения) такой цикл выглядит несколько противоречиво.
Некоторую путаницу создает то, что при помощи DISM (Deployment Image Servicing and Management, основной инструмент развертывания и обслуживания образов в Windows в командной строке) к образу нельзя напрямую применить файл ответов WPAF, но можно сделать это, если WPAF находится в составе Provisioning Package, что, тем не менее, вполне согласуется с идеологией модели Provisioning Framework (см. схему выше).
Мы также обратили внимание, что некоторые настройки, выполненные в ICD, работают не так, как ожидается, либо их поведение отличается при создании образов разных типов. Возможно, это связано с тем, что ICD был спроектирован как универсальный инструмент, скрывающий свою мощь за внешней простотой, и, как любой подобный инструмент, он требует некоторого времени на устранение шероховатостей. Интерфейс ICD гораздо проще по сравнению с SIM или ICE и не требует глубокой подготовки, а все настройки снабжены мгновенно появляющимися подсказками.
В рамках одной статьи практически невозможно описать все нововведения в разработке образов Windows 10, поэтому перечислим наиболее значимые, в том числе те, которые несложно обнаружить прямо в ICD:
- Возможность включить сжатие образа при помощи новой технологии Compact OS. Предшествующая технология, WIMBoot (результаты тестирования в Кварта Технологии доступны по ссылке [21]) обладала рядом недостатков. Compact OS совмещает в себе сильные стороны своего предшественника с отсутствием его недостатков;
- Возможность создания загрузочных носителей для чистой установки (Clean Install), производства (Production), восстановления (Recovery) (рис. 8). Носители для чистой установки ориентированы на конечного пользователя, они создаются быстро, но само развертывание длится дольше. С образами для производства ситуация обратная. Они ориентировали на производителей оборудования, их развертывание происходит быстрее. Образы для восстановления позволяют создать загрузочный носитель для автоматического восстановления системы с графической оболочкой;
- Новый формат Full Flash Update (FFU), который, в отличие от своего предшественника Windows Image (WIM), применявшегося для тиражирования Windows, является секторным, а не файловым, а значит, позволяет вместе с файлами образа сохранить разметку разделов целевого устройства. FFU в чем-то похож на формат виртуального жесткого диска (VHD/VHDX), но в целом отличается большей безопасностью.
- Сравнение форматов можно найти по ссылке [22]. На данный момент создать собственный образ в формате FFU можно только путем модификации базового образа в ICD, применить же FFU можно с помощью утилиты DISM;
- Разработчики встраиваемых устройств оценят то, что при отсутствии соединения с Интернет устройство на Windows 10 IoT Enterprise, в отличие от предыдущей версии Windows 8.1 Industry, не потребует активации.
Рис. 8
При анализе новой модели разработки и соответствующих инструментов, необходимо сделать акцент на ряде существенных замечаний:
- Отметим, что в новой модели настройки не поддерживается Windows Embedded CE, так как ее последняя версия Windows Embedded Compact 2013 не получила прямого продолжения в семействе Windows 10. Ближайшая альтернатива на данный момент — Windows 10 IoT Core, однако при всех своих достоинствах она имеет принципиальные отличия от систем Windows Embedded CE, например, не совместима с приложениями последней даже на уровне их исходных кодов и не является системой жесткого реального времени;
- Можно заметить, что принципы работы ICD в чем-то схожи с SIM, однако ключевой целью введения новых инструментов являлась универсальность, совмещенная с простотой использования. Заметим, например, что ICD, в отличие от SIM или ICE, не требует знания особенностей фаз установки Windows, что позволяет разработчику сосредоточиться на разработке образа, а не изучении особенностей работы программы установки. Не можем не отметить, что Microsoft рекомендует постепенный переход на новые средства разработки;
- В автоматическом режиме в ICD проще встроить в образ приложение Windows Store, чем классические Win32. Первое встраивается путем указания пути к пакетам и сертификату, второе обычно требует использования специальных техник;
- Некоторые из ставших классическими компонентов встраивания (например, отдельный фильтр клавиатуры) отсутствуют в текущей сборке Windows 10 Enterprise LTSB 2015, что связано с ориентацией системы на новую технологию блокировки системы Assigned Access, при использовании которой оболочкой выступает приложение Магазина Windows. Эта технология уже включает в себя фильтр клавиатуры, жестов и запуск приложения Магазина Windows как оболочки;
- Для использования файла ответов WPAF в рамках Provisioning Framework при первоначальном развертывании образа необходимо создать образ с желаемым файлом ответов непосредственно в ICD. Напомним, в рамках Unattend Framework можно просто скопировать файл ответов в определенное место на установочном диске, после чего установка станет автоматической;
- В Windows 10 IoT Enterprise доступны все возможности Windows 10 Enterprise, такие, как, например, BitLocker. Исключением является Магазин (Store) и некоторые приложения. Возможно также полностью отключить телеметрию;
- В Windows 10 IoT Core отсутствует оболочка и поддерживаются только приложения Магазина Windows (или универсальные приложения).
- По нашему мнению, несмотря на некоторые шероховатости, с течением времени новая модель разработки и инструменты займут достойное место в разработке образов Windows
.
Рекомендации по получению и тестированию пробной версии Windows 10 IoT Enterprise привидены в [23].
Получить дополнительные консультации, заказать разработку и приобрести встраиваемые ОС Microsoft вы можете у авторизованного дистрибутора в России и странах СНГ «Кварта Технологии», www.quarta-embedded.ru
ЛИТЕРАТУРА
1. Lockdown features (Industry 8.1). msdn.microsoft.com/en-us/library/dn449278(v=winembedded.82).aspx
2. Антонович С.В. Windows 8 Embedded Lockdown — возможности для встраивания. Control Engineering Russia. 2013. № 3 (45). С. 64-69. www.controlengrussia.com/programmnye-sredstva/windows-8-embedded-lockdown-vozmozhnosti-dlya-vstraivaniya
3. Windows 10 IoT для встраиваемого применения. www.quarta-embedded.ru/products/windowsembedded/windows10
4. Understanding the Long Term Servicing Branch and Current Branch in Windows 10. windowsitpro.com/windows-10/understanding-long-term-servicing-branch-and-current-branch-windows-10
5. Windows 10 Customization. msdn.microsoft.com/en-us/library/windows/hardware/mt269765(v=vs.85).aspx
6. Run-Time Image Configuration Files (Compact 2013). technet.microsoft.com/ru-ru/ee478986
7. Managed Centralized Settings Framework (MCSF). msdn.microsoft.com/en-us/library/windows/hardware/dn772150(v=vs.85).aspx
8. Customize using the desktop Unattend framework. msdn.microsoft.com/en-us/library/windows/hardware/dn898376(v=vs.85).aspx
9. Почему необходимо использование sysprep. www.quarta.ru/wiki/public:windows:servicing:sysprep
10. Комплект средств для развертывания и оценки Windows (Windows ADK) для обновления до Windows 8.1. www.microsoft.com/ru-ru/download/details.aspx?id=39982
11. Create an OS Image by Using Image Configuration Editor (Standard 8). msdn.microsoft.com/en-us/library/jj980217(v=winembedded.81).aspx
12. Microsoft Deployment Toolkit. technet.microsoft.com/ru-ru/windows/dn475741.aspx
13. Guide to Universal Windows Platform (UWP) apps. msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx
14. Customize using the Windows Provisioning framework. msdn.microsoft.com/en-us/library/windows/hardware/dn898375(v=vs.85).aspx
15. Загрузка Windows ADK. msdn.microsoft.com/ru-ru/windows/hardware/dn913721.aspx
16. Create a provisioning package with multivariant settings. msdn.microsoft.com/en-us/library/windows/hardware/dn916108(v=vs.85).aspx
17. Добавление файлов и папок с помощью папок $OEM$. technet.microsoft.com/ru-ru/library/dd744507(v=ws.10).aspx
18. Modules (Standard 8). msdn.microsoft.com/en-us/library/jj963003(v=winembedded.81).aspx
19. Создание образа данных. technet.microsoft.com/ru-ru/library/cc765989(v=ws.10).aspx
20. Sean D. Liming and John R. Malin. Addendum 1: Windows 10 IoT Enterprise Build 10240. annabooks.com/Articles/Articles_IoT10/Windows-10-IoT-E-Addendum-1%20Rev1.4.pdf
21. WIMBoot и Windows Embedded Industry 8.1. Тестирование на Intel NUC DC3217IYE. ruemb.blogspot.ru/2015/04/wimboot-windows-embedded-industry-81.html
22. WIM-, VHD- и FFU-файлы: сравнение форматов файлов образов. msdn.microsoft.com/ru-ru/library/windows/hardware/dn938355(v=vs.85).aspx
23. Сведения о загрузке пробной версии Windows 10 Enterprise LTSB. www.quarta.ru/wiki/public:windows:servicing:win10_evaluation
Автор: Кварта Технологии
