Windows 10 IoT: Еволюція засобів розробки

В останні роки фокус інтересів компанії 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].

image
Рис. 1

Для систем Windows Embedded Standard застосовується його різновид Image Configuration Editor (ICE) [11] з відповідного комплекту засобів розробки (рис. 2).

image
Рис. 2

Для створення файлу відповідей з використанням даних інструментів необхідно попередньо вибрати образ системи:

  • SIM спроба створення файлу відповідей призводить до пропозиції вибрати образ ОС — його можна знайти на диску. Далі SIM проводить сканування образу і створює файл каталогу для даного образу, що містить перелік компонентів і налаштувань, можливих для даного образу. Надалі способу сканування не потрібно, так як файл каталогу вже створено;
  • ICE створення файлу відповідей вимагає вибору компонентів сховища (Distribution Share, Catalog), якому буде відповідати цільовий файл. На відміну від SIM, концепція, що застосовується в ICE, яка дозволяє не тільки налаштувати існуючі компоненти, але і підібрати їх комбінацію, виключивши непотрібні для цільового пристрою. Саме тому інструмент ICE був створений спеціально для компонентних систем.


Таким чином, файл відповідей створюється для конкретного образу або сховища компонентів і його сумісність з іншими образами або сховищами не гарантується.

Важливо відзначити, що при роботі з SIM або ICE розробник повинен розуміти, через які фази проходить програма установки Windows (всього їх 7, але звичайна установка включає 4), так як завдання параметрів компонентів вимагає явної вказівки фази установки (рис. 3).

image
Рис. 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;
  • Загальний код.


image
Рис. 4

Таким чином, розробнику все ж таки доводилося писати окремі частини коду під конкретну платформу. Інтерфейс також розроблявся роздільно.

У Windows 10 подібне рішення містить вже один єдиний проект (рис. 5): додатки дійсно є всезагальними — як за рахунок ядра системи, єдиного для великої кількості платформ, так і за рахунок підтримки адаптивного інтерфейсу користувача [13]. Зрозуміло, для досягнення якісного результату, засоби, що забезпечують подібну універсальність, повинні використовуватися грамотно.

image
Рис. 5

Універсальна модель налаштування образів в Windows 10 носить назву Provisioning Framework [14]. Відповідний інструмент розробки Windows Imaging and Configuration Designer (ICD) (рис. 6) зі складу комплекту ADK [15] поєднує роботу з компонентами, обслуговування та підготовку до розгортання образів як з використанням графічного інтерфейсу, так і командного рядка. У даній моделі підтримуються всі редакції Windows 10, включаючи Mobile і Core.

image
Рис. 6

У новій моделі налаштування (рис. 7) застосовується схема Provisioning XML, яка визначає структуру налаштувань компонентів образу. Дана схема має кошти вказівки умов, при яких параметри потрапляють у спосіб, що дозволяє визначити залежність певної конфігурації образу від його стану (т. зв. багатоваріантні установки [16]). Прикладом зміни стану способу є, наприклад, зміна регіону у налаштуваннях пристрою.

image
Рис. 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 поєднує в собі сильні сторони свого попередника з відсутністю його недоліків;
  • Можливість створення завантажувальних носіїв для чистої установки (Install Clean), виробництва (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, не потребує активації.


image
Рис. 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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.