|
Kernel Enhancements for Windows Vista and Windows Server Longhorn -
Kernel Enhancements for Windows Vista and Windows Server Longhorn
Draft Version 0.9 - May 2006
Abstract
Microsoft has made many enhancements to the kernel of the Microsoft® Windows Vista™ and Microsoft Windows Server™ Code Name "Longhorn" operating systems. This paper provides an overview and references to other sources of information for some of the new features and changes in the kernel for these versions of Microsoft Windows®.
Draft version 0.9 of this article replaces draft version 0.5, which was published in September 2005. Draft version 0.9 has been updated to include additional information about heap management, code signing, protected processes, dynamic-link library (DLL) loader enhancements, and thread pool enhancements. This paper will be updated as more information becomes available.
This information applies for the following operating systems:
Microsoft Windows Vista
Microsoft Windows Server Longhorn
The current version of this paper is maintained on the Web at:
http://www.microsoft.com/whdc/system/vista/kernel-en.mspx
Contents
Introduction 3
Memory and Heap Management 3
Memory Manager 3
Heap Manager 4
Management Mechanisms 5
Registry 5
Services Model 5
Windows Hardware Error Architecture 6
Security 7
Kernel Patch Protection 7
Protected Processes 7
Code Signing and Code Integrity 8
Other Application Support Mechanisms 9
Dynamic-Link Library Loader 9
Thread Pool 10
Support for Hardware Innovation 11
Dynamic Hardware Partitioning 11
ACPI 11
PCI and PCI Express 12
Boot Environment Enhancements 12
Power Management 13
Plug and Play 14
Hardware Abstraction Layer 15
Resources 15
Disclaimer
This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.
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, IMPLIED OR STATUTORY, 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, email address, logo, person, place or event is intended or should be inferred.
© 2005-2006 Microsoft Corporation. All rights reserved.
Microsoft, Win32, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Introduction
Microsoft has made substantial enhancements to the kernel at the core of the Microsoft® Windows Vista™ and Microsoft Windows Server™ code name "Longhorn" operating systems. Kernel improvements are significant because the kernel provides low-level operating system functions, including thread scheduling, interrupt and exception dispatching, multiprocessor synchronization, and a set of routines and basic objects that the remainder of the operating system uses to implement higher level constructs.
This paper describes kernel enhancements for Windows Vista and Windows Server Longhorn in several key areas:
Memory and heap management.
Management mechanisms, including the registry, the services model, and the new Microsoft Windows® Hardware Error Architecture (WHEA).
Security features, including kernel patch protection, code signing and code integrity, and support for protected processes.
Other application support mechanisms, including dynamic-link library (DLL) loader and the thread pool.
Support for hardware innovation, including dynamic partitioning, ACPI 2.0, PCI, PCI Express, and boot environment enhancements.
Power management.
Plug and Play.
Hardware abstraction layer (HAL).
For many of these areas, this paper summarizes more detailed information from other sources that are referenced in each section. The information in this paper applies to both Windows Vista and Windows Server Longhorn. Areas such as dynamic hardware partitioning that apply only to Windows Server Longhorn are specifically noted.
This paper is for system and peripheral designers, driver developers, firmware developers, and application developers who are creating products for these operating systems. It assumes that the reader is familiar with related concepts and issues for Windows Server 2003 and Windows XP.
Memory and Heap Management Memory Manager
Significant enhancements were made throughout the memory manager in Windows Vista and Windows Server Longhorn. Changes include:
Improvements to dynamic system address space, including on-demand allocation of system virtual address space and kernel page table pages, and support for very large registries.
Enhanced support for nonuniform memory architecture (NUMA) systems and systems with large pages, including additional device driver and Microsoft Win32® NUMA application program interfaces (APIs).
Advanced video model support through a new mapping type called rotate virtual address descriptors (VADs).
I/O and section access improvements, including pervasive prefetch-style clustering for all types of page faults and system cache read-ahead.
General performance improvements, including translation buffer optimizations and improvements to internal data structures and algorithmic performance.
Microsoft Terminal Services improvements, including new Terminal Services session objects.
Robustness and diagnosability improvements, including reduced data loss from failed in-page operations.
Developers who write NUMA-aware applications or drivers that run on NUMA systems may want to modify their code to take advantage of new and expanded NUMA-related APIs. Other memory management changes should be transparent to both applications and drivers.
Memory Manager Resources
The Memory Manager in Windows Server 2003 and Windows Vista
http://go.microsoft.com/fwlink/?LinkId=67468
Windows Memory Management
http://go.microsoft.com/fwlink/?LinkId=67469
Heap Manager
The heap manager underwent significant changes in Windows Vista and Windows Server Longhorn. Although most of these changes should be transparent to developers, both end users and developers will benefit from improved performance, security, and reliability of applications.
Performance. The heap manager takes advantage of recent changes in the hardware architectures and the growing popularity of 64-bit and symmetric multiprocessing (SMP) systems to provide better performance and scalability on these systems.
In particular, previous versions of Windows support the low-fragmentation heap (LFH) that provides significant scalability improvements on multiprocessor systems, but applications could not take advantage of these improvements in a transparent manner. The heap manager in Windows Vista introduces the concept of automatic tuning, which detects allocation patterns at run time, automatically chooses the right mode, and provides lazy initialization whenever applicable to improve overall system and application performance.
Other significant improvements include rearchitecture of internal algorithms and data structures that handle segment management. As a result, the heap manager provides better fragmentation management, better scalability, and lower overhead for large heaps, especially for 64-bit server applications. In addition, the efficiency of lookup algorithms has been improved from O(n) to O(1).
Security and reliability. Security has been a priority for the heap manager in earlier versions of Windows, but the attack landscape has changed considerably. The heap manager in Windows Vista has significant improvements not only to mitigate against current exploits and attack vectors, but also to proactively fix potential target areas for future attacks.
Some of the changes in this area include block metadata encoding, integrity checks on block headers, and random heap rebasing. In addition, the heap manager provides improved and early detection of heap corruptions and the ability for applications to terminate when heap corruption occurs, thereby deterring "brute force" attacks that exploit a vulnerability.
Management Mechanisms
Improved management mechanisms in Windows Vista and Windows Server Longhorn include changes to the registry, the services model, and WHEA.
Registry
Changes to the Windows registry include several significant new innovations:
Transaction support for registry operations. Transaction support allows the registry to provide “all or none” semantics for a group of registry operations. The registry can also collaborate with other resource managers in the system such as transactional NTFS (TxF) to enable transactions that span file system and registry operations.
Optimizations to reduce the possibility of registry corruption. One such mitigation mechanism protects memory pages from accidental corruption by other components by marking pages as read only. When the registry must write data to one of these pages, its access mode is changed from read-only to read/write. After the write operation is completed, the page's access mode reverts to read-only.
Registry filtering that is consistent with the file system filtering model. The registry filtering model was enhanced to be consistent with the file system filtering model. The new model adds support for redirecting calls and modifying parameters in addition to the existing support for monitoring and blocking calls.
Similar to the file system filtering model, the new registry filtering model allows filters to register at specific positions on the filtering stack by introducing the concept of altitudes for filter registrations. Developers of registry filter drivers for Windows Vista should register their minifilter altitudes with Microsoft at the location listed in "Windows Registry Allocation" at the end of this section.
Registry virtualization support. Registry virtualization support enables legacy applications to run in non-administrator accounts. Registry virtualization isolates write operations that have a global impact to a per-user location. This redirection of writes is transparent to applications and is applicable only to operations on keys in the software hive (HKLM\Software). All other keys are unaffected by virtualization.
Windows Registry Resources
Minifilter Altitude Allocation
http://go.microsoft.com/fwlink/?LinkId=66682
Services Model
The Windows Services model has been enhanced to improve the performance, security, and manageability of services. Most of these changes work as a natural extension of the existing model, making it easy for legacy services to leverage these changes. In most cases, legacy services can leverage the new platform infrastructure without changing code. Enhancements include:
Delayed start type for services. To address the problem of the growing number of auto-start services and their negative impact on boot performance, there is a new start type for services that do not need to start early in boot: delayed start. This new start type improves boot performance by starting services shortly after boot and yet retains the “unattended start” behavior.
Platform support for sandboxing and protection from user-mode attacks. In an effort to reduce the attack surface exposed by services, the service control manager (SCM) provides platform support for sandboxing services and running them with least privilege by using the Windows service hardening infrastructure. In addition, services are also protected from user interface attacks by running them in Session 0 and isolating this session from other user sessions.
Manageability improvements. The service model provides a new notification API to track service state changes. These notifications work both locally and remotely, and remove the requirement for services or clients to use polling loops to monitor state changes. In addition, support for failure actions has been extended to provide recovery actions for non-crash failures.
Windows Services Resources
Services in Windows Vista
http://go.microsoft.com/fwlink/?LinkId=66644
Impact of Session 0 Isolation on Services and Drivers in Windows Vista
http://go.microsoft.com/fwlink/?LinkId=67470
Service Functions
http://go.microsoft.com/fwlink/?LinkId=67471
Windows Hardware Error Architecture
According to Microsoft’s Online Crash Analysis (OCA) data, approximately 7 to 10 percent of all reported crashes are due to some type of hardware error, such as processor, memory, or cache errors. Operating systems earlier than Windows Vista and Windows Server Longhorn do not expose sufficient error information to determine the root cause of these types of crashes from OCA data. Issues include the lack of a common error record format, disparate sources of errors, disparate signaling and reporting mechanisms, the fact that existing error management implementations are proprietary, and other factors.
Windows Server Longhorn implements WHEA, a common operating system/hardware error-handling infrastructure that builds on PCI Express Advanced Error Reporting (AER). WHEA provides rich hardware error data and helps reduce mean time to recovery through the following mechanisms:
A generic mechanism for error source discovery.
A common error-record format for operating system and hardware errors.
A common error-handling flow for operating system and hardware errors.
A persistence mechanism for operating system error records.
A common hardware error-eventing model based on Event Tracing for Windows (ETW) for management applications.
WHEA Resources
WHEA – Windows Hardware Error Architecture
http://go.microsoft.com/fwlink/?linkid=67472
Error Management Solutions Synergy With WHEA [WinHEC 2005]
http://go.microsoft.com/fwlink/?LinkId=67473
Windows Hardware Error Architecture [WinHEC 2005]
http://go.microsoft.com/fwlink/?LinkId=67474
Security Kernel Patch Protection
Kernel patch protection was first implemented in Windows Server 2003 SP1 x64–based systems and Windows XP for x64–based systems. No significant changes have been made to kernel patch protection in Windows Vista and Windows Server Longhorn. However, because this security feature is still relatively new, it is discussed in this paper to increase awareness of the feature and its potential impact on driver and application developers.
Windows Server 2003 SP1 and later versions of Windows for x64-based systems do not allow the kernel to be patched except through authorized Microsoft–originated hot patches. For compatibility with Windows for x64–based systems, kernel-mode components must avoid the following practices:
Modifying the system services tables, for example, by hooking KeServiceDescriptorTable.
Modifying the Interrupt Dispatch Table (IDT).
Modifying the Global Descriptor Table (GDT).
Using kernel stacks that are not allocated by the kernel.
Patching any part of the kernel (detected on AMD64-based systems only).
If code attempts to modify any of these resources, kernel patch protection generates a bugcheck 109. Note that the list of protected resources may increase over time.
Patch protection is disabled when a debugger is physically attached to the system. Therefore, vendors should test their drivers and applications without a debugger attached to ensure that their code can function properly in the presence of patch protection.
Kernel Patch Protection Resources
Patching Policy for x64-based Systems
http://go.microsoft.com/fwlink/?LinkId=67478
Kernel Patch Protection: Frequently Asked Questions
http://go.microsoft.com/fwlink/?LinkId=67479
Protected Processes
The Windows Vista operating system introduces a new type of process, called a protected process, that enhances support for digital rights management functionality in Windows Vista and Windows Longhorn Server. These protected processes exist alongside typical processes in Windows Vista.
Differences between a Typical Process and a Protected Process. The primary difference between a typical Windows process and a protected process is the level of access that other processes in the system can obtain to protected processes.
In earlier versions of Windows operating systems, before Windows Vista, the process model allows a parent process to acquire a handle to and manipulate the state of any child process it creates. Similarly, processes that are created by users with sufficient privileges (that is, a system administrator) can access and manipulate the state of all processes on the system. This behavior remains unchanged for typical Windows processes. However, the level of access to protected processes and to threads within those processes is significantly more constrained in Windows Vista.
Significant Functionality Constraints of Protected Processes. Developers who are accustomed to interacting with typical Windows processes will notice the following significant differences in interacting with protected processes. A typical Windows process cannot take the following actions on a protected process:
Inject a thread into another process. A call to CreateRemoteThread requires a handle that must have the PROCESS_CREATE_THREAD, PROCESS_QUERY_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_WRITE, and PROCESS_VM_READ access rights
Debug an active protected process. A call to DebugActiveProcess requires PROCESS_ALL_ACCESS.
Which Applications Can Create a Protected Process. Currently only the Windows Protected Media Path can create protected processes.
Vendors of any product that monitors and reports on processes in the system (such as software debuggers, anti-malware applications, and so on) should be aware of the specific constraints on protected processes and should test their software on systems that are running protected processes.
Protected Process Resources
Protected Processes
http://go.microsoft.com/fwlink/?LinkId=69749
Process Security and Access Rights
http://go.microsoft.com/fwlink/?LinkId=67480
Code Signing and Code Integrity
For Windows Vista and later versions of the Windows family of operating systems, kernel-mode software must have a digital signature to load on x64-based computer systems. Certain configurations of x86 systems require kernel-mode software to have digital signatures to access next-generation premium content, depending on content protection policy.
Digital Signatures
Digital signatures allow an administrator or an end user who is installing Windows-based software to know whether a legitimate publisher has provided the software package.
Windows Vista relies on digital signatures on kernel-mode code to increase the safety and stability of the Microsoft Windows platform and enable new customer experiences with next generation premium content:
Drivers must be signed for devices that stream protected content. This includes audio drivers that use Protected User Mode Audio (PUMA) and Protected Audio Path (PAP), and video device drivers that handle protected video path-output protection management (PVP-OPM) commands.
Unsigned kernel-mode software does not load and does not run on x64-based systems.
Even users with administrator privileges cannot load unsigned kernel-mode code on x64-based systems. This applies for any software module that loads in kernel mode, including device drivers, filter drivers, and kernel services.
The mandatory kernel-mode code signing policy applies to all kernel-mode software on x64-based systems that are running Windows Vista. However, Microsoft encourages publishers to digitally sign all software, including device drivers for both 32-bit and 64-bit platforms. Windows Vista performs kernel-mode signature verification on x86-based systems to support protected media content. Kernel-mode driver signatures are not mandatory for 32-bit systems.
Code Integrity
Code integrity enforces the mandatory code-signing policy for kernel-mode drivers on x64-based systems. Code integrity also verifies the integrity of all code that is loaded into a protected process. Images that fail image validation are not loaded because such a failure indicates that they have been corrupted (either inadvertently or maliciously by a virus or hack). System catalogs are used to store image or page hashes that are used for validation.
Code integrity features include the following:
The operating system boot loader (Winload) verifies all boot-critical drivers including the HAL and NTOS kernel.
Code integrity functionality in the executive (ntoskrnl) verifies image hashes for every driver that is loaded into kernel mode by using image hashes. This verification is done only on x64 systems.
Page hashes are only used by code integrity in the kernel to verify user-mode binaries that implement cryptographic functions, or binaries that are loaded into a protected process that is used for playback of high-definition media content.
System catalogs (nt5.cat) that contain image hashes are used to verify kernel code. Page hashes in nt5ph.cat and ntpe.cat are used to verify a specific set of user-mode binaries.
Code Signing and Code Integrity Resources
Digital Signatures for Kernel Modules on x64-based Systems
Running Windows Vista
http://go.microsoft.com/fwlink/?linkid=67481
Driver Signing for Kernel-Mode Software for x64-based Systems:
Frequently Asked Questions
http://go.microsoft.com/fwlink/?linkid=67482
Other Application Support Mechanisms Dynamic-Link Library Loader
The user-mode dynamic-link library (DLL) loader plays a fundamental role in process and thread creation. Every time a process or thread is created, the loader is invoked to complete the following tasks that are related to DLLs and that are required by the process or thread in question:
Determine appropriate DLL load order and resolve dependencies
Load all required DLLs
Unload DLLs when they are no longer needed
The Windows Vista DLL loader has undergone a number of improvements, including:
Improved process creation time performance. A significant portion of process creation time is spent resolving DLL dependencies and processing DLL imports.
Improvements to import processing algorithms have reduced processing time by an impressive factor of 1000x in some scenarios (from ~800,000 cycles to ~800 cycles). End-to-end process creation times were reduced by as much as 10 percent for some of the more DLL-heavy applications.
Fewer reboots resulting from system DLL servicing. In earlier versions of Windows operating systems, before Windows Vista, whenever a system or core DLL was updated by using a service pack, security patch, or similar mechanism, a reboot was required. The reboot was required because no mechanism could identify which system services had loaded the DLL in question. Therefore, the entire system had to be rebooted to ensure that the earlier version of the DLL was unloaded and the updated DLL was loaded instead.
Enhanced bookkeeping techniques in the Windows Vista loader allow the system to maintain a complete list of services that have loaded a particular DLL. When that DLL is updated, the system can identify and restart only the specific services that are using the DLL to be updated, instead of rebooting the entire system. This change helps to decrease downtime, thus increasing the availability of the system even while it is being upgraded or serviced.
Note that some system DLLs, including NTDLL.dll and kernel32.dll, still require a reboot when they are being serviced.
Best Practices for Creating DLLs
http://go.microsoft.com/fwlink/?LinkId=69750
Thread Pool
A thread pool is a collection of system-managed worker threads that efficiently execute asynchronous callbacks on behalf of the developer. The thread pool can be thought of as a smart entity that manages work items, timed executions, asynchronous I/O, and so on while exposing a simple interface to the developer. The thread pool is considered to be "smart" because it can adapt to demands on system resources and respond by dynamically altering scheduling policy, shrinking or growing the pool, and so on.
The thread pool in Windows Vista is significantly enhanced to improve reliability, performance, and API simplicity. New thread pool functions give the developer a higher degree of control and flexibility while hiding the complexity of synchronization, reference counting and so on, which makes the thread pool much easier to program. Some specific examples of Windows Vista thread pool enhancements include:
Cleanup groups. Cleanup groups are container objects that can be associated with a group of threadpool callback-generating objects, which creates a single synchronization point for cleanup operations as a unit. Cleanup groups introduce the ability to clean up pending thread pool requests on process shutdown.
Multiple pools per process. The thread pool also supports multiple thread pools per process, each of which is scheduled independently. This significantly improves responsiveness as well as code isolation.
Performance. The thread pool is optimized to provide the best possible processor usage and to reduce pressure on system memory. Thread recycling, maintaining a number of running threads that is proportional to the number of processors, smart load balancing, and work assignment are used to gain maximum performance from the thread pool.
Thread Pool Resources
Thread Pooling
http://go.microsoft.com/fwlink/?linkid=67483
Thread Pools
http://go.microsoft.com/fwlink/?LinkId=67484
Support for Hardware Innovation
Support for hardware innovation in Windows Server Longhorn includes dynamic hardware partitioning. Both Windows Vista and Windows Server Longhorn also support ACPI, PCI, and PCI Express.
Dynamic Hardware Partitioning
Dynamic hardware partitioning allows systems to be partitioned at a hardware level to run multiple operating systems instances on a single server. In addition, on dynamic hardware partitioning–capable systems, I/O devices, memory, and processors can be dynamically added and removed from, to, and between partitions without powering down the system.
Windows Server 2003 already supports hot add of memory on x86-based, x64-based, and Itanium-based systems.
For compliant hardware platforms, Windows Server Longhorn supports hot add of processors and memory plus hot replace of processors and memory on x64-based and Itanium-based systems. Hot add of I/O host bridges is also planned.
System manufacturers, hardware vendors, firmware vendors, and driver developers should follow Microsoft guidelines for developing products for systems and components that support dynamic hardware partitioning.
Dynamic Hardware Partitioning
http://go.microsoft.com/fwlink/?linkid=67485
Dynamic Partitioning in Windows Longhorn [WinHEC 2005]
http://go.microsoft.com/fwlink/?linkid=67486
ACPI
Windows Vista and Windows Server Longhorn continue to advance support for the ACPI specification, including selected features from ACPI 3.0:
Complete support for ACPI 2.0 processor performance objects.
ACPI 3.0 processor domain dependency and throttling objects.
Operating System Capabilities (_OSC) method invocation to facilitate transitions to native support of PCI-E features.
ACPI General Purpose Event (GPE) block device support.
New firmware tables API.
ACPI Resources
ACPI / Power Management – Architecture and Driver Support
http://go.microsoft.com/fwlink/?linkid=67487
PCI and PCI Express
Windows Vista and Windows Server Longhorn support a significant number of features in the PCI Express 1.1 specification, including:
Extended configuration space.
Segments.
PCI Express registers, including capability registers, save and restore of configuration settings, and BIOS configurations.
Device serial numbers.
PCI Express hierarchy.
Message-signaled interrupts (MSI and MSI-X).
Hot plug.
Native power management events.
Active-state power management.
Advanced Error Reporting (AER).
System manufacturers, hardware vendors, and driver developers should be familiar with these features as described in the PCI Express 1.1 specification and should design their products to comply with that specification.
PCI and PCI Express Resources
PCI Express Update for Windows Longhorn [WinHEC 2005]
http://go.microsoft.com/fwlink/?linkid=67488
PCI Multi-Level Rebalance in Windows Vista
http://go.microsoft.com/fwlink/?LinkId=67489
Supporting Subtractive PCI-to-PCI Bridges in Windows
http://go.microsoft.com/fwlink/?LinkId=67490
Active State Power Management in Windows Vista
http://go.microsoft.com/fwlink/?LinkId=67491
Firmware Allocation of PCI Device Resources in Windows
http://go.microsoft.com/fwlink/?linkid=67492
_OSC Method and PCI Express in Windows Vista
http://go.microsoft.com/fwlink/?linkid=67493
PCI, PCI-X, and PCI Express Frequently Asked Questions
http://go.microsoft.com/fwlink/?linkid=67494
PCI and PCI Express – Architecture and Driver Support
http://go.microsoft.com/fwlink/?LinkId=67495
Boot Environment Enhancements
Microsoft has completely reengineered the boot environment for Windows Vista to address the increasing complexity and diversity of modern hardware and firmware. A key aspect of this reengineering is a new firmware-independent data store called boot configuration data (BCD).
BCD is designed to handle boot environment data for any type of system. It provides access to the information and applications that Windows Vista and later versions of Windows use to load the operating system or run boot applications such as memory diagnostics. Some key characteristics include:
BCD provides clean and intuitive structured storage for boot settings.
BCD abstracts the underlying data store, making BCD independent of the underlying firmware or processor architecture. BCD currently handles both PC/AT and EFI systems, and can be readily extended to accommodate future improvements in hardware and firmware.
BCD is available at run time as well as during the boot process.
BCD provides improved security over boot.ini. It allows secure lockdown of the storage format and flexible assignment of the rights that are required for changing boot settings. BCD is stored in a binary format and cannot be edited directly.
BCD is designed to handle systems with multiple versions and configurations of Windows, including versions earlier than Windows Vista.
BCD is the only boot data store that is required for Windows Vista and later versions of Windows. BCD supports the loading of earlier versions of Windows, but they are ultimately loaded by Ntldr.exe and must still store their boot options in a boot.ini file.
Instead, users can interact with BCD through several tools. Developers can programmatically manipulate a BCD store through the BCD Windows Management Instrumentation (WMI) provider that can be used for both local and remote management of BCD stores independent of the underlying firmware.
Boot Environment Resources
Boot Configuration in Windows Vista
http://go.microsoft.com/fwlink/?LinkId=67496
BCD Reference
http://go.microsoft.com/fwlink/?linkid=67497
Boot Configuration Data (BCD)
http://go.microsoft.com/fwlink/?LinkId=67498
Introduction to Boot Options
http://go.microsoft.com/fwlink/?LinkId=67500
Power Management
Windows Vista and Windows Server Longhorn continue to advance and adopt power management technologies with a rich set of new features and capabilities:
Simplified power policies that make it easier for users to match usage patterns to the appropriate power policy.
A new hybrid sleep state, which combines aspects of standby (suspend to RAM) and hibernate (suspend to disk) to protect the user’s data while in standby.
Windows Direct Experience, which provides support for starting a PC directly to a specific media experience (for example, to launch directly into a media player when a "media" button is pushed).
A new "away mode" that supports media-oriented PC usage models.
Reliable power management transitions.
Extensive diagnostic tracing and error reporting infrastructure.
Comprehensive group policy control for power management settings.
Improved battery meter that provides simple, quick access to basic power management settings.
Significant improvements to the overall power management user interface and user experience.
Power Management Resources
Longhorn Power Management Update [WinHEC 2005]
http://go.microsoft.com/fwlink/?linkid=67501
Direct Application Launch from System Startup on Windows Vista
http://go.microsoft.com/fwlink/?linkid=67502
Measuring System Resume Performance on Windows Vista
http://go.microsoft.com/fwlink/?linkid=67503
Integrating Drivers and Applications with Windows Power Management [WinHEC 2005]
http://go.microsoft.com/fwlink/?linkid=67504
Windows Vista: Developing Power-Aware Applications [PDC 2005]
http://go.microsoft.com/fwlink/?linkid=67505
ACPI / Power Management - Architecture and Driver Support
http://go.microsoft.com/fwlink/?linkid=67506
Plug and Play
Kernel-mode Plug and Play enhancements in Windows Vista and Windows Server Longhorn include the following features:
Support for PCI multilevel rebalance.
Partial arbitration of resources to support PCI subtractive bridges.
Asynchronous device start and enumeration operations to speed system startup.
Support for setting and retrieving custom properties on a device.
An enhanced ejection API to allow the caller to determine if and when a device has been successfully ejected.
Diagnostic tracing to facilitate improved reliability.
Plug and Play Resources
PCI Multi-Level Rebalance in Windows Vista
http://go.microsoft.com/fwlink/?linkid=67507
Supporting Subtractive PCI-to-PCI Bridges in Windows
http://go.microsoft.com/fwlink/?LinkId=67508
Plug and Play - Architecture and Driver Support
http://go.microsoft.com/fwlink/?LinkId=67509
Hardware Abstraction Layer
The HAL for Windows Vista and Windows Server Longhorn supports Extensible Firmware Interface (EFI) run-time calls for reading the real-time clock and for getting and setting nonvolatile random access memory (NVRAM) variables on Itanium-based systems.
Hardware Abstraction Layer Resources
Firmware Design and Boot Environment
http://go.microsoft.com/fwlink/?LinkId=67510
EFI and Windows Vista
http://go.microsoft.com/fwlink/?LinkId=67511
Resources
WHDC
Technical information, development and testing kits, and other essential resources for system and device manufacturers, driver developers, and other professionals who create products that run with Windows.
http://go.microsoft.com/fwlink/?LinkId=67512
Windows Driver Kit (WDK)
http://go.microsoft.com/fwlink/?LinkId=67513
Microsoft Windows XP Professional Resource Kit, Second Edition
http://go.microsoft.com/fwlink/?linkid=67514
Microsoft Windows Server 2003 Deployment Kit: A Microsoft Resource Kit
http://go.microsoft.com/fwlink/?linkid=67515
Available through MSDN Professional subscription or through Microsoft Press
Draft Version 0.9 - May 2006
© 2005-2006 Microsoft Corporation. All rights reserved.
|
