The game must be visible within Games Explorer (the Games folder) on Windows Vista and Windows 7. When selected, the game must also display correct meta data, which includes publisher, developer, release date, version, Windows Experience Index scores, rating (if applicable), and associated hyperlinks.

If the game is digitally distributed through an online game service, then the service provider should also appear in Games Explorer. To ensure proper handling of the provider and to enable use of RSS feeds, version 2 of the schema for game definition files (GDFs) should be used. (For more information about GDFs, see Additional Information.)

In addition, game installers must observe the following rules when they run on Windows Vista and Windows 7:

• The installation must not create a shortcut to launch the game on the desktop, in the Start menu, or in any other location.

• Tasks and shortcuts for removal must not be created.

• Users must be able to remove the game by using Programs and Features in Control Panel on Windows Vista and Windows 7, or Add or Remove Programs in Control Panel on Windows XP.

On Windows XP, and on previous versions of Windows, the game installer is free to create program groups, desktop icons, or shortcuts as needed.

Windows Games Explorer is similar in concept to the Windows XP folders My Documents or My Pictures. The idea is to centralize similar content in one place and allow for easier organization and context-sensitive activities. Games Explorer extends the My Documents or My Pictures concept by allowing richer organization and control over games. Games Explorer allows gamers to view, organize, and interact with all the games installed on their systems. It also allows game publishers to communicate important game information more effectively. The system is data-driven, making it easy for a game publisher to update game information over the life of the product.

Integration with Games Explorer requires that you author a game definition file (GDF), which is an XML text file that is embedded within a binary file (an executable file or a DLL) as a resource, along with a Windows icon. The game must then be registered with Games Explorer. The GDF also enables the exposure of supplied information such as the game title, publisher, developer, links to websites and optional tasks. Note that support tasks can be only links to Web sites, but play tasks can be used for optional support tasks as well.

Games Explorer can make use of a thumbnail bitmap image, but it is recommended that, instead, you provide a Windows icon resource with large icons (256×256). The icon resource should include image sizes of 256×256 48×48, 32×32, and 16×16 in both 24-bit (True Color) and 8-bit (256) color depths. The icon editor provided in Visual Studio 2008 and 2010 supports these large icon formats, as does IconWorkshop Lite.

Details on integrating with Windows Games Explorer are provided in the DirectX SDK. The DirectX SDK includes a game definition file (GDF) editor, as well as an example GDF that is included in GDFExampleBinary, a sample. Another sample, GameUxInstallHelper, provides routines for integrating the required functionality into existing installation systems. The Game Definition File Validator (gdftrace.exe) provides debugging support for evaluating a GDF. Also see "Windows Games Explorer Integration" in the DirectX SDK Documentation for C++.

Windows 7 introduces support for the second version of a schema for GDF files. The new version includes a simplified method for creating play tasks and support for update notifications, game service providers, game statistics, and RSS feeds for game service providers. The latest version of GameUxInstallHelper handles all of the registration and legacy support needed to use a version 2 GDF file with Windows Vista. Use the tools and sample code from the DirectX SDK from August 2009 or later. Using a version 2 GDF file is recommended to enable support for RSS feeds, game statistics, and update notifications. Also, see the samples ProviderGDFExampleBinary and GameStatisticsExample.

On Windows Vista Business Edition, Windows 7 Professional Edition, and Enterprise Edition of both Windows Vista and Windows 7, the Games link on the Start menu is hidden. Games Explorer is still available on the Start menu by clicking All Programs, and then clicking Games.

For associated applications that are installed with your game, but not themselves games, you are free to create Start menu program groups, shortcuts, and desktop icons on all versions of Windows, including Windows Vista and Windows 7. Such associated applications should pass applicable Games for Windows requirements; for details, see Guidelines for Game Middleware Products. Game services are encouraged to register with Games Explorer as a Game Provider for Windows 7.

Games must fully support Windows Family Safety by adhering to the following rules:

• Games must not require that the user have administrative credentials to play. Installation, patching, and removal can require administrative credentials, subject to the requirements in section 3. (Related to this is requirement 2.1, Follow User Account Control Guidelines.)

• Games rated by Windows-supported ratings boards, such as ESRB and PEGI, must include their assigned ratings information in their game definition file (GDF). All available ratings data must be included in every localized version of the GDF, as well as in the language-neutral version.

• Games must list their executables in the GDF to provide a good user experience for General Application Restrictions, unless the game uses an anti-piracy technology that creates randomly named executables at runtime.

• Games must call the VerifyAccess method of the Games Explorer interface during startup, if available, and exit if it returns *pfHasAccess as FALSE.

All games must execute within the context of a Standard User account to allow accounts that are controlled by Windows Parental Controls to play the game. Parents want the ability to monitor and control their children's access to games. Moreover, numerous industry, government and advocacy groups desire better ways to allow parents to monitor and control the games to which their children are exposed. In conjunction with the architecture offered by Games Explorer, Microsoft provides parents this ability through Windows Parental Controls.

Even for games that do not participate in a ratings board program, requiring elevated privileges creates a poor play experience for the majority of user accounts. This is particularly the case if Parental Controls are enabled, which would require the parent to enter the administrator password every time the game is launched.

The Windows Parental Controls system allows parents to select the ratings that they believe are appropriate for their children. Parental Controls support many of the worldwide ratings systems. Parental Controls also allow parents to restrict access to games based on Content Descriptors (if the applicable rating system supports them) and to allow or disallow access to individual games.

The default choice of rating system for Windows Parental Controls is based on the system's locale setting, but can be modified by the user in Regional and Language Options in Control Panel. Therefore, every supported language should provide all available ratings data so that the user has the freedom to select whatever ratings board they desire.

Games without a rating must still meet the requirements to support play as a Standard User and to call VerifyAccess. Such games default to the Unrated category, display the text "No Rating Provided" in Games Explorer, and are subject to the Game Restrictions setting in Parental Controls for unrated games. The default Restrictions setting is Allow.

Rating information in the GDF will be ignored if the containing binary is not properly Authenticode signed. See requirement 2.3.

The Game Definition File Editor in the DirectX SDK includes all supported ratings systems and will correctly replicate this information to all localized versions of the GDF, as well as a language neutral version. The GDFTrace tool will decode and verify all ratings information present. Use the August 2009 version or later of these tools.

The GDF for a game provider typically contains no rating information, and it is subject to the settings for unrated content.

Operating System	Supported rating systems
Windows Vista	CERO (Japan) ESRB (USA) OFLC (Australia) PEGI (Europe) PEGI Finland (deprecated) PEGI Portugal PEGI/BBFC (United Kingdom) USK (Germany)
Windows Vista with a service pack	Service packs for Windows Vista add support for the following: GRB (South Korea) ESRB "Mild" variant content descriptors
Windows 7	Windows 7 supports the ratings systems supported by Windows Vista and adds support for the following: CSRR (Taiwan)

GRB and CSRR ratings data are ignored on versions of operating systems without support for them. The PEGI (Finland) variant is now deprecated in favor of the standard PEGI (Europe) rating system.

For more information about making a game compatible with standard user privileges, see the DirectX SDK article User Account Control for Game Developers.

See requirement 1.1 for more details on the game definition file (GDF).

Games that support gamepad controllers must support the Xbox 360 Controller for Windows using the XInput API. If DirectInput peripherals are also supported, then DirectInput can also be used. However, XInput must be the default API if an Xbox 360 compatible device is used.

All references to common controller triggers and buttons must use the Xbox 360 names. See the Xbox 360 Common Controller for Windows Terminology list for details.

Controller vibration must be turned off when the game is in a paused or suspended state.

Mouse/keyboard control cannot be fully disabled at any time. At a minimum, an option to return to game menus must be available.

This requirement gives gamers freedom of choice to use either the Xbox 360 controller or the keyboard and mouse, depending on which input method is more natural and intuitive interface.

This requirement does not apply to games that use only the mouse and/or the keyboard.

We recommend that menu navigation be implemented to use the widely accepted standard controller buttons:

• A - Accept

• B - Cancel

• Start - Accept or pause

• Back - Cancel, back one screen or up a menu level

See the DirectX SDK Documentation on XInput for details.

The topic XInput and DirectInput discusses issues with using both APIs at the same time.

It is recommended that DirectInput not be used to implement keyboard or mouse controls. Keyboard and mouse controls should only be implemented using Windows messages and Win32 APIs. For details on getting high-resolution mouse movement information without using DirectInput, see Taking Advantage of High-Definition Mouse Movement.

The game must support at least the following aspect ratios and associated screen resolutions:

• 4:3 normal (800×600 or 1024×768)

• 16:9 widescreen (1280×720)

• 16:10 widescreen (1152×720 or 1680×1050 or 800×480)

For screen resolution configuration and detection, the game must adhere to the following rules:

• The game uses the desktop resolution of the display device by default if it is a supported resolution. The desktop aspect ratio must be used as a search criterion if the game chooses a different default resolution.

• The game must prompt the user to confirm new display settings when a change is made. If the user does not accept within 15 seconds, the display must revert to the previous setting.

• The game must not stretch pixels or center a 4:3 render window to support widescreen aspect ratios. However, letterboxing is acceptable.

With the Windows 3D desktop, a particular aspect ratio or resolution cannot be assumed, because of the following factors:

• Support for high-detail displays.

• Increased market share of widescreen monitors.

• HDTV deployments for Windows Media Center.

• Accessibility requirements.

Ideally, the game defaults to the native aspect ratio of the display. However, obtaining this information reliably can be a challenge, so as a more general solution the game can assume that the desktop is running at the native aspect ratio. The desktop resolution can be obtained by calling EnumDisplaySettings with ENUM_REGISTRY_SETTINGS.

For more details, see the Aspect Ratio and Widescreen sections of the DirectX SDK article Introduction to the 10-Foot Experience for Windows Game Developers.

If the game uses Direct3D, then the minimum version supported must be Direct3D 9, and Direct3D must be the default renderer selected.

The Windows Vista and Windows 7 core graphics architecture is designed around Direct3D. Direct3D 8 and earlier versions are supported by remapping legacy interfaces.

Use of versions of Direct3D newer than Direct3D 9 is strongly encouraged. See the Games for Windows Showcase S.1. Requiring Direct3D 10 or Direct3D 11 is fully compliant with requirement 1.7.

Games and their installers must run correctly without visual problems when dots-per-inch (DPI) scaling is enabled (tested with 144 DPI for 150% scaling at display resolution of 1600×1200) on Windows Vista and Windows 7.

This typically requires the game executable to declare being DPI-aware. This is accomplished by embedding a manifest element: <dpiAware>true<dpiAware> .

High-quality LCD monitors are commonplace as computer displays, and they look best when driven at their native resolutions (typically 1280×1024, 1600×1200, and so on). Customers who have difficulty reading text and seeing images at this resolution often set their computer desktops to a lower resolution and suffer visual artifacts from LCD scaling. Instead, customers can leave the resolution at the native size and change the DPI of the Windows display, thus making item and text appearance larger without sacrificing image quality.

While this feature has been available in some form since Windows XP, it is seldom enabled by customers or by OEMs. More than half of all computer displays today are set to a lower resolution than the monitor's native resolution, based on customer feedback. Windows 7 makes this feature much more visible to customers during initial setup and when changing display settings, encouraging them to use DPI scaling rather than change the desktop resolution.

The SetProcessDPIAware function can be used instead, if called early in the process startup code. Adding to the manifest is preferred, to ensure there are no race conditions with software elements (such as DLLs) that might initialize before the main entry point is called. note that SetProcessDPIAware is only present on Windows Vista and Windows 7.

Adding the manifest element is easy to do with Visual Studio 2005 and 2008; create a file named dpiaware.manifest that contains the following text:

            <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
            <asmv3:application>
            <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>true</dpiAware>
            </asmv3:windowsSettings>
            </asmv3:application>
            </assembly>
          

Then, inside Visual Studio, add dpiware.manifest to the project. Ensure that Embed Manifest is set to Yes in the project's properties. Note that older versions of the Manifest Tool (Mt.exe) will generate a spurious warning with the DPI-aware manifest elements. To resolve this, update Mt.exe to the latest version from the Windows SDK.

Visual Studio 2010 includes a setting in the project properties, named Enable DPI Awareness, that eliminates the need for a file like dpiaware.manifest. Find Enable DPI Awareness by expanding Configuration Properties and Manifest Tool, and then selecting Input & Output.

On Windows, the traditional display mode defaults to 96 DPI, which was common for CRT monitors.

While full-screen applications change the display resolution, they often use window messages and metrics when setting up buffers and display rectangles. DPI virtualization causes these full-screen display modes to appear cropped, and declaring DPI-aware will prevent these problems. For more information, see Writing DPI-Aware Win32 Applications.

Every executable file (that is, every file that has a .exe extension) must contain an embedded manifest that defines its execution level by including the following tag:

            <requestedExecutionLevel>
          

Per requirement 1.2, the main game and Autorun executable must have the execution level of asInvoker to support Standard User contexts.

User data files that have file associations registered with File Explorer must be placed in a subfolder of the folder that is specified by CSIDL_PERSONAL (also called Documents or My Documents). All other user data files must be stored in a subfolder of the folders that are specified by CSIDL_LOCAL_APPDATA or CSIDL_COMMON_APPDATA. (These directories are hidden by default for individual users and for all users.)

A user's Windows experience is more secure if applications run only with the permissions needed.

If only a few features in an application require administrative privileges (for example, an application that needs to configure a firewall), the main process of the application must still be run by using standard user privileges. Features that require administrative privileges must be moved into a separate process, such as an installer or configuration utility.

If administrative privileges are not required, the embedded manifest XML should include the following:

            <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
            <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
            <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
            <ms_asmv2:security>
            <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
            </ms_asmv2:requestedPrivileges>
            </ms_asmv2:security>
            </ms_asmv2:trustInfo>
            </assembly>
          

If administrative privileges are required, the embedded manifest XML should include the following:

            <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
            <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
            <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
            <ms_asmv2:security>
            <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
            </ms_asmv2:requestedPrivileges>
            </ms_asmv2:security>
            </ms_asmv2:trustInfo>
            </assembly>
          

With Visual Studio 2005 this is easily embedded by just adding a manifest (.manifest) file that contains one of the preceding blocks to the project, and ensuring that Embed Manifest is set to Yes in the project properties for Manifest Tool. For Visual Studio 2008 and 2010, UAC properties can be set directly in the project properties for the linker on the Manifest File page. Note that older versions of the Manifest Tool (Mt.exe) generate a spurious warning with the UAC manifest elements. To resolve this, update Mt.exe to the latest version from the Windows SDK.

See requirement 3.1 for details on the special cases of installation, patching, and removal.

Dynamic Link Libraries (DLLs) do not require such manifests.

For more information about User Account Control, see User Account Control for Game Developers.

To maintain compatibility with 64-bit editions of Windows, games should meet the following requirements.

• Titles and title installers must not contain any 16-bit code or rely on any 16-bit component.

• If the game is dependent on kernel-mode drivers for operation, x64 versions of these drivers must be available. The game setup must detect and install the proper drivers and components for the 64-bit editions of Windows.

Many Windows Vista and Windows 7 users will run 64-bit editions of the operating system over the life of the product, so it is crucial for applications to be compatible with this operating system.

Windows on Windows 64 (WOW64) allows 32-bit code to run on 64-bit editions of Windows, so it is not necessary that the application be native 64-bit code on 64-bit editions of Windows. Sixteen-bit code does not run on 64-bit editions of Windows.

Maintaining compatibility with Windows XP Professional x64 Edition is not required, but it is strongly encouraged.

For details, see 64-bit Programming for Game Developers.

All executable code files (typically, files with the extension .exe or .dll) must be signed with a publicly valid Authenticode certificate, and must have a valid timestamp server URL for production signing.

If your game uses Windows Installer, the installer package files (.msi files) must be signed.

Signing a file helps users decide whether to trust an application, and assures users that files have not been tampered with. It also allows applications to run properly in locked-down environments.

For details, see Authenticode Signing for Game Developers.

If your game uses Windows Installer, we recommend that you enable UAC/LUA patching, by including an MsiPatchCertificate table. For more information, see User Account Control (UAC) Patching.

We do not recommend signing cabinet (.cab) files, unless they are relatively small (less than 100 MB).

Any kernel-mode driver that is installed by the game must be signed with a publicly valid Authenticode certificate.

Any kernel-mode hardware device driver that is installed by the game must have a Microsoft signature, which can be obtained from the Windows Hardware Quality Labs (WHQL) or from the Driver Reliability Signature (DRS) program.

Poorly written or malware drivers can severely affect the stability and security of a system. On 64-bit editions of Windows Vista and Windows 7, unsigned drivers do not load. This policy can also be enabled for 32-bit editions of Windows Vista and Windows 7.

Both 32-bit and 64-bit native versions of all kernel-mode drivers are needed per requirement 2.2.

More information about Microsoft driver signing programs can be found at the Windows Hardware Developer portal.

Games must not fail to run on future operating systems as indicated by changes in the Windows version number, unless the End User License Agreement prohibits use on future operating systems. If the game is supposed to fail, it must do so gracefully by displaying an appropriate message to the user.

If Windows version checks are made, the version-checking APIs (GetVersionEx or VerifyVersionInfo) must be used to check the operating system version. Registry keys must not be read to determine the version.

Explicit version checks for the DirectX runtime must not be present in the game. These version checks must not be present in the installation that launches the DirectX runtime setup (DirectSetup).

When Windows users upgrade their operating systems, they should not be blocked from playing current games simply because the Windows version number has increased. Poorly written version checkers continue to create problems for software that, otherwise, works fine on newer versions of Windows or simply with the addition of a Windows service pack.

Fragile version check comparison logic for the DirectX runtime has created numerous failed installations when it is run on different versions of Windows. The DirectX version number applies only to the core operating system components. It does not apply to the side-by-side DirectX SDK components that are used by many games.

It is quite common to see installers check for a minimum OS version. This check, however, needs to be done with care to ensure that it tests for greater than or equal to, rather than simple equality, thereby locking to a specific version of the operating system. Using Application Verifier's HighVersionLie test is a quick and easy way to determine how your installer will react to a significant change in the OS version number.

Proper use of the DirectX runtime redistribution package (DirectX Setup) involves always launching it during installation, preferably in silent mode. This allows the code that is provided by Microsoft to perform any required version updates. It also allows installation of any optional side-by-side DirectX SDK components, such as D3DX, XACT, MDX, or XInput.

For best practices for deploying the DirectX runtime, see DirectX Installation for Game Developers.

It is recommended that games that support Windows XP check for a service pack level of 2 or higher, because Service Pack 2 (SP2) and Service Pack 3 (SP3) provide significant security improvements, a simplified DirectX Runtime Redistribution requirement, and extremely broad deployment. Most modern Microsoft technologies that support Windows XP require SP2 or SP3 (XAudio2, Games for Windows - LIVE, and so on).

Games that rely on 3D graphics are not required to work over a remote desktop connection, but the user must be alerted when the game fails.

Games must support standard Windows multitasking scenarios by adhering to the following rules:

• Games must not block the use of concurrent user sessions.

• A game must run in a new user session when it is already running in another session.

• Game sound in one user session must not be heard when another user is active in a different session.

• Games must support Fast User Switching.

• Games must not attempt to disable standard task switching. Games must not disable the ALT+TAB keyboard shortcut. Games are allowed to disable accessibility keyboard shortcuts, as described in Disabling Shortcut Keys in Games.

Windows users should be able to run concurrent sessions without conflict or disruption. This is a common scenario for a Windows computer that is shared by a family, roommates, or others.

To test whether the game is launched in a remote session, call GetSystemMetrics(SM_REMOTESESSION). A nonzero value indicates that the session is remote.

For more information, see Fast User Switching. Note that Fast User Switching occurs if Parental Controls time restrictions are enabled when the user's time is up. See requirement 1.2 for more details.

If a game supports saving files, it must be able to save files that have long names and paths. The game must properly handle special file system characters, such as \ / : * ? " < >, in any user input fields that are used to create file names or paths.

Games must work properly when a user has a long user name.

Players are accustomed to using long names on deep paths that are supported by the underlying operating system.

Long names are defined as those that contain the maximum values that are defined in the Windows SDK.

Games must provide a simplified path in the setup user interface by implementing the following:

• Display a maximum of one EULA prompt.

• The default installation path must bypass all selections for the installation (such as installation folder or component selections), assume the default selections, and then run the game or launcher upon successful installation, without additional prompts. If desired, a custom installation option can be provided for advanced configuration options.

• Install any required operating system components (such as the DirectX and Visual C runtimes) using the correct Microsoft redistribution packages. The installation should be performed silently, without prompting and without being guarded by component version checks.

• Provide removal through Programs and Features in Control Panel for both the game application and generated working files. An option for deleting any data files that are created by the user is recommended. The removal process must ensure that all installed files are removed and all settings (for example, firewall exception list entries and registry keys) are cleared. Redistributed operating system components must not be removed.

• If the game requires exceptions to be added to the Windows Firewall, the setup process can prompt to inform users that this change is required. This prompt should appear before installation begins.

Installation and removal can require administrative rights. Patching can require prompting for administrative credentials, depending on frequency of update. Normal play of the game must not require administrative rights, per requirement 2.1 Follow User Account Control Guidelines.

Easy installation is a Windows-centric game development philosophy that is designed to simplify and streamline the sometimes tedious and confusing process of installing games on computers that are running Windows operating systems. Easy installation is enabled by utilizing a set of technologies and best practices that reduce the unnecessary complexity and perceived risk of installing games on Windows computers.

The key goals are to:

• Reduce the amount of time to get into the game and begin play.

• Reduce the number of dialog boxes and choices to very few, or none, in order to simplify the game installation experience.

Some traditional installations have prompts that allow non-functional installations, even though the application appears to be successfully installed. For example, a game can require a user to accept a EULA. The game is then installed, and then the DirectX EULA appears. This EULA allows users to decline, and thus skip installation of the DirectX runtime. This scenario can result in a game that fails to run because of missing components.

For more information about game installation, non-traditional game installation techniques, UAC-compatible patching solutions, and handling frequent patching, see the following DirectX SDK articles:

• Simplifying Game Installation

• Install-on-Demand for Games

• Patching Game Software in Windows XP, Windows Vista, and Windows 7

• Installation Best Practices for Massively Multiplayer Online Games

Note that removing user-specific generated data files should be performed only for the current user and for common shared user locations. There is no robust way to scan the system to remove user-specific files for other users, even if the removal requires administrative credentials.

The game installer must not assume that it is running in the same context as the user. User-specific locations will be different from the installer and the player even for single-user systems due to administrator credentials elevation. Therefore, when a game runs for the first time, it must perform user-specific tasks, separately from the installation process.

The Windows Firewall exception dialog box must not appear when a user hosts or joins a multiplayer game. Any required configuration must be done at installation time. The setup instructions should inform the user that this operation will occur as part of the setup.

The game installer must provide an embedded manifest that designates the required execution level, per requirement 2.1 Follow User Account Control Guidelines.

If the game is launched by the installer after installation is complete, it must be launched in the context of the original user.

One of the largest changes to the Windows operating system in Windows Vista is the addition of User Account Control (UAC), which runs applications with reduced privileges by default. As a result, installers need to manage privilege levels accordingly. Windows 7 also makes extensive use of UAC. While Windows 7 improves the user experience of UAC, installers must still meet the same requirements as on Windows Vista to function properly, without relying on potentially confusing virtualization behavior.

UAC is active by default on Windows Vista and Windows 7, and the vast majority of customers (88% or more, based on feedback) leave this feature enabled.

For more details on configuring the Windows Firewall, see the DirectX SDK article Windows Firewall for Game Developers and the FirewallInstallHelper sample.

Standard launch of the game at the end of the installation process fails to meet the last aspect of this requirement if the installation is launched by a standard user, and if the setup process requires administrative privileges (that is, prompts for a administrator credentials). It also inherits administrative privileges, which is a potential security risk. Instead, a setup bootstrap loader should launch the game after returning from a successful invocation of the installer. For more information, see the MSDN Magazine article Teach Your Apps to Play Nicely with Windows Vista User Account Control.

Games that are installed for all users must be installed to the Program Files folder by default. User data must be written when the game runs for the first time, not during the installation.

Users should have the flexibility to install applications where they need them. They should also have a consistent and secure experience with the default location of files.

Games can make use of the various known folder locations (such as those specified by CSIDL_LOCAL_APPDATA and CSIDL_COMMON_APPDATA) to store significant amounts of game data and supporting executable files to implement advanced install-on-demand and patching scenarios.

Because installation can require elevation to a different user account during the all users installation process, there is no correct user location in which to store data at installation time. Also, if file encryption is enabled, encrypted files can be only accessed by the user account that created them.

Applications must not attempt to install files or registry keys that are protected by Windows Resource Protection (WRP). If the application requires newer versions of system components, it must update these components by using a Microsoft Service Pack or a Microsoft-approved installation package that contains the system component. System components must never be repackaged.

Windows Resource Protection (WRP) is designed to ensure that protected system resources are updated only by using Microsoft-approved installation or update mechanisms. WRP improves system reliability by ensuring that the results of an installation are predictable.

WRP is the successor to Windows File Protection, which protects the majority of the system components that are installed in the Windows folder. WRP protects most registry keys that store settings for COM object creation. It also reserves certain folders for use exclusively by the operating system. Attempts to access protected resources typically result in an access denial error.

For details of best practices when the DirectX runtime is deployed with a game, see the DirectX SDK article DirectX Installation for Game Developers.

The game installer should not assume that installation of Windows components from redistribution packages requires a reboot, unless the reboot is indicated by a return result or by Microsoft documentation.

If the game installer always forces a reboot, this must be approved by Microsoft.

Files-in-use dialog boxes that are included in Windows Installer packages must contain an option to automatically close applications and attempt to restart them after setup is complete.

Rebooting the system after an installation is an inconvenient disruption for users and is usually unnecessary.

For more information, see Using Windows Installer with Restart Manager.

The game installation program must properly check to ensure that the latest file versions are installed. Installing a game must never regress any files that you do not produce or that are shared by applications that you do not produce.

Shared components and system components are often updated for security fixes and expanded functionality. An installation that includes an older version of updated components should not result in the loss of updates and fixes that already have been applied.

For games distributed on CD, DVD, or other removable media that support Autorun, when the disc is inserted for the first time, the application must automatically run or prompt the user to install the game, unless the user has disabled the Autorun feature.

After the application is successfully installed, re-inserting the disc in the drive must not cause installation to automatically begin again. It is acceptable to ask users if they want to update or change their installation choices.

The autorun application must not prompt for elevation (that is, it must have asInvoker in the manifest, per requirement 2.1, although it can launch the setup program or another utility that requires administrative rights. Elevation should occur only if the game is not installed, or if the user specifically selects it.

Autorun simplifies the experience of using media-distributed applications, such as games that typically require the disc to be present in the drive in order to play the game.

It is not acceptable to require the user to navigate in File Explorer to launch the installation from the CD or DVD.

For games that are distributed on multiple discs, subsequent discs should ideally either use the Autorun feature or continue installation without prompting the user to press a key or take other action.

When authoring an Autorun program, ensure all required components are present on fresh installs of Windows. Typical applications rely on technologies installed by the setup, but Autorun itself executes before any such setup occurs. One common example is the failure of Autorun programs because the Visual C Runtime DLLs were not included as part of the Windows setup. The Autorun program, therefore, must use application local CRT deployment or must statically link the CRT.

Autorun programs written for use on versions of Windows before Windows Vista should not use the .NET runtime because this technology is not included with Windows XP or older versions of Windows. Windows Server 2003 and Windows Vista are the first versions of Windows to include .NET runtime as part of their operating system.

For similar reasons, Autorun programs cannot require the presence of DirectX SDK optional side-by-side components such as D3DX9, D3DX10, D3DX11, XAudio2, X3DAudio, XACT, XINPUT, and MDX 1.1.

For an example of using Autorun, see AutoRun Sample.

All application installers must take advantage of the restart manager APIs to avoid system reboots (see requirement 3.5).

Games must not block shutdown.

All applications must respond to the restart manager by listening and responding to the following shutdown messages:

WM_QUERYENDSESSION with LPARAM = ENDSESSION_CLOSEAPP (0x1)

GUI applications must respond (TRUE) immediately in preparation for a restart.

WM_ENDSESSION with LPARAM = ENDSESSION_CLOSEAPP (0x1)

Applications must return a 0 value within 5 seconds, and then close.

CTRL+C

Console applications that receive this message must close immediately.

System reboots are a major disruption. They lead to a bad user experience, and should be minimized. Some operations, such as critical system updates can require reboots. By listening to shutdown messages, the game and other applications can react promptly to requests from restart manager. In this way, they can avoid unnecessarily delays in valid reboot requests.

If a game installer uses the Windows Installer technology (MSI) without any custom actions, this functionality is provided automatically. Microsoft redistribution packages also support the Restart Manager.

For more information about the Restart Manager, see the MSDN article About Restart Manager.

The game must generate no failures running under Microsoft Application Verifier (AppVerifier), version 4.0 or later, in the following tests:

• Basics: Handles, Heaps, Locks, Memory, TLS

• Miscellaneous: DangerousAPIs, DirtyStacks

AppVerifier tests for many known issues that cause crashes and hangs in Windows applications, as well as known security vulnerabilities.

For more information about Application Verifier, see Application Verifier and Using Application Verifier Within Your Software Development Lifecycle on MSDN. You can download Application Verifier from Download details: Application Verifier on Microsoft Download Center.

This requirement does not apply to pure managed applications without native interop.

These tests should be run on a release build. Debugging builds can generate false failures. Some anti-piracy and anti-cheat technologies can interfere with the execution of AppVerifier. Therefore, these tests should be performed without anti-piracy and anti-cheat technologies enabled.

It may be necessary to set the Full property of the Basics:Heaps test to FALSE, because the full PageHeap greatly increases the memory pressure of the running application. Failures will still be detected, but they might be more difficult to track down if you use only partial PageHeap.

If you use the UAC/LUA-related tests in Application Verifier to meet the User Account Control requirements 2.1 and 3.2, you should use the Standard User Analyzer to review the results. There are also numerous other useful tests provided by Application Verifier which you are strongly encouraged to use in development and testing to ensure a high level of compatibility with current and future versions of Windows. The HighVersionLie test is used to verify compliance with requirement 2.5.

Visual Studio Team System includes a subset of the AppVerifier functionality that is integrated into the debugging environment. This may prove useful for tracking down and resolving issues with Basics: Heaps, Handles, and Locks tests.

To enable support of Windows Error Reporting, games must meet the following requirements:

• Games must handle only exceptions that are known and expected. Windows Error Reporting must not be disabled. If a fault such as an Access Violation appears in a game, it must allow Windows Error Reporting to report the crash.

• All executable files (for example, .exe files or DLLs) must contain an accurate product name, company name, and file version.

• Normal exit of the game must not result in an unknown exception fault.

The Windows Error Reporting APIs provide vital feedback to Microsoft for detecting widespread crashes and hangs in applications. This allows Microsoft and its partners to quickly detect and resolve system and driver issues that lead to application failures quickly.

Games can include custom unhandled exception handlers to perform custom support and reporting functionality, but they must pass any error on to the ReportFault or WerReportSubmit functions.

Proper file version information can be verified by viewing the file properties in the Windows desktop UI and checking the Version property page.

For more information about the Windows Error Reporting APIs, and how to analyze the crash dumps that are generated when you use this service, see the DirectX SDK article Crash Dump Analysis.

Direct3D 11 is the next-generation rendering API for Windows Vista and Windows 7. Games exploiting Direct3D 11 use optimized content, advanced rendering techniques, and new hardware features to create a compelling experience on hardware that supports 10, 10.1, and 11.

If the game also implements Direct3D 9, a side-by-side comparison should demonstrate a perceptible improvement in content quality, visual fidelity, performance, scene complexity, and other areas of graphics fidelity for Direct3D 11. This support is subject to the Games for Windows Technical Requirement 1.7.

Direct3D 10level9 technology can be used to support Shader Model 2.0/3.0 Direct3D 9-class video hardware on Windows Vista and Windows 7, rather than using a side-by-side Direct3D 9 implementation for broad hardware support. However, this is not sufficient to demonstrate this showcase.

On computers running Windows Vista or Windows 7 with Direct3D 11 installed, the game should default to using Direct3D 11.

The Direct3D 11 API builds on the Windows Vista Display Driver Model (WDDM) and Direct3D 10.1 infrastructure to support new capabilities: hardware tessellation, compute shaders, multithreaded rendering and resource creation, new texture compression formats, and a more flexible shader language. Direct3D 11 provides unified hardware support for modern video cards, including the latest generation Direct3D 11 parts, all Direct3D 10 and 10.1 video cards, and many Shader Model 2.0/3.0 Direct3D 9 video cards, which is the minimum video hardware required for the Aero 3D desktop.

Migrating a Direct3D 9 rendering engine to use the new Direct3D 11 interface is a well-defined task:

• Eliminate all fixed-function operations in favor of programmable shaders.

• Update all existing shaders to the new syntax of Shader Model 4.x/5.

• Update resource management to support the new view model.

• Convert all assets to use a new list of available formats.

• Update render state handling to use immutable state blocks, and rework shader constants into constant buffers.

This conversion is essential to enable the Direct3D 11 showcase, although the result does not meet the showcase requirement of exploiting the new API.

The new API and associated HLSL programming model offers many opportunities for enhanced content:

• Leveraging existing Direct3D 10 hardware features, such as Geometry Shader, Stream Out, texture arrays, and the BC4/BC5 compressed texture formats.

• Leveraging existing Direct3D 10.1 hardware features, such as independent per-render-target blend modes, MSAA depth read back, MSAA per-sample shader access, cube map arrays, and rendering to block-compressed (BC) formats.

• Implementing advanced GPU algorithms using Compute Shader with CS4.x on existing Direct3D 10/10.1 video cards (enabled by updated video drivers) or CS 5.0 on next-generation Direct3D 11 video cards.

• Rendering on multiple threads using free-threaded resource creation and multiple device contexts for improved performance on multicore systems (with updated video drivers). For more information, see the Games for Windows Showcase S.3.

• Utilizing new features of Direct3D 11-class video hardware, such as hardware tessellation with hull and domain shaders, Shader Model 5.0 HLSL shader hardware features BC6HBC7 compressed texture formats, and Dynamic Shader Linkage.

Techniques that can be implemented with Direct3D 9 (largely through high CPU cost) can be off loaded to the GPU in an efficient manner, thus freeing CPU resources to support other game demands.

Direct3D 11 APIs, supporting tools, and samples are available in the DirectX SDK. Also see Graphics APIs in Windows Vista.

The game includes a 64-bit native executable that delivers a compelling new experience enabled by x64 editions of Windows running on x64-capable hardware. A side-by-side comparison with the 32-bit version of the game should show a perceptible improvement in content complexity, reduced overall load times, and performance.

On 64-bit editions of Windows, installation should always set up the 64-bit native version of the game as the default for shortcuts in Games Explorer and Windows XP Professional x64 Edition. If dual installation is desired, then an additional play task can be specified for Games Explorer on Windows Vista and Windows 7 that points to the 32-bit version, but the default should remain the 64-bit native version.

Note that the game should support the 64-bit editions of Windows Vista and Windows 7 to meet this showcase recommendation. Support for Windows XP Professional x64 Edition is encouraged, but not required.

x64 technology provides 64-bit addressing capabilities for both the consumer and server markets that includes full-speed 32-bit backwards compatibly for existing applications. x64 is a key part of the roadmap for both AMD (AMD64) and Intel (EMT64), and, with the exception of ultra-mobile CPUs, support the technology for all current and future generation processors.

Windows XP Professional x64 Edition was the first consumer-oriented Windows operating system (OS) to support x64 technology, and Windows Vista and Windows 7 greatly expand the availability of the OS-enablement for 64-bit consumer computing. With 2 GB of RAM as standard on many new computers, further improvements in memory scaling will not benefit 32-bit individual applications that are unable to address more than 2 GB of physical RAM. Many games today are facing challenges fitting all of the available content into the constraints of 2 GB of virtual address space, especially when combined with the large video memories available on high-end GPUs, and moving to x64 technology greatly increases the supportable levels of detail.

x64 compatibility for 32-bit games is a Games for Windows technical requirement (2.2), but taking full advantage of the new technologies requires a 64-bit native implementation.

The primary benefit of 64-bit addressing is the ability to directly access more than 2 GB of physical and virtual memory. The large virtual memory address space allows for extensive use of memory-mapped I/O without concern for VM address space exhaustion problems prevalent in 32-bit programming. Games can take advantage of the new space to greatly improve load times or, in some instances, to eliminate pauses for loading content.

Existing 32-bit applications can benefit from x64 editions by having the capability to process addresses with full 32-bit data when built with the Enable Large Addresses (/LARGEADDRESSAWARE) linker option. On 32-bit versions of Windows XP, special boot modes allowed such applications to address up to 3 GB of RAM, and x64 editions provide access up to 4 GB of RAM for Large Address Aware (LAA) apps. While use of LAA in a 32-bit application does not meet this showcase requirement, this bridge technology is an extremely useful way of providing additional scaling benefits on x64 versions of Windows for those not fully implementing this showcase requirement.

For more information, see 64-bit programming for Game Developers and RAM, VRAM, and More RAM: 64-bit Gaming Is Here in Gamasutra.

Note that a key challenge for this showcase is ensuring any third-party libraries or components your game relies on are available for 64-bit native development. Many legacy Microsoft APIs also have been eliminated from the 64-bit native environment, which can prove a challenge for engine codebases containing older implementations of key systems.

The game implements features that take advantage of multicore processors, scaling to 3, 4, or more cores, when available.

If the game supports single-processor or dual-core systems, a side-by-side comparison with a quad-core system should demonstrate perceptible new features, additional compelling effects, improvement in content quality, and/or improved performance.

Because dual-core scaling is already widely supported by games, as well as automatically utilized by various Direct3D driver enhancements, dual-core scaling is not sufficient to demonstrate this showcase.

The continuing growth in performance for CPUs has switched from clock rate improvements to the addition of computational cores. Both AMD and Intel roadmaps are based on scalable, multicore designs. All next-generation game platforms have multicore CPUs because of this fundamental shift in the evolution of processors. Single-threaded applications no longer will see significant gains from next-generation CPUs. Simple multithreading also will fail to scale as the number of CPU cores in common use grows to three or more.

Note that core counts need not be a power of two, so games should scale linearly and handle core counts of 3, 4, 5, 6, 7, 8, and so on.

Scaling by increasing the number of threads in an application only provides a return if the cost of communication and thread synchronization are kept in check. Feature-based scaling may prove an easier solution in the short-term, allowing the game to operate normally without the additional threads on single-core systems and enabling them when the additional CPU power is available.

For more information, see Coding For Multiple Cores on Xbox 360 and Microsoft Windows and Lockless Programming Considerations for Xbox 360 and Microsoft Windows in the DirectX SDK documentation, as well as the DXUTLockFreePipe utility and the CoreDetection sample.

Making use of the Direct3D 11 free-threaded resource creation and device contexts is useful in achieving many-core scalability in rendering and loading graphics resources. See Games for Windows Showcase S.1.

Note that using the CPU instruction rdtsc directly, instead of using Windows APIs to compute timing on multicore systems, can lead to problems on some hardware and OS configurations; see Game Timing and Multicore Processors in the DirectX SDK documentation.

Implement Games for Windows – LIVE on-line service. This requires a signed On-line Licensing Agreement (OLA), adherence to security-focused Technical Certification Requirements (TCRs), and successfully passing Certification. Titles that use Games for Windows – LIVE (GFWL) will permit sign-in to LIVE, display and use the Guide UI for social features and LIVE account management, use LIVE multiplayer features, and offer premium downloaded content through the LIVE service.

Titles that use Games for Windows - LIVE enjoy a variety of benefits. Player presence, game invitations, and achievements all serve as marketing vehicles for a title. Achievements and gamerscore provide additional purchase incentive for consumers. The Games for Windows - LIVE service is designed to be more accessible for users who are not tech-savvy and for those for whom the cheating and griefing behaviors commonly found in on-line gaming are barriers to participation. True to the roots of multiplayer gaming, a Silver (free) account permits full multiplayer gaming functionality, integrated voice communications, and all of the social features of LIVE.

Games for Windows - LIVE also provides a robust solution for paid in-game downloadable content, where developers can provide game add-ons to users who use LIVE's licensing and billing system with minimal development effort. Users can purchase downloadable content, not only from the Games for Windows - LIVE Client, but also from the Guide UI within the game.

Developers who are creating an Xbox 360 version of a title will find that the API set used in Games for Windows - LIVE is nearly identical, facilitating simultaneous development by a single team, and resulting in a shorter time to market and better leveraging of marketing assets.

Titles can be single-player (LIVE-aware), multiplayer, and/or cross-platform multiplayer with Xbox 360. Integrating additional on-line solutions is permitted, but allowing simultaneous connection while connected to Games for Windows - LIVE is not permitted, for security reasons.

For more information, please visit the developer portal, Games for Windows-LIVE Central .

Windows touch-capable games are playable using touch and/or gestures on computers running Windows 7 with a touch display. Keyboard input can be used as well, but the primary play interface must be touch-based.

Enabling touch should not prevent the use of the mouse or common controller, subject to Technical Requirement 1.4.

The game's installer is not expected to support Windows Touch functionality.

Multi-touch-capable displays for computers are available for laptops and desktops, and they represent a key hardware feature being promoted with the release of Windows 7. Windows 7 supports Windows Touch throughout the desktop and common controls interfaces.

Native code applications can access multi-touch through the WM_TOUCH messages, in combination with the RegisterTouchWindow function. See also the Manipulations and Inertia API.

Windows Presentation Foundation (WPF) 4.0 provides a managed solution for multi-touch interfaces.

For more information, see the Windows Touch SDK.

Games that support High Color use a 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) or a 16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) format for the rendering back-buffer and full-screen display mode.

By using a “High Color” render target, High-Dynamic Range (HDR) content can be rendered with an extended or wide gamut when performing tone mapping to a 10-bit or 16-bit range.

Monitors have been capable of displaying more than 256 color levels per channel for many years, even when CRT displays were prevalent. The scan out hardware on video cards has been the limiting factor. Modern GPUs, including most Direct3D 9-class hardware and all Direct3D 10-class and better hardware, have scan-out hardware capable of at least 10-bits per channel, and hardware capability is set to grow to 16-bits per color channel in the future. HD TV interconnect systems (HDMI, DisplayPort) have been designed to handle more than 8-bits per channel as well, and analog VGA will already carry such signals.

Note that High Color, or Hi Color, historically refers to moving from 256 (8-bit) color displays to 15- or 16-bit color displays. Most display systems have long since moved on to True Color which is 24-bit color, or 8-bits per color channel for red, green, and blue. By High Color here we mean a new generation of displays systems that can operate with more than 8-bits per individual color channel. The is also referred to as Deep Color.