Windows?PE Developer's Guide Microsoft Corporation April, 2007 Applies to: ???Windows?PE 2.0 Summary: Provides information about the Windows Preinstallation Environment (Windows?PE) for the Microsoft? Windows? family of operating systems. It provides guidelines for independent software vendors (ISVs) and original equipment manufacturers (OEMs) to develop and to debug deployment, diagnostics, and recovery applications that run in Windows?PE. Disclaimer The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. ? 2007 Microsoft Corporation. All rights reserved. Microsoft, Win32, Windows, and Windows?NT are either registered trademarks or trademarks of Microsoft Corporation in the United States or other countries or regions. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Contents Introduction 1 Building Windows?PE Applications 2 Development Platforms and Tools 2 Runtime Environment 2 Project Build Settings 3 Creating a Windows PE Image and Adding Applications 3 Debugging Applications in Windows?PE 8 Programming for Windows?PE 9 Design Considerations 9 Statelessness 9 RAMDISK Boot 9 File-based Write Filter ("Scratch Space") 10 Usage of Microsoft Virtual PC 10 Extensibility Points 10 Winpeshl.exe 11 Wpeinit.exe / Wpeutil.exe / Wpeutil.dll 11 Desktop Settings 13 References 13 Windows?PE API Compatibility Reference 13 Overview 13 Supported APIs 13 Unsupported APIs 14 Windows Subsystems Reference 14 Windows?PE Documentation 15 Glossary 16 Introduction The Windows? Preinstallation Environment (Windows?PE) is the core technology for the diagnostics, deployment, and recovery of Microsoft? Windows operating systems. It is a bootable collection of Windows components that will run from a variety of media without installation. Windows?PE is licensed to independent software vendors (ISVs) and original equipment manufacturers (OEMs) for the purposes of creating customized deployment, diagnostics, and recovery utilities. This document outlines the development best practices, capabilities, and limitations of Windows?PE. It is intended for ISVs and OEMs, and it applies to Windows?PE 2.0, which is based on components from the Windows?Vista? operating system. Windows?PE 2.0 comes in both 32-bit x86 and 64-bit x64 versions. The 32-bit version must be used to install, recover, and troubleshoot 32-bit versions of Windows; likewise, the 64-bit version must be used to service 64-bit versions of Windows. The 64-bit version does not support WOW64, so it can execute only 64-bit applications and drivers. Windows?PE is a bootstrap environment with enough core functionality to enable deployment, diagnostics, and recovery scenarios. It is capable of booting and running without installation or online configuration. It can be booted from the network with PXE, a CD/DVD, a USB Flash Device (UFD), or a hard disk. It also has the ability to run entirely from random access memory (RAM). For a high-level overview of Windows?PE 2.0 that includes a list of new features, go to the Windows?PE 2.0 for Windows?Vista Overview (http://go.microsoft.com/fwlink/?LinkId=80812). Figure 1. A simplified diagram of the composition of Windows?PE. Windows?PE is not a general-purpose operating system. It may not be used for any purpose other than deployment, diagnostics, and recovery. It may not be used as a thin client or an embedded operating system. There are other Microsoft products, such as Windows? XP Embedded and Windows?CE, which may be used for these purposes. When creating a product for Windows?PE, you may not add additional Windows code to your product without consent from Microsoft. You may add code that you have created or have licensed for redistribution from a third party. For answers to Windows?PE licensing questions, send e-mail to licwinpe@microsoft.com. Building Windows?PE Applications You can develop 32-bit and 64-bit applications and dynamic link libraries (DLLs) for Windows?PE with native C and C++ and the subsystems and application programming interfaces (APIs) listed in the "Windows?PE API Compatibility Reference" later in this document. Windows?PE uses MFC42.dll, but does not support other versions of MFC. Therefore, applications based on MFC are not supported on Windows PE. Likewise, Windows PE does not support ATL. Windows?PE does not support the .NET Framework, so you cannot build managed applications or components with C#, Visual Basic, .NET, or managed C++. Development Platforms and Tools To build applications for Windows?PE 2.0, you can host the build environment on Windows?Vista, Windows?XP, or Windows Server?2003. The required build tools for each host are listed in this table. Host Windows Version Required Build Tools Windows?Vista Windows SDK for Windows?Vista Visual Studio .NET 2005 with Service Pack 1 (SP1) Support Update for Windows?Vista Windows Automated Installation Kit (Windows?AIK) Windows?XP and Windows Server?2003 Windows SDK for Windows?Vista Visual Studio .NET 2005 or Visual Studio .NET 2003 Windows Automated Installation Kit (Windows?AIK) The Windows SDK provides information on how to build Win32 applications, including documentation, header files, and libraries. You can obtain the Windows SDK for Windows?Vista from the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkID=80852. The Windows?AIK is required because it contains Windows?PE 2.0 and its offline customization tools. Microsoft recommends that you install Visual Studio before installing the Windows SDK. Visual Studio enables the SDK installer to set its .include, .lib, and .bin directories to work correctly with Visual Studio. The Windows AIK may be installed before or after Visual Studio and the Windows SDK. Runtime Environment Windows?PE requires an ACPI-compliant computer with at least 512?megabytes (MB) RAM for RAMDISK operation and 256?MB RAM for non-RAMDISK operation. Applications that require significant amounts of RAM may increase this minimum requirement. Be sure to determine the minimum amount of RAM needed for your application plus Windows PE. Project Build Settings This section describes some of the basic Visual Studio project settings that may be different from the defaults created by the Visual Studio Project Wizard. Please read this section to ensure that you set up your project's build settings to produce applications and DLLs that are compatible with Windows PE. You must develop Windows PE applications with native C or C++ code that does not use MFC or ATL. Therefore, if you use the Visual Studio Project Wizard, choose a Win32 project and make sure that both MFC and ATL are not checked. Set your project options to link to the static C/C++ runtime libraries, not the .dll version of Msvcrt.dll. Open your project properties and set "Configuration Properties \ C/C++ RunTime Library" to "Multi-threaded" or "Multi-threaded debug," not one of the .dll versions. If you do not perform this step, then your application might not run on Windows?PE. Note???Your application can use customized .dll files that you write or license from a third party. Add these .dll files to your application for Windows?PE. However, do not use Msvcrt.dll and do not include additional Windows .dll files that are not part of Windows?PE. If you plan to host your application on the 64-bit version of Windows?PE, set the project build options to compile all binaries with the x64 compiler in Visual Studio. If you plan to host your application on the 32-bit version of Windows?PE, set the project options to compile with the x86 compiler. Note???Be sure that your project does not have the /clr: compiler option set. This option produces managed C++ code, which will not run on Windows PE. Creating a Windows PE Image and Adding Applications The following steps show how to create a Windows PE image, customize the image to include specific Windows PE features, add your application files to the image, and produce a bootable CD-ROM or USB Flash Drive. For additional details on how to further customize your Windows PE image, refer to the Windows Preinstallation Environment (Windows PE) User's Guide (Winpe.chm) in the Windows AIK. Step 1: Set up a Windows?PE Build Environment In this step, you will create a required directory structure that supports building a Windows?PE image. On your build computer, click Start, point to All Programs, point to Windows?OPK or Windows?AIK, and then click Windows?PE Tools Command Prompt. The menu shortcut opens a Command Prompt window and automatically sets environment variables to point to all the necessary tools. By default, all tools are installed at C:\Program Files\\Tools, where can be Windows?OPK or Windows?AIK. At the command prompt, run the Copype.cmd script. The script requires two arguments: hardware architecture and destination location where the Windows?PE image will be created. For example, copype.cmd Where can be x86 or amd64 and is a path to the local directory. For example, copype.cmd x86 c:\winpe_x86 The script creates the following directory structure and copies all the necessary files for that architecture. For example, \winpe_x86 \winpe_x86\ISO \winpe_x86\mount Step 2: Mount the Base Windows?PE Image In this step, you will mount the base image to a local directory so that you can add or remove packages. At the command prompt, mount the base Windows?PE image (Winpe.wim) to the \mount directory by using ImageX. For example, imagex /mountrw c:\winpe_x86\winpe.wim 1 c:\winpe_x86\mount Step 3: Add Additional Packages By using the Peimg tool, you will install Windows features by using the /install option. Windows features are included with the base image (Winpe.wim) but are not installed. You can also import packages and add drivers and language packs. For more information, see the Windows Preinstallation Environment (Windows PE) User's Guide (winpe.chm). Add a Windows feature to the base image by using the peimg /install command. For example, Repeat step 1 for each package. peimg /install= c:\winpe_x86\mount\Windows where denotes the package name. A list of available packages and their names can be obtained by using the /list command. Wildcards can be used when specifying a package name. Any packages with matching names will be installed. For example, peimg /install=WinPE-HTA-Package c:\winpe_x86\mount\Windows -OR- peimg /install=*HTA* c:\winpe_x86\mount\Windows where wildcards denote any package with HTA in the package name. Windows?PE 2.0 provides the following Windows features referred to as packages: Package Name Description WinPE-FONTSupport- -Packages Additional font support for ja-jp, ko-kr, zh-cn, zh-hk, and zh-tw. WinPE-HTA-Package HTML application support WinPE-MDAC-Package Microsoft Data Access Component support WinPE-Scripting-Package Windows Script Host support WinPE-SRT-Package Windows Recovery Environment component WinPE-WMI-Packages Windows Management Instrumentation (WMI) support WinPE-XML-Package Microsoft XML (MSXML) parser support Verify that the packages were installed by using the peimg /list command to view all packages in the current image. For example, peimg /list c:\winpe_x86\mount\Windows In the INS column, (+) denotes installed packages and (-) denotes not installed. Step 4: Add Your Application and Additional Customizations This step is where you add your application and its support files to your Windows?PE image. You can also add any scripts that you need while Windows?PE is running. Copy your application files into the Windows?PE image. For example, if your application is "myApp.exe", then type: copy myApp.exe mount\"Program Files" The following is a list of common tools you might want to include in your Windows?PE image: ImageX A command-line tool for capturing and applying images during deployment scenarios. For example, at a command prompt, copy "c:\program files\\Tools\x86\imagex.exe" c:\winpe_x86\iso\ Package Manager (Pkgmgr.exe) A tool for servicing Windows image (.wim) files offline. You must copy the entire \Servicing folder and MSXML6 binaries. Offline servicing requires ImageX. For example, xcopy "c:\program files\\Tools\\Servicing" c:\winpe_x86\iso\Servicing /s copy %windir%\system32\msxml6*.dll c:\winpe_x86\iso\Servicing Where can be Windows?OPK or Windows?AIK and can be x86, amd64, or ia64. In both previous examples, the tools are not loaded into memory during a Windows?PE RAM boot. The media must be available to access the tools. To load the tools into memory along with Windows?PE, copy the source files into the mounted \Windows directory. For example, c:\winpe_x86\mount\Windows Important???Adding files to the \Windows directory will increase the size of your Windows?PE RAM image. Make sure your computer has sufficient memory to boot Windows?PE and run various applications. Step 5: Prepare the Image In this step, you will prepare the image by using the peimg /prep command. This operation removes any non-installed packages from the final image. This operation reduces the overall image size. For example, peimg /prep c:\winpe_x86\mount\Windows The /prep option cannot be reverted, and after the /prep option is run, the /install, /uninstall, /import, and /list options will not function, while the /lang and /inf options will continue to function. The Peimg tool prompts you to confirm the command. To suppress this prompt for scripting, add the /f option. Step 6: Commit Changes to the Image In this step, you commit the changes to the original image file (Winpe.wim) by using the ImageX /unmount option with the /commit option. For example, imagex /unmount c:\winpe_x86\mount /commit Step 7: Replace the Default Boot.wim File In this step, you replace the default Boot.wim in the \ISO directory with your new custom image. The image must be called Boot.wim. For example, copy c:\winpe_x86\winpe.wim c:\winpe_x86\ISO\sources\boot.wim Next Step You now have a customized Windows?PE RAMDISK image that you can place on bootable media, like a CD-ROM or UFD. To create a bootable CD-ROM On your technician computer, at a command prompt, create an .iso file by using Oscdimg. For example, oscdimg -n -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe_x86.iso For ia64 architecture, replace etfsboot.com with efisys.bin. Burn the image (Winpe_x86.iso) to a CD-ROM. To create a bootable UFD During a running Windows?Vista operation system or Windows?PE session, insert your USB Flash Drive (UFD) device. At a command prompt, use Diskpart to format the device as FAT32 spanning the entire device, setting the partition to active. For example, diskpart select disk 1 clean create partition primary size= select partition 1 active format fs=fat32 assign exit Where the value of disk 1 is equal to UFD. On your technician computer, copy all the contents in the \ISO directory to your UFD device. You can manually create the directory structure or use the xcopy command to automatically build and copy the appropriate files from your technician computer to your UFD device. For example, xcopy c:\winpe_x86\iso\*.* /s /e /f f:\ Where c: is your technician computer hard disk and f: is your UFD device. You can further customize your Windows?PE image by adding language packs, custom scripts, and drivers. For more information, see the Windows Preinstallation Environment (Windows PE) User's Guide (Winpe.chm), especially the "How-To" Topics under "Customizing Windows PE." Debugging Applications in Windows?PE You can also use the Windows Debuggers (Ntsd.exe, Cdb.exe and Windbg.exe) and their supporting tools to debug applications on Windows?PE and to kernel debug Windows?PE itself. To debug a Windows?PE destination computer remotely, you must turn off the built-in firewall by running wpeutil disablefirewall from a Command Prompt window. To enable kernel debugging of Windows?PE you must set the debug flag of the BCD store used to boot the image to "On." The store is contained in a file named "bcd" within the boot directory in the root of the media containing the Windows?PE image (not within the .wim file in a RAMDISK boot scenario). The debug flag can be set with the following command: bcdedit /store /boot/bcd /set {default} debug on The {default} might need to be replaced by the UID of the boot option for Windows?PE. You can also enable kernel debugging by pressing F8 during boot and selecting the debug option. To use a symbol server from within Windows?PE, you must use the net use command on the server's symbols and file shares. Scenario: User-mode Debugging of an Application You must make the debugging tools available on the Windows?PE computer. You can either copy them locally or use them from a share. The easiest user-mode debugging method is to run a process server on the Windows?PE computer and connect to it by using a debugger on another computer. The process server is included with the debugging tools. Dbgsrv.exe, can be set up as in the following example: Run wpeutil disablefirewall on the Windows?PE computer. Run dbgsrv.exe –t tcp:port=1234 on the Windows?PE computer. The process server can be used from the remote computer to attach to or start processes on the Windows?PE destination computer. A guide to using and connecting to the process server by using the premote command-line option is included in Debugger.chm. It is also possible to run the debugger directly on the Windows?PE computer, but this requires setting up symbol and source paths after every reboot of the Windows?PE computer. It is easier to perform the debugging as previously described from a computer running a full version of Windows. Scenario: Kernel-mode Debugging You can debug Windows?PE in kernel-mode as follows. Prevent Startnet.cmd from running. Hold down the CTRL key during boot before the command prompt is shown. Programming for Windows?PE Design Considerations Statelessness To support CD-boot scenarios, Windows?PE is designed to run without being installed. Because of this, Windows?PE is designed to be stateless between reboots. When Windows?PE is booted into a RAMDISK (.wim file), statelessness is enforced, so any state changes (files, registry keys, and so on) are made in RAM and are lost when the computer is turned off. In addition, when Windows PE is run from a read-only medium such as a CD-ROM, state changes cannot be written back to the Windows PE boot medium. To accommodate statelessness, modifications to Windows PE must be made to the .wim image as it is being created, not while it is running. For example, you must install and configure applications as a step in creating the .wim image. Likewise, you must make permanent registry changes by importing the Windows PE registry hives to a host computer, editing the keys, and then exporting the hives back out to the .wim image. Once all the persistent changes have been applied to the .wim image, it can be prepared for use on bootable media. RAMDISK Boot Booting with a .wim file into a RAMDISK comprises the following stages: Bootcode (Etfsboot, MBR, and so on) calls into Bootmgr (Windows?Vista bootloader). Bootmgr reads Boot Configuration Database (BCD). The .wim file is loaded completely into the RAM through BIOS I/O calls. The loader mounts the .wim file to an empty RAMDISK volume. Boot process continues with Winload.exe. Note that, in step?3, the entire .wim file is loaded into RAM. If the amount of RAM present on a computer is less than the size of the .wim file, then the loader will exit and will halt the loading process. Windows?PE 2.0 .wim file sizes can vary from approximately 95?MB to over 160?MB, depending on the configuration (optional components, drivers, applications, etc.) Therefore, it is important to maintain a .wim file size that is consistent with your application requirements. For example, a 160?MB .wim file will run well on operating systems with 512?MB RAM, while a 500?MB .wim file will not run well. For low-memory scenarios (less than 512?MB shared), "flat" (non-RAMDISK) boot of Windows?PE is recommended. For more information about how to configure Windows?PE for a flat boot, not into RAM, see the documentation in Winpe.chm. File-based Write Filter ("Scratch Space") Windows?PE 2.0 provides up to 32?MB of read-write temporary space for applications to use. Note that this is available in all Windows?PE boot scenarios, regardless of boot media type or RAMDISK usage. This temporary space is useful for applications that produce log files. However, applications that require more storage space must utilize the hard disk or network resources. Usage of Microsoft Virtual PC Microsoft Virtual PC can be a useful tool for debugging Windows?PE applications. Often, it is useful to be able to run your application in Windows?PE on your development computer without rebooting. You can use Windows?PE in Microsoft Virtual PC by creating a Windows?PE .iso file and by selecting Capture ISO image. Note???You must allocate at least 512 MB RAM to the Virtual Machine in which you run Windows?PE. Extensibility Points The majority of Windows?PE applications are fixed-function and do not use Windows multitasking features extensively. It is common to add a custom "shell" application to Windows?PE that provides a user interface. The following figure illustrates the Windows Recovery Environment (Windows?RE) application shell. Figure 2: The Windows?RE application shell. This section details the various extension points that are available to create a customized Windows?PE shell application. Extension points are "hooks" that exist in Windows?PE that your application can use in order to make a more seamless end-user experience. For example, your application can be launched automatically by Windows?PE. Winpeshl.exe By default, Winpeshl.exe is the first process run when Windows?PE is booted. This is specified by the registry value cmdline contained in the key HKLM\System\Setup. Winpeshl.exe searches for a file called Winpeshl.ini. If the file does not exist, then Winpeshl.exe will start a Cmd.exe process that executes the Startnet.cmd script. If Winpeshl.ini does exist and it contains applications to launch, then these applications will be executed instead of Cmd.exe. Figure 3: Boot application decision path. A customized shell application can be launched from either Winpeshl.ini or Startnet.cmd, depending on what experience you provide to the end user. If it is acceptable to show command-prompt user interface (UI), then Startnet.cmd is the most convenient command to launch your application. However if your application provides a complete UI, such as the previous Windows?RE screenshot, then this is where you must launch your application. If you launch your application from Winpeshl.ini, read the following section regarding Wpeinit.exe. Wpeinit.exe / Wpeutil.exe / Wpeutil.dll Wpeinit.exe performs important initialization tasks, such as installing PnP devices, starting the networking stack, and processing Unattend.xml settings. If Wpeinit.exe is not run at startup, networking will not be enabled. Important???Customized shell applications must either run Wpeinit.exe or use Wpeutil.exe to enable networking. Networking can be started at any time by running Wpeinit.exe or the Wpeutil InitializeNetwork command. Both applications call into a common code base. Figure 4. Initialization tools architecture. Customized shell applications can call directly into Wpeutil.dll through the LoadLibrary/GetProcAddress command. Each of the functions exported by Wpeutil.dll have the same function signature as WinMain()(http://go.microsoft.com/fwlink/?LinkID=16995): int?InitializeNetworkingW(?????? ????HINSTANCE?hInstance, ????HINSTANCE?hPrevInstance, ????LPSTR?lpCmdLine, ????int?nCmdShow ); For a complete listing of Wpeutil.dll exports, see Winpe.chm in the Wpeutil.exe section of "Command-line tools Reference". The following is a sample program that initializes networking. #include #include #include typedef int (*WpeutilFunction)( HINSTANCE hInst, HINSTANCE hPrev, LPTSTR lpszCmdLine, int nCmdShow ); int __cdecl _tmain( int argc, TCHAR *argv[] ) { HMODULE hWpeutil = NULL; WpeutilFunction InitializeNetwork = NULL; int result = 0; TCHAR szCmdLine[T(""); hWpeutil = LoadLibrary( _T("wpeutil") ); if( NULL == hWpeutil ) { _tprintf( _T("Unable to load wpeutil.dll\n") ); return GetLastError(); } InitializeNetwork = (WpeutilFunction)GetProcAddress( hWpeutil, "InitializeNetworkW" ); if( NULL == InitializeNetwork ) { FreeLibrary( hWpeutil ); return GetLastError(); } result = InitializeNetwork( NULL, NULL, szCmdLine, SW_SHOW ); if( ERROR_SUCCESS == result ) { _tprintf( _T("Network initialized.\n") ); } else { _tprintf( _T("Initialize failed: 0x%08x"), result ); } FreeLibrary( hWpeutil ); return result; } Desktop Settings When creating a customized Windows?PE application, you can replace the default wallpaper. This can be done simply by replacing the bitmap (.bmp) file at \windows\system32\winpe.bmp to a customized .bmp file. References Windows?PE API Compatibility Reference Overview Windows?PE is a lightweight, bootstrap operating system based on a subset of components from Windows Vista designed to host deployment, diagnostic, and recovery applications. As such, it contains many Windows binaries that are needed to host the APIs that are most important to these classes of application. Due to size and other design constraints, not all Windows binaries are present in Windows?PE and therefore not all Windows APIs are present or usable. This reference explains what this means to application developers, and lists the API families and system components that are present or partially present. Supported APIs Because Windows PE is based on components from Windows Vista, it contains a significant subset of Windows APIs that are published in the Windows SDK for Windows?Vista. The parameters, calling conventions, and behaviors of these supported APIs will be the same or nearly the same as on Windows?Vista, unless they are affected by the unique Windows PE environment, as explained in the "Design Considerations" section earlier in this document. Applications using only these APIs should be portable between Windows?Vista and Windows?PE. Important???If an API behaves the same as it does on Windows?Vista and as documented in the Windows SDK for Windows?Vista, it will be considered supported and can be used by applications unless otherwise noted. In some cases, a subset of the possible parameter values will be usable on Windows?PE. This may be due to the unique runtime environment such as running on a read-only medium, not having access to persistent state, or other design limitation. In this case, the API may not be supported but may still be used to accomplish a specific task if there is no other alternative. The "Windows Subsystems Reference" later in this document lists which Windows subsystems and Windows API families are present or partially present. Unsupported APIs Because many Windows components are not present in Windows?PE, many APIs are not available. They may be either completely missing because the Windows binary in which they reside is not present, or only partially present because the Windows binary in which they reside is present, but one or more binaries it depends on is not. In addition, some APIs that are present in Windows PE do not work correctly and behave differently than they do in Windows. These APIs are unsupported and must not be used because their behavior on Windows PE is undefined. Important???In general, if an API works incorrectly or not at all on Windows PE, it is not supported and must not be used, even if it resides in a binary that is included in Windows PE. The API may be failing because Windows?PE is a subset of Windows?Vista or because of the runtime design considerations unique to Windows?PE. Such failures are not considered bugs in Windows?PE. Sometimes, there may be no suitable API to accomplish a specific task. This would require application logic or possibly a different algorithm design or a redefinition of the underlying problem to find an alternate solution. Windows Subsystems Reference The following Windows subsystems are either fully present or partially present in Windows?PE. Subsystems that are partially present are indicated by an asterisk (*) and might be missing dependent binaries or registry keys. Because of this, some of their APIs may not work on Windows PE. Access Control (http://go.microsoft.com/fwlink/?LinkId=80102) ADO (http://go.microsoft.com/fwlink/?LinkId=80103) Automation (http://go.microsoft.com/fwlink/?LinkId=80104) * Boot Configuration Data (BCD) (http://go.microsoft.com/fwlink/?LinkId=80105) Certificate Enrollment Control (http://go.microsoft.com/fwlink/?LinkId=80152) * COM (http://go.microsoft.com/fwlink/?LinkId=80153) Common Controls (http://go.microsoft.com/fwlink/?LinkId=80154) Cryptography (http://go.microsoft.com/fwlink/?LinkId=80155) Debugging and Error Handling (http://go.microsoft.com/fwlink/?LinkID=80751) Device I/O (http://go.microsoft.com/fwlink/?LinkId=81228) DHCP (http://go.microsoft.com/fwlink/?LinkId=81229) Distributed File System (Dfs) (http://go.microsoft.com/fwlink/?LinkId=80151) DLLs, Processes, and Threads (http://go.microsoft.com/fwlink/?LinkId=80156) Domain Name System (DNS) (http://go.microsoft.com/fwlink/?LinkId=80157) * Dynamic Host Configuration Protocol (DHCP) (http://go.microsoft.com/fwlink/?LinkId=80150) File Systems (http://go.microsoft.com/fwlink/?LinkId=80108) GDI (http://go.microsoft.com/fwlink/?LinkId=80109) ICM (http://go.microsoft.com/fwlink/?LinkId=80101) Internet Connection Sharing and Firewall (ICSF) (http://go.microsoft.com/fwlink/?LinkId=80165) Internet Protocol Helper (IP Helper) (http://go.microsoft.com/fwlink/?LinkId=80166) Interprocess Communications (http://go.microsoft.com/fwlink/?LinkId=80169) Isolated Applications and Side-by-side Assemblies (http://go.microsoft.com/fwlink/?LinkId=80171) LSA Authentication (http://go.microsoft.com/fwlink/?LinkID=80148) LSA Policy (http://go.microsoft.com/fwlink/?LinkId=80149) Management Information Base (http://go.microsoft.com/fwlink/?LinkId=80172) * Memory Management (http://go.microsoft.com/fwlink/?LinkId=80173) Microsoft Data Access Components (MDAC) (http://go.microsoft.com/fwlink/?LinkId=80175) Microsoft Interface Definition Language (MIDL) (http://go.microsoft.com/fwlink/?LinkId=80176) National Language Support (http://go.microsoft.com/fwlink/?LinkId=80177) NetShell (http://go.microsoft.com/fwlink/?LinkId=80178) Network Provider API (http://go.microsoft.com/fwlink/?LinkId=80179) * Open Database Connectivity (ODBC) (http://go.microsoft.com/fwlink/?LinkId=80147) * Power Management (http://go.microsoft.com/fwlink/?LinkId=80107) * Remote Procedure Call (RPC) (http://go.microsoft.com/fwlink/?LinkId=80110) Security Support Provider Interface (SSPI) (http://go.microsoft.com/fwlink/?LinkId=80760) * Setup API (http://go.microsoft.com/fwlink/?LinkId=80180) Shell (http://go.microsoft.com/fwlink/?LinkId=80182) * Simple Network Management Protocol (SNMP) (http://go.microsoft.com/fwlink/?LinkId=80183) Structured Storage (http://go.microsoft.com/fwlink/?LinkId=80184) * Unicode (http://go.microsoft.com/fwlink/?LinkId=80145) UPnP APIs (http://go.microsoft.com/fwlink/?LinkId=80146) Windows API (http://go.microsoft.com/fwlink/?LinkId=80186) Windows Firewall (http://go.microsoft.com/fwlink/?LinkId=80187) Windows GDI (http://go.microsoft.com/fwlink/?LinkId=80109) Windows HTTP Services (WinHTTP) (http://go.microsoft.com/fwlink/?LinkId=80188) Windows Management Instrumentation (WMI) (http://go.microsoft.com/fwlink/?LinkId=80189) Windows Sockets 2 (http://go.microsoft.com/fwlink/?LinkId=80190) Windows System Information (http://go.microsoft.com/fwlink/?LinkId=80191) Windows User Interface (http://go.microsoft.com/fwlink/?LinkId=80192) Windows?PE Documentation For Windows?PE product documentation, please see Winpe.chm, located in the Windows?AIK or the Windows?OPK. Glossary This section contains definitions of terms used in this document. host – The hosting tools and the images of the operating system. image – The collection of files and settings (usually ACLs or other NTFS metadata) that comprises the operating system. An image can reside entirely in an image file, such as a Windows Imaging (.wim) file. offline operating system – An operating system image that is not currently running on a computer. For example, a dual-boot computer has two operating systems, A and B. If A is the currently booted operating system, then B is the offline operating system. online operating system – An operating system image that is currently running on a computer. supported API – An API that is fully implemented in the binaries that are provided by Windows?PE and is not generally affected or limited by the unique runtime characteristics of Windows?PE, such as statelessness. unsupported API – An API that is not present in the binaries that are provided by Windows?PE, is only partially present, or doesn't work according to the documentation in the Windows SDK for Windows Vista due to the unique runtime characteristics of Windows?PE.