Modules (Standard 8)
Review modules, module types, and module relationships in Windows Embedded 8 Standard (Standard 8).
In Windows Embedded 8 Standard (Standard 8), all of the functionality of the Windows 8 operating system is available in pieces called modules. Modules can contain packages and files, and are the smallest unit of functionality that you can add to your Standard 8 OS design. For example, a module might provide the packages and files needed for wireless networking. Modules may have dependencies on other modules.
Microsoft signs Standard 8 modules to help make them more secure. You can also sign non-Microsoft modules, if desired.
If a module is indicated as signed in Image Configuration Editor (ICE), that means that the cab or emb module is signed but does not necessarily reflect whether drivers in the module are signed.
You use the Image Builder Wizard (IBW) and Image Configuration Editor (ICE) tools to create and build a Standard 8 image that has the functionality that you choose. All deployable images must contain the Embedded Core module, which forms the foundation for all Standard 8 operating systems. You can add other modules to your image to add features, device drivers, or language support. You may also create custom modules for custom functionality.
You can add modules when designing and building your OS image, or you can use Deployment Image Servicing and Management (DISM) to add them after you build the image or to an offline image. For information about deploying the image, see Deployment Image Servicing and Management (DISM) Technical Reference.
There are five basic types of modules in Standard 8.
Embedded Core Module
The Embedded Core module contains the minimum functionality that is required for Standard 8 deployment. Available in x86 and x64 versions, it is used as the base for all Standard 8 images, and is the smallest image that you can build and deploy.
Embedded Core provides following functionality:
- Device drivers and class installers needed to start a device for the architecture specified.
- The software required to start various devices.
- Basic support for security.
- Basic support for servicing.
- Basic support for the following networking protocols: TCP/IP, IPV4/6, DHCP, HTTP, DNS Client, NETBIOS, and SMB/CIFS.
The Embedded Core is language-neutral and does not contain fonts or language resources. When developing your OS image, you must add at least one language module to your image.
The Embedded Core includes a command prompt, but it does not include a complete user interface or any Windows-based applications or components that rely on the presence of a complete GUI or other advanced Standard 8 functionality.
You can service this module through Deployment Image Servicing and Management (DISM) or through the Windows Update process.
For details about what the Embedded Core contains and which settings you can configure, see Embedded Core.
This type of module is a technological group of functionality, such as a shell or wireless networking, that you can add to your image while you are designing it or after you deploy it.
Driver modules include the drivers needed for a device or a group of devices for Windows Embedded 8 Standard (Standard 8). Drivers enable hardware or peripherals to function with the device.
When you use Image Builder Wizard (IBW) to build an image, you can install additional device drivers. For more information, see Add Drivers Using Image Builder Wizard.
For driver modules that you can add to your image when you are designing your OS, see Drivers.
Language modules provide fonts and other resources needed to translate all or parts of the user interface (UI) of a Standard 8 operating system into a specific language. They might include resources for a fully localized language or for partially localized language for a specific region.
You must select at least one language module for your OS image. For a list of language modules that are supported in Standard 8, see Languages.
You can create your own module to modify the registry and to execute commands to help install your custom software. You use the Module Designer tool to create your custom module and then import it into the catalog so that you can add it to your image. These modules contain a metadata file and a list of files. They look and behave similarly to feature modules, except that they can have custom files and applications.
Files and directories copied to a target device when adding a custom module through DISM may be hidden. In order to see these files, the user should change the system attribute to display system and hidden files.
Modules may depend on other modules for their functionality or they may conflict with other modules. In many cases, these module relationships are managed automatically, but in some cases, you must manage them when designing your OS image.
A dependency is a relationship in which one module depends upon the functionality provided by another module. Unresolved dependencies can prevent your image from functioning correctly. Dependencies can apply to specific modules or to one or more modules from a group of modules. For example, you must include one language module in your image from the group of all available language modules.
The following list shows the types of dependencies:
- Required Modules provide functionality that is required for the module with the dependency to function. A module might require one or more modules in a group of modules.
- Optional Modules provide additional functionality that you may want to add to your image. Although these are not required, the module with the dependency may not provide all possible functionality if they are not.
If a custom module has a dependency on a specific version of another module, and the configuration file contains a different version than the one required by the custom module, ICE will report a dependency error.
The error dialog box will then incorrectly display that the dependency has been resolved.
To resolve the dependency error, select the module with the incorrect version number in the configuration file and manually change the version number in the Properties pane.
For more information about dependencies, see Dependencies)
A conflict is a relationship in which one module conflicts with the functionality of another module. Conflicts must not be included in the image. Some modules have a conditional conflict in which a module conflicts with another under certain conditions.