Windows 10 IoT: Evolution of Development Tools

In recent years, Microsoft's focus has shifted toward cloud technology, the Internet of Things (IoT), and related services. At the same time, many devices that interact with cloud services have operating systems (OS) on board. A vivid example is Windows 10, released in 2015, which claims to be a universal system for almost any type of device.


Together with the new system, new concepts of the application model, service and delivery of updates, as well as development tools that have no analogues in previous versions of the OS appeared. To understand what led to drastic changes in Windows 10 (IoT), and what advantages it will bring to developers of embedded devices, it will be interesting to trace the history of development of Microsoft operating system image development tools.

WINDOWS EMBEDDED / IOT FAMILY OPERATING SYSTEMS

For use in embedded (ie, functionally complete) systems, Microsoft offers a separate family of Windows Embedded operating systems with special licensing conditions and additional components designed to simplify the process of creating embedded solutions out of the box [1, 2]. The Windows Embedded family fully supports software (software) developed for versions of Windows for general-purpose computers (this does not apply to Windows CE / Compact). The operation of OS components designed to ensure the smooth operation of custom solutions is transparent and invisible to application software (software).

The Windows Embedded family of OS can be divided into the following groups:

  • Windows Embedded Server, binary completely identical OS for general-purpose computers, but intended for use in specialized devices of narrow purpose, with special licensing conditions. Do not contain special embedding options;
  • Windows for Embedded Systems (FES), which are binary completely similar to desktop OS for general-purpose computers, but also for embedded applications. Do not contain special embedding options;
  • Windows Embedded CE / Compact (hereinafter referred to as Windows CE) are Microsoft's only hard real-time systems. They have a minimum image size and are not binary compatible with other Windows operating systems. They require separate drivers for each platform and image development tools. In the general case, the development of an OS image is quite complex and expensive, which, however, is offset by the low cost of licenses. This group also includes systems based on the CE core, such as Windows Mobile;
  • Windows Embedded Standard - component OS with embedded features, such as: recording filters, keyboards, USB, etc. Compatible with applications and device drivers of classic Windows OS. They require the development of an OS image, which consists in choosing the right combination of components, thus eliminating unnecessary ones in a given project, reducing the occupied disk space and increasing system stability. A special development tool is needed;
  • Windows Embedded POSReady / Industry / IoT - pre-assembled versions from the Standard group, containing the maximum set of components and not requiring special development tools. Contain special embedding capabilities. In working with these OSs, familiar development tools from Windows systems are used for general-purpose computers.


Due to the combination of good compatibility with existing applications and unique embedding capabilities, the last two groups of OS are usually of most interest to developers.

As can be seen from the above, Windows 10 IoT belongs to the last group. However, having the features of the FES group and including special embedding capabilities, the OS does not require separate configuration, and the development process can be reduced to the simplest installation of the system from a boot disk. However, development tools (rather accurate customization) for Windows 10 IoT still exist and are designed to simplify the receipt of a ready-made image of the system that immediately configured the specific requirements of the project.
Note that with the advent of Windows 10 IoT, there is some ambiguity in the names.

First, there are three varieties of Windows 10 IoT itself: Enterprise, Mobile Enterprise, and Core, which have some differences, but are based, however, on a single core [3]. The Windows 10 IoT Enterprise system may also be called Windows 10 Enterprise LTSB in a number of sources, which is associated with a special way of delivering updates to it (LTSB - Long Term Servicing Branch, which means a service branch in which the system automatically installs only critical and security updates , and also allows you to postpone the installation for a long time [4]).

Secondly, it should be noted that the name Windows IoT is used instead of the well-established Windows Embedded, which is associated with the development of the Internet of Things (Internet of Things, IoT) and the orientation of Windows 10 IoT to use it in devices of the Internet of things connected to the cloud.

DEVELOPMENT FOR WINDOWS

It is necessary to clarify that when it comes to the concept of "development for Windows", the following types of processes should be distinguished:
Development of an OS image, that is, a set of OS components that, when deployed to a file system, make up ready to download and use the OS with installed applications;
Development of applications running in the environment provided by the operating system.
Further we will consider only the development of OS images, since it is in the case of embedded OSs that there are some features. The development of applications for them is a proven process and is no different from the development of those for classic general-purpose operating systems.

MODELS FOR CUSTOMIZING IMAGES (BEFORE WINDOWS 10)

The model for customizing OS images (Customization Framework) refers to a certain way of entering settings related to the appearance of the system, ways to connect to the network, user interaction, branding elements, adaptation to the target market, into the OS image which device is supplied. This may also include adding applications, modifying icons and menus, sounds, network and other system settings [5].
Before Windows 10, various models for customizing images were used for various Windows Embedded operating systems.
In Windows Embedded CE, a number of files in various formats are used to describe the configuration of images, reading data from which the build system creates an OS image [6]. This includes files that store a list of components, file system structure, and registry data.
Windows Embedded CE systems are unique in their own way, and their configuration model is not like other systems. Unlike other systems, they do not imply complicated maintenance procedures, since the image in this case is actually the firmware (“firmware”) of the device.
The image development tool in this case is Microsoft Visual Studio with the installed add-ons for Windows Embedded CE.
Starting with Windows Phone 8.1 systems, the Mobile Model Managed Centralized Settings Framework (MCSF) [7] is introduced for mobile devices. It is intended for manufacturers of mobile devices and allows them to reduce the number of images subject to ongoing support. This model allows, having a single basic image, to carry out various settings in it related to the specific conditions of use of the target device, for example, change communication or branding parameters.
MCSF settings are defined in custom answer files (CAFs). These XML files can be created manually or using the development tool provided with the operating system. During image assembly, such a file is converted into a special Customization Package, which is embedded in the device image. It is possible to update or modify such packages in an image.
For all other systems, the Unattend Framework configuration model [8] is intended, which is the most familiar to a wide range of IT specialists, since it is usually used to automate the deployment (installation) in classic Windows OS for general purpose computers, which is the reason for the name (Unattend - maintenance-free, automatic deployment).
The essence of this model is the so-called response files (Answer files, sometimes Configuration files), which contain a description of the configuration of a specific OS image in XML format. Each component of the OS image includes a number of parameters that can be used to create a similar response file. It is sometimes said that the answer file contains “answers” ​​to questions from the installation wizard (similar to manually entering answers to system questions), which determines its name and the essence of such automation.
However, in addition to the above, the Unattend Framework model also provides more features:

  • The list of settings in the answer file is wider than just answers to questions from the installation wizard, for example, you can configure automatic login;
  • The response file can be used when deploying the system over a network using Windows Deployment Services;
  • The answer file can be applied after the deployment of the system to add any components or change settings;
  • The answer file can be used to “seal” the image using the sysprep utility [9] before replication, thus changing the behavior of the system for the intended use during subsequent “printing”.


The answer file development tool is the Windows System Image Manager (SIM) tool from the Windows Assessment and Deployment Kit (ADK) (Fig. 1) [10].

image
Fig. 1

For Windows Embedded Standard systems, its version of Image Configuration Editor (ICE) [11] from the corresponding set of development tools is used (Fig. 2).

image
Fig. 2

To create an answer file using these tools, you must first select the system image:

  • In SIM, an attempt to create an answer file leads to a proposal to select an OS image - it can be found on the installation disk. Next, the SIM scans the image and creates a catalog file for this image, containing a list of components and settings that are possible for this image. Further image scanning is not required, since the catalog file has already been created;
  • In ICE, creating an answer file requires selecting a component store (Distribution Share, Catalog) to which the target file will respond. Unlike SIM, the concept used in ICE not only allows you to configure existing components, but also select their combination, eliminating unnecessary for the target device. That is why the ICE tool was created specifically for component systems.


Thus, an answer file is created for a specific image or repository of components and its compatibility with other images or repositories is not guaranteed.

It is important to note that when working with SIM or ICE, the developer must understand what phases the Windows installation program goes through (there are 7 in all, but the usual installation includes 4), since setting the parameters of the components requires an explicit indication of the installation phase (Fig. 3).

image
Fig. 3

One cannot fail to mention another deployment-related tool, the Microsoft Deployment Toolkit (MDT), which has its own configuration approaches and is focused on network deployment of general-purpose Windows systems. Additional information about him can be found at [12].

From the description of the models and development tools, it is clear that by the release of Windows 10 there was a lot of fragmentation: there were several configuration models and development tools that came in several versions with their own characteristics. A developer who has mastered a new version of Windows for himself often needed to learn new technological techniques. There is a need for a qualitative change - a transition to a universal model and development tool that is common for all Microsoft OSs, which was done for the release of Windows 10.

WINDOWS 10 IMAGE SETTING MODEL

Note that in Windows 10, not only the configuration model and development tools are universal, but also the system and applications of the Windows Store itself. Considering the previous version, Windows 8.1, we can say that the applications in it were not truly universal. When creating a solution in Visual Studio that focused on both Windows 8.1 and Windows Phone 8.1, three related projects were actually created (Fig. 4):

  • Windows 8.1 code
  • Windows Phone 8.1 Code
  • Common code.


image
Fig. 4

Thus, the developer still had to write separate pieces of code for a specific platform. The interface was also developed separately.

In Windows 10, such a solution already contains one single project (Fig. 5): the applications are truly universal - both due to the kernel of the system, which is common for a large number of platforms, and due to the support of the adaptive user interface [13]. Of course, to achieve a high-quality result, the means providing such universality should be used correctly.

image
Fig. 5

The universal model for configuring images in Windows 10 is called the Provisioning Framework [14]. The corresponding Windows Imaging and Configuration Designer (ICD) development tool (Fig. 6) from the ADK [15] combines work with components, maintenance and preparation for deployment of images using both the graphical interface and the command line. This edition supports all editions of Windows 10, including Mobile and Core.

image
Fig. 6

The new configuration model (Fig. 7) uses the Provisioning XML schema, which defines the configuration structure of image components. This scheme has the means to indicate the conditions under which settings fall into the image, which allows you to determine the dependence of a particular configuration of the image on its state (the so-called multivariate settings [16]). An example of changing the state of an image is, for example, changing a region in the device settings.

image
Fig. 7

The image of any edition of Windows 10 contains metadata (Settings Manifest) with a description of the components and their possible settings. In the process of developing an image using ICD, all possible settings obtained from this metadata are available in the Settings Store.
From the foregoing, we can conclude that the development of an image in Windows 10 does not consist in its component-wise assembly from the component store, as it was in Windows Embedded Standard systems, but in fact in the modification of the base image. The base image consists of components, but they are inseparable, just like in systems like FES.

From the diagram it is easy to see that in Windows 10 the parameters of the components from previous development models are still available. Moreover, the ADK still includes the Windows SIM tool for creating response files as part of the Unattend Framework model, which allows you to use familiar development tools and gradually migrate to new ones.

The image settings made in ICD are saved in a new answer file format called the Windows Provisioning Answer File (WPAF). The WPAF file is then converted into a Provisioning Package, which contains both the settings themselves and additional components (Deployment Assets), which include drivers, applications, updates, language packs, etc. A unique feature of such a package is that it can be used both during the initial deployment of the image (in the diagram - the Imaging Tool), and already in the running image (using the Provisioning Engine). In the first case, a new installation media is created from the base image and the WPAF response file, which includes all the settings made. In the second, all settings are already applied to the deployed image and additional components are deployed.

The combination of settings and additional components in one package (Provisioning Package) solves one of the problems of the Unattend Framework, when the additional components and the answer file containing the path to them were separated, which created potential difficulties when the file at the specified path at the time of application of the answer file was unavailable, for example, due to errors and inaccuracies in the design. This problem was solved, for example, by using configuration sets and OEM folders (Configuration Sets, OEM Folders) [17] or custom modules in Windows Embedded Standard 8 [18]. Another way to solve the problem was to use data images [19] or manually add the necessary software already on the deployed image and then seal and duplicate it. The listed methods were not always convenient.

Like any new and universal tool, ICD is not in all situations the most suitable means for solving the problem. Thus, it was noticed that some developers [20] recommend using SIM instead of ICD, since ICD “works well with Windows 10 IoT Core, but not with IoT Enterprise”, “promising, but will become stable in several releases”, “sealing the system was problematic. "

Indeed, ICD cannot help in sealing the image with the answer file, because the sysprep utility used for sealing expects an Unattend Framework model response file, and ICD can only save settings in WPAF. In our opinion, this is due to the fact that ICD is not focused on the classic “deploy-configure-seal-capture” model of replicating images when a large number of settings are performed directly on a working image.

We believe that instead of this, ICD offers a “configure-deploy” cycle, which does not imply that settings are made on a working image with its subsequent replication. Thus, each time it turns out already configured system with a "clean" installation. In conjunction with the existing difficulties of embedding classic Win32 applications directly at the deployment stage (we will explain below), this cycle looks somewhat contradictory.

Some confusion is that using DISM (Deployment Image Servicing and Management, the main tool for deploying and servicing images in Windows on the command line), you cannot directly apply the WPAF response file to the image, but you can do this if WPAF is part of the Provisioning Package. which, however, is consistent with the ideology of the Provisioning Framework model (see diagram above).

We also noticed that some settings made in ICD do not work as expected, or their behavior is different when creating images of different types. Perhaps this is due to the fact that the ICD was designed as a universal tool, hiding its power behind its external simplicity, and, like any similar tool, it requires some time to eliminate roughnesses. The ICD interface is much simpler compared to SIM or ICE and does not require deep preparation, and all settings are equipped with instantly appearing prompts.

Within the framework of one article, it is almost impossible to describe all the innovations in the development of Windows 10 images, so we list the most significant ones, including those that are easy to find directly in ICD:

  • Ability to enable image compression using the new Compact OS technology. The previous technology, WIMBoot (the test results in Quart Technologies are available at [21]) had a number of drawbacks. Compact OS combines the strengths of its predecessor with the absence of its shortcomings;
  • The ability to create bootable media for a clean installation (Clean Install), production (Production), recovery (Recovery) (Fig. 8). Media for a clean installation is end-user oriented, they are created quickly, but deployment itself takes longer. With images for production, the situation is reversed. They focused on equipment manufacturers, their deployment is faster. Recovery images allow you to create bootable media for automatic system recovery with a graphical shell;
  • The new Full Flash Update (FFU) format, which, unlike its predecessor, Windows Image (WIM), which was used to replicate Windows, is a sector rather than a file format, which means that it can save partition layout of the target device along with image files. FFU is somewhat similar to the format of a virtual hard disk (VHD / VHDX), but is generally more secure.
  • A comparison of the formats can be found at [22]. At the moment, you can create your own image in FFU format only by modifying the base image in ICD, but you can apply FFU using the DISM utility;
  • Embedded developers will appreciate that if there is no Internet connection, a device on Windows 10 IoT Enterprise, unlike the previous version of Windows 8.1 Industry, will not require activation.


image
Fig. 8

When analyzing a new development model and related tools, it is necessary to focus on a number of significant points:

  • Note that the new configuration model does not support Windows Embedded CE, since its latest version of Windows Embedded Compact 2013 did not receive a direct continuation in the Windows 10 family. The closest alternative at the moment is Windows 10 IoT Core, but with all its advantages, it has fundamental differences from Windows Embedded CE systems, for example, are not compatible with the applications of the latter even at the level of their source codes and are not a hard real-time system;
  • You may notice that the principles of ICD work are somewhat similar to SIM, however, the key goal of introducing new tools was universality, combined with ease of use. Note, for example, that ICD, unlike SIM or ICE, does not require knowledge of the features of the Windows installation phases, which allows the developer to focus on developing the image, rather than studying the features of the installation program. We cannot but note that Microsoft recommends a gradual transition to new development tools;
  • In automatic mode, in ICD, it is easier to embed a Windows Store application in an image than classic Win32. The first is embedded by specifying the path to the packages and certificate, the second usually requires the use of special techniques;
  • Some of the classic embedding components (for example, a separate keyboard filter) are missing from the current build of Windows 10 Enterprise LTSB 2015, which is related to the orientation of the system to the new Assigned Access locking system technology, which uses the Windows Store application as a shell. This technology already includes a keyboard filter, gestures and the launch of the Windows Store application as a shell;
  • To use the WPAF answer file within the Provisioning Framework during the initial deployment of the image, you must create an image with the desired answer file directly in the ICD. Recall that within the Unattend Framework, you can simply copy the answer file to a specific location on the installation disk, after which the installation will become automatic;
  • In Windows 10 IoT Enterprise, all the features of Windows 10 Enterprise are available, such as, for example, BitLocker. An exception is the Store and some applications. It is also possible to completely disable telemetry;
  • Windows 10 IoT Core does not have a shell and only Windows Store apps (or universal apps) are supported.
  • In our opinion, despite some rough spots, over time, the new development model and tools will take their rightful place in the development of Windows images
.

Recommendations for obtaining and testing a trial version of Windows 10 IoT Enterprise are given in [23].

You can get additional consultations, order development, and purchase the Microsoft embedded OS from an authorized distributor in Russia and the CIS countries, Quarta Technologies, www.quarta-embedded.ru

REFERENCES
1. Lockdown features (Industry 8.1). msdn.microsoft.com/en-us/library/dn449278 (v = winembedded.82) .aspx
2. Antonovich S.V. Windows 8 Embedded Lockdown - Embedded Features. Control Engineering Russia. 2013. No. 3 (45). S. 64-69. www.controlengrussia.com/programmnye-sredstva/windows-8-embedded-lockdown-vozmozhnosti-dlya-vstraivaniya
3. Windows 10 IoT for embedded use.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/en-us/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. Why is it necessary to use sysprep. www.quarta.ru/wiki/public : windows: servicing: sysprep
10. Windows Deployment and Evaluation Toolkit (Windows ADK) for upgrading to Windows 8.1. www.microsoft.com/en-us/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/en-us/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. Download Windows ADK. msdn.microsoft.com/en-us/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. Adding files and folders using folders $ OEM $. technet.microsoft.com/en-us/library/dd744507 (v = ws.10) .aspx
18. Modules (Standard 8). msdn.microsoft.com/en-us/library/jj963003 (v = winembedded.81) .aspx
19. Creating a data image. technet.microsoft.com/en-us/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 and Windows Embedded Industry 8.1. Testing for Intel NUC DC3217IYE. ruemb.blogspot.ru/2015/04/wimboot-windows-embedded-industry-81.html
22. WIM, VHD and FFU files: comparing image file formats. msdn.microsoft.com/en-us/library/windows/hardware/dn938355 (v = vs.85) .aspx
23. Information about downloading a trial version of Windows 10 Enterprise LTSB. www.quarta.ru/wiki/public : windows: servicing: win10_evaluation

Also popular now: