Windows® Internals, Sixth Edition, Part 1

In turn, the loader’s LdrpApplyFileNameRedirection function, which is normally responsible for the .local and SxS/Fusion manifest redirection that was mentioned earlier, also checks for API Set redirection data whenever a new import library that has a name starting with “API-” loads (either dynamically or statically). The API Set table is organized by library with each entry describing in which logical DLL the function can be found, and that DLL is what gets loaded. Although the schema data is a binary format, you can dump its strings with the Sysinternals Strings tool to see which DLLs are currently defined:C:\Windows\System32>strings apisetschema.dll ... MS-Win-Core-Console-L1-1-0 kernel32.dllMS-Win-Core-DateTime-L1-1-0 MS-Win-Core-Debug-L1-1-0 kernelbase.dllMS-Win-Core-DelayLoad-L1-1-0 MS-Win-Core-ErrorHandling-L1-1-0 MS-Win-Core-Fibers-L1-1-0 MS-Win-Core-File-L1-1-0 MS-Win-Core-Handle-L1-1-0 MS-Win-Core-Heap-L1-1-0 MS-Win-Core-Interlocked-L1-1-0 MS-Win-Core-IO-L1-1-0 MS-Win-Core-LibraryLoader-L1-1-0 MS-Win-Core-Localization-L1-1-0 MS-Win-Core-LocalRegistry-L1-1-0 MS-Win-Core-Memory-L1-1-0 MS-Win-Core-Misc-L1-1-0 MS-Win-Core-NamedPipe-L1-1-0 MS-Win-Core-ProcessEnvironment-L1-1-0 MS-Win-Core-ProcessThreads-L1-1-0 MS-Win-Core-Profile-L1-1-0 MS-Win-Core-RtlSupport-L1-1-0 ntdll.dll MS-Win-Core-String-L1-1-0

Hypervisor (Hyper-V)

One of the key technologies in the software industry—used by system administrators, developers, and testers alike—is called virtualization, and it refers to the ability to run multiple operating systems simultaneously on the same physical machine. One operating system, in which the virtualization software is executing, is called the host, while the other operating systems are running as guests inside the virtualization software. The usage scenarios for this model cover everything from being able to test an application on different platforms to having fully virtual servers all actually running as part of the same machine and managed through one central point.

Until recently, all the virtualization was done by the software itself, sometimes assisted by hardware-level virtualization technology (called host-based virtualization). Thanks to hardware virtualization, the CPU can do most of the notifications required for trapping instructions and virtualizing access to memory. These notifications, as well as the various configuration steps required for allowing guest operating systems to run concurrently, must be handled by a piece of infrastructure compatible with the CPU’s virtualization support. Instead of relying on a piece of separate software running inside a host operating system to perform these tasks, a thin piece of low-level system software, which uses strictly hardware-assisted virtualization support, can be used—a hypervisor. Figure 3-33 shows a simple architectural overview of these two kinds of systems.

Figure 3-33. Two architectures for virtualization

With Hyper-V, Windows server computers can install support for hypervisor-based virtualization as a server role (as long as an edition with Hyper-V support is licensed). Because the hypervisor is part of the operating system, managing the guests inside it, as well as interacting with them, is fully integrated in the operating system through standard management mechanisms such as WMI and services. (See Chapter 4 for more information on these topics.)

Finally, apart from having a hypervisor that allows running other guests managed by a Windows Server host, both client and server editions of Windows also ship with enlightenments, which are special optimizations in the kernel and possibly device drivers that detect that the code is being run as a guest under a hypervisor and perform certain tasks differently, or more efficiently, considering this environment. We will look at some of these improvements later; for now, we’ll take a look at the basic architecture of the Windows virtualization stack, shown in Figure 3-34.

Figure 3-34. Windows Hyper-V architectural stack

Partitions