Games for Windows: Technical Requirements
Games for Windows: Technical Requirements
Microsoft Corporation
Version 1.3.0008
November 2008
The information presented in these guidelines reflects Microsoft Corporation's views as of the date of publication. These views can change and probably will change in response to changing market conditions. Microsoft makes no warranties or guarantees, implicit or explicit, in or by virtue of this document. Unless otherwise permitted by law, no part of this document may be copied without Microsoft's prior written permission.
This document contains the following categories:
Games for Windows
Summary of Games Requirements
Customer Benefits
Computer games are a key entertainment experience on Windows, but ease-of-use concerns have caused customer frustration over the years. Traditionally, games are installed like applications, but they are utilized more like entertainment media (movies or songs, for example), as demonstrated by the gaming experience on Xbox 360 consoles. Innovations, such as Games Explorer, expose games in a consistent manner that is different from standard applications. These innovations also and give games first-class citizen status in Windows, together with Music and Pictures. The following requirements help ensure that Windows Vista provides an improved, more accessible, and unified gaming experience. At the same time, they ensure compatibility with Windows XP.
This section describes the following requirements:
1.1 Games Explorer Integration
Requirement
The game must be visible within Games Explorer (the Games folder) on Windows Vista. 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.
In addition, game installers must observe the following rules when developing on Windows Vista and future versions of Windows:
- 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 (or Add or Remove Programs in Windows XP) on Windows Vista or on future versions of Windows.
On Windows XP, and on previous versions of Windows, the game installer is free to create program groups, desktop icons, or shortcuts as needed.
Rationale
The Windows Vista 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 completely data-driven, so it is easy for a game publisher to update game
information over the life of the product.
Additional Information
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 thumbnail bitmap image. 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 websites, but play tasks can be used for optional support tasks as well.
Details on integrating with Windows Vista Games Explorer are provided in the DirectX SDK. The DirectX SDK includes a GDF editor, as well as an example GDF that is included in the GDFExampleBinary sample. The GameUxInstallHelper sample provides routines for integrating the required functionality into existing installation systems. The Game Definition File Validator provides debugging support for evaluating a GDF. Also see the article Windows Games Explorer Integration in the DirectX SDK Documentation for C++.
On Windows Vista Business and Enterprise Editions, 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.
Associated applications that are not themselves games, but that are installed along with your game, are free to create Start menu program groups, shortcuts, and desktop icons on all versions of Windows including Windows Vista. Such associated applications should pass applicable Games for Windows requirements. See the Guidelines for Game Middleware Products for details.
1.2 Support Family Safety / Parental Controls
Requirement
Games must fully support Windows Vista Family Safety by adhering to the following rules:
- Games must not require administrative credentials to play. Installation, patching, and removal can require administrative credentials, subject to the requirements in section 3.
- Games rated by Windows Vista supported ratings boards such as ESRB and PEGI must include this rating 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 on Windows Vista, and exit if it returns *pfHasAccess as FALSE.
Rationale
All games must execute within the context of a Standard User account to allow accounts that are controlled by Windows Vista 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 new architecture offered by Games Explorer in Windows Vista, Microsoft provides parents this ability through Windows Vista 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 Vista Parental Controls system allows parents to select ratings they believe are appropriate for their children. Parental Controls support many of the worldwide ratings systems. Parental Controls also allow parents to restrict based on Content Descriptors (if the applicable rating system supports them) and to allow / disallow access to individual games.
The default choice of rating system for Windows Vista 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.
Additional Information
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 March 2008 version or later of these tools.
Windows Vista Service Pack 1 increases the support of Parental Controls by adding the GRB (South Korea) ratings system and by enhancing the ESRB content descriptors with the inclusion of “Mild” variations of existing descriptors. Note: Any title that includes new ESRB Windows Vista Service Pack 1 (SP1) content descriptors will show as “Unrated.” Without the application of SP1, GRB data will be ignored by Windows Vista.
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).
1.3 Support Rich Saved Games
[This requirement has been retired]
1.4 Support the Xbox 360 Common Controller for Windows
Requirement
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.
Rationale
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.
Additional Information
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.
1.5 Support Multiple Aspect Ratios and Resolutions
Requirement
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.
Rationale
With the Windows Vista 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.
Additional Information
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.
1.6 Support Launch from Windows Media Center
[This requirement has been retired]
1.7 Direct3D Support
Requirement
If the game uses Direct3D, then the minimum version supported must be Direct3D 9, and Direct3D must be the default.
Rationale
The Windows Vista core graphics architecture is designed around Direct3D. Direct3D 8 and earlier versions are supported by remapping legacy interfaces.
Security and Compatibility
Summary of Security and Compatibility Requirements
Customer Benefits
The following requirements improve the overall security of games and help ensure that they work with Windows Vista on different architectures, under different configurations, and in different modes.
This section describes the following requirements:
2.1 Follow User Account Control Guidelines
Requirement
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.)
Rationale
A user's Windows experience is more secure if applications run only with the permissions needed.
Additional Information
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>
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.
2.2 Support Windows Vista x64 Versions
Requirement
To maintain compatibility with 64-bit versions 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 versions of Windows.
Rationale
Many Windows Vista users will run 64-bit versions of the operating system over the life of the product, so it is crucial for applications to be compatible with this operating system.
Additional Information
Windows on Windows 64 (WOW64) allows 32-bit code to run on 64-bit versions of Windows, so it is not necessary that the application be native 64-bit code on x64 versions of Windows. Sixteen-bit code does not run on 64-bit versions 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.
2.3 Sign Files
Requirement
All executable code files (typically, files with the extension .exe or .dll) must be signed
with a publicly valid Authenticode certificate.
If your game uses Windows Installer, the installer package files (.msi files) must be signed.
Rationale
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.
Additional Information
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).
2.4 Sign Drivers
Requirement
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.
Rationale
Poorly written or malware drivers can severely affect the stability and security of a system. On 64-bit versions of Windows Vista, unsigned drivers do not load. This policy can also be enabled for 32-bit versions of Windows Vista.
Additional Information
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.
2.5 Perform Proper Version Checking
Requirement
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)
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).
Rationale
When Windows users upgrade their operating systems, they should not be blocked from playing current games simply because the Windows version number has increased.
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.
Additional Information
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.
2.6 Support Concurrent User Sessions
Requirement
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.
Rationale
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.
Additional Information
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.
2.7 Support Long Names
Requirement
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.
Rationale
Players are accustomed to using long names on deep paths that are supported by the underlying operating system.
Additional Information
Long names are defined as those that contain the maximum values that are defined in the Windows SDK.
Installation
Summary of Installation Requirements
Customer Benefits
Customers can be confident that applications will install on Windows without degrading the operating system or other applications if applications use official system component distribution methods. A streamlined installation experience provides a more accessible and trouble-free out-of-box experience for games.
This section describes the following requirements:
3.1 Support Easy Installation
Requirement
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.
Rationale
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.
Additional Information
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:
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.
3.2 Support User Account Control for Installation
Requirement
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.
Rationale
One of the largest changes to the Windows operating system in Windows Vista is the addition of User Account Control, which runs applications with reduced privileges by default. As a result, installers need to manage privilege levels accordingly.
Additional Information
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 crednetials). It also inherits administrative privileges, which is a potential security risk. Instead, a setup bootstrapper 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.
3.3 Install to Correct Folders
Requirement
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.
Rationale
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.
Additional Information
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.
3.4 Install Windows Resources Properly
Requirement
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.
Rationale
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.
Additional Information
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.
3.5 Avoid Reboots During Installation
Requirement
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.
Rationale
Rebooting the system after an installation is an inconvenient disruption for users and is usually unnecessary.
Additional Information
For more information, see Using Windows Installer with Restart Manager.
3.6 Use File Versioning Correctly
Requirement
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.
Rationale
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.
3.7 Support Autorun
Requirement
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.
Rationale
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.
Additional Information
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, XAudio2, X3DAudio, XACT, XINPUT, and MDX 1.1.
Reliability
Summary of Reliability Requirements
Customer Benefits
These requirements make an application more reliable by minimizing the number of crashes, hangs, and reboots. The reliability requirements can help ensure that software is more predictable, maintainable, resilient, and recoverable.
This section describes the following requirements:
4.1 Eliminate Unnecessary Reboots
Requirement
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.
Rationale
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.
Additional Information
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.
4.2 Eliminate Application Verifier Failures
Requirement
The game must generate no failures running under Microsoft Application Verifier (AppVerifier), version 3.3 or later, in the following tests:
- Basics: Handles, Heaps, Locks, Memory, TLS
- Miscellaneous: DangerousAPIs, DirtyStacks
Rationale
AppVerifier tests for many known issues that cause crashes and hangs in Windows applications, as well as known security vulnerabilities.
Additional Information
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.
Visual Studio 2005 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.
4.3 Support Windows Error Reporting and File Version Information
Requirement
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.
Rationale
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.
Additional Information
Games can include custom unhandled exception handlers to perform custom support and reporting functionality, but they must pass any error on to the ReportFault API.
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.
Xbox 360 Common Controller for Windows Terminology
| A
| The A button.
|
| B
| The B button.
|
| BACK
| The Back button.
|
| (right/left) bumper
| The button at the top right and left edge of the
controller. Equivalent to a shoulder button.
|
| directional pad
| The controller directional pad.
|
| D-pad
| Accepted abbreviation of directional pad.
|
| DP
| Directional pad abbreviation and controller label.
|
| RB, LB
| Right and left bumper abbreviations and controller labels.
|
| RS, LS
| Right and left stick abbreviations and controller labels.
|
| RT, LT
| Right and left trigger abbreviations and controller labels.
|
| START
| The Start button.
|
| (right/left) stick
| The controller stick. Formerly thumbstick.
|
| (right/left) stick button
| The controller stick button. Formerly thumbstick button.
|
| (right/left) trigger
| The controller trigger.
|
| Vibration
| Gameplay feedback produced by the controller motor. Do not use rumble.
|
| X
| The X button.
|
| Xbox 360 Controller for Windows
| The Xbox 360 gamepad sold as a PC hardware SKU, including a Windows device driver disc.
|
| Xbox360 Wireless Controller for Windows
| The Xbox 360 wireless gamepad sold as a PC hardware SKU, including a Windows device driver disc.
|
Guidelines for Game Middleware Products
Introduction
For games to qualify for the Games for Windows program, they must meet a list of technical requirements. Any third-party components that are shipped with a title (.exe files, DLLs, drivers, and so forth) must also meet these requirements in order for the game to qualify. This document highlights the most common requirements that must also be met by the third-party components in order for the game to pass the compliance tests. Installers and complete game engine/production packages should review the full Games for Windows technical requirements document, because many of these requirements are affected by these tools.
Additional Recommendations
Beyond ensuring that your component supports the creation of titles that are compliant with the requirements for Games for Windows, there are a number of other considerations you should take into account when designing and deploying a library or support utility for a Windows game.
- To support developers working on 64-bit native x64 applications, provide both 32-bit and 64-bit native versions of your libraries. The 32-bit version must be 64-bit compatible per 2.2. Libraries for 32-bit applications should not assume that the high bit of any 32-bit address is unused in order to support use within LARGEADDRESSAWARE x86 applications.
- If you use a statically linked library, as opposed to a DLL, provide Link Time Code Generation (LTCG) release versions of the library, in addition to standard release versions. The exact compiler version used to generate the LTCG should be documented, which may necessitate generating a specific LTCG version for each supported compiler release (for example, VS 2005, or VS 2005 SP 1).
- If you provide native code (C/C++) headers, use Standard Annotation Language (SAL) attribute syntax to decorate your public API routines. This will allow users of your library to get the maximum benefit of using Static Code Analysis (/analyze), which is part of Visual Studio Team System 2005 and the publicly available Windows SDK compiler tools.
- If your product creates threads within the user's process, be sure to name each thread so that debugging tools can properly annotate running threads.
- If you write routines that are intended to be called within a game's main loop, use the D3DX routines D3DPERF_BeginEvent/EndEvent and D3DPERF_SetMarker to annotate high-level operations for easier identification of bottlenecks using PIX for Windows.
- For networking libraries, provide IP-neutral implementations and avoid deprecated IPv4 only routines to support the IPv6 and Teredo technologies in Windows XP SP2, Windows Vista, and future versions of Windows.
Games for Windows Showcases
Introduction
Games for Windows showcases go beyond providing a solid gaming experience on Windows PCs. By implementing these features, games can add more excitement to the user experience on the latest Windows platforms.
Games for Windows titles must fulfill all technical requirements listed in this document, but showcase features are optional. These titles are free to implement some, none, or all of these showcases.
S.1 Exploit Direct3D 10
Requirement
The game implements a Direct3D 10 rendering pipeline that provides a compelling new experience over existing graphics APIs. If the game also implements Direct3D 9, a side-by-side comparison must demonstrate a perceptible improvement in content quality, visual techniques, performance, scene complexity, or other area of graphics fidelity. Providing an experience on Direct3D 10 that sets the game apart from previous-generation video cards requires enhanced next-generation content, not simply porting existing content to use the new Direct3D API.
Titles that implement this showcase are free to provide a Direct3D 9 rendering engine as well. Such an implementation would be used for Windows Vista machines lacking Direct3D 10 capable hardware and for Windows XP support. This would be subject to the Games for Windows Technical Requirement 1.7.
On Windows Vista systems with a Direct3D 10 capable device, the game should default to using Direct3D 10.
Rationale
Direct3D 10 represents a major innovation for the Direct3D graphics technology based on over a decade of evolution. In order to implement the depth of improvements in this new API, radical changes have been made to the core architecture so as to streamline the pipeline for performance and to provide greatly simplified usability. This necessitated a break from an incremental improvement model. No existing Direct3D 9 card supports the Direct3D 10 interface. The new API also is tied to an innovated new driver model, the Windows Display Driver Model (WDDM), which is not available on older Windows versions.
Direct3D 10 hardware provides excellent and high-performance Direct3D 9 functionality to support existing games and broad non-gaming use by the new Windows Vista user interface. Games must implement their rendering through the new Direct3D 10 API to maximize the new, enhanced capabilities of the new video card hardware and for software support in Windows Vista.
Additional Information
Migrating a Direct3D 9 rendering engine to use the new Direct3D 10 interface is a well-defined task. It requires eliminating all fixed-function operations in favor of programmable shaders, updating all existing shaders to the new Shader Model 4 syntax, effecting major changes to the resource management interface to support the new view model, and converting all assets to use a new list of available formats. Migration also includes significant changes to the handling of rendering state, as well as shader constants. This conversion is essential to enable the Direct3D 10 showcase, although the result does not meet the showcase requirement of exploiting the new API
The new API and associated Shader Model 4 HLSL programming model offers many opportunities for enhanced content:
- The new Geometry Shader stage provides an opportunity to perform edge-enhancement, vertex decimation, limited geometry magnification, and in-GPU material selection.
- Stream Out provides an extremely efficient implementation of multipass techniques without expensive CPU round-trip costs.
- The reliable common computational model allows easier migration of shader code up or down the pipeline for more efficient computation at the per-vertex, per-primitive, or per-pixel level.
- Unified resource access from shaders allows efficient implementation of GPU-based skinning, animation, particle systems, and GPGPU-style operations.
Techniques that can be implemented with Direct3D 9 (largely through high CPU cost) can be offloaded to the GPU in an efficient manner, freeing CPU resources to support other game demands.
Direct3D 10 APIs, Effects 10, Shader Model 4 HLSL, and supporting tools are available in the DirectX SDK. Also see the DirectX SDK article Graphics APIs in Windows Vista.
S.2 Exploit x64 Native
Requirement
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 must show a perceptible improvement in content complexity, reduced overall load times, and performance.
On 64-bit versions 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 that points to the 32-bit version, but the default should remain the 64-bit native version.
Note that the game must support the 64-bit editions of Windows Vista to meet this showcase requirement. Support for Windows XP Professional x64 Edition is encouraged, but not required.
Rationale
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 a few ultra-mobile CPUs support the technology, for all current and future generation processors.
Windows XP Professional x64 Edition was the first consumer Windows operating system (OS) to support x64 technology, and Windows Vista greatly expands the availability of the OS-enablement for 64-bit consumer computing. With 2 GB of RAM a 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.
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.
Additional Information
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 the DirectX SDK article 64-bit programming for Game Developers.
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.
S.3 Exploit Multicore
Requirement
The game implements features that take advantage of multiple CPU cores when present. A side-by-side comparison of the game running on a single-core machine versus a dual- or quad-core machine must demonstrate perceptible new features, additional compelling effects, and improved performance.
Rationale
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.
Additional Information
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.
See the DirectX SDK article Coding For Multiple Cores on Xbox 360 and Microsoft Windows.
Note that using RDTSC directly instead of using Windows APIs to compute timing on multicore systems can lead to problems on some hardware and OS configurations; see the DirectX SDK article Game Timing and Multicore Processors.
Resources
- Games for Windows: Test Cases
- Games for Windows: Test Cases
- Windows Vista SDK
- Windows SDKs
- User Account Control Guidelines
- Windows Vista Application Development Requirements for User Account Control Compatibility
- Windows Installer Information
- Windows Installer
- WinQual Developer Portal
- Windows Quality Online Services (Winqual)
- DirectX Developer Portal
- Directx Developer Center
- Additional DirectX SDK Articles
- DirectX SDK Technical Articles