|
|
Microsoft Corporation
July 2004
The Games for Microsoft Windows Logo Specification defines the technical requirements for applications to earn the Games for Microsoft Windows logo.
Contents:
The technical requirements are all subsets of the overall Designed for Windows software logo program. The numeric references coincide with the Designed for Windows test cases for easy referencing of partners that are releasing applications for both programs.
The following summarizes the key requirements for the Games for Windows logo program for applications.
Customers can be confident that a compliant product will execute on Windows XP and will not adversely affect the reliability of the operating system.
1.1 Perform Primary Functionality and Maintain Stability
The application must perform its primary functions without compromising the stability of the operating system or the application. This includes testing for application hanging, crashing, losing data, or incorrect system behavior.
Test Cases-1.1
As defined in Designed for Microsoft Windows XP Application Test Framework (see Application Test Framework):
1.2 Any Kernel-mode Drivers that the Application Installs Must Pass Verification Testing on Windows XP
Poorly written kernel-mode drivers have the potential to crash the system. Therefore, it is critical that if the application includes any kernel-mode drivers, such as copy protection mechanisms, they be thoroughly tested to minimize this risk.
If the application includes any kernel-mode drivers, each of these drivers must pass validation testing under the Windows Driver Verifier Manager tool (Verifier.exe). That is, Driver Verifier must not report any stop error messages, or otherwise cause system instability, while exercising the system and your application with Driver Verifier installed on your kernel-mode components.
1.4 Perform Windows Version Checking Correctly
The application must verify that the operating system meets the minimum version requirements for the application. The application must also install and run on all later versions of Windows.
1.7 Support Switching Between Tasks
The application must handle ALT+TAB, CTRL+ALT+DEL, CTRL+SHIFT+ESC and other task-switching scenarios. The application must not try to defeat these mechanisms in any way.
Test Cases-1.7
As defined in Designed for Microsoft Windows XP Application Test Framework (see Application Test Framework):
Customers can be confident that your product will install onto Windows XP without degrading the operating system or other applications.
2.1 Do Not Attempt to Replace Files that are Protected by Windows File Protection
The application must not attempt to replace any files that are protected by Windows File Protection (WFP). To ensure that the application does not invoke WFP, it should call SfcIsFileProtected when installing any file that it did not create. The Windows Installer service does this automatically.
Windows File Protection is a feature of Windows XP that prevents the unauthorized replacement of essential system files. WFP runs as a background process on Windows XP and monitors certain files. When WFP detects that a protected file has been changed, it restores the original.
If the application requires newer versions of these components, it must update these components by using a Service Pack or an authorized system redistributable that installs the required versions.
2.3 Do Not Overwrite Non-Proprietary Files with Older Versions
The application's installation program must properly check to ensure that the latest file versions are installed. Installing an application must never regress any files that you do not produce or that are shared by applications that you do not produce.
Do not prompt the user to update a component unless a version update is actually required.
Application binaries must have valid file version information
Correct file version information has several benefits, including making it easier to meet the requirement of not overwriting files with older versions. Accordingly, all executable images that you distribute must contain valid file version information. When you display or get the properties of an executable (EXE, DLL and so on), they must contain an accurate Product Name, Company Name, and File Version.
2.4 Do Not Require a Reboot Inappropriately
In Windows XP, very few installation situations require a reboot. Reboots are unwelcome by customers and, in some situations, can make deploying applications difficult. The application must not require or suggest an unnecessary reboot during or after installation.
The most usual situation that may require a reboot is the installation of a Windows Service Pack or authorized system redistributable.
If a reboot is required, you must prompt users and allow them the option of deferring the reboot. If the component is required for first use, then this should be highlighted to the user; the application should not fail.
If multiple system components requiring reboot are installed, for example DirectX and Windows Media Foundation, then the minimal number of reboots should be determined and, if possible, deferred to the end of the title installation, before first use.
2.5 Install to Program Files by Default
By default, the application must install into an appropriate subdirectory where the current user's program files are stored. Do not use hard-coded paths to determine the location:
If your application does not require installation (it executes without any files being installed onto the system), then this requirement is not applicable.
2.7 Support Add or Remove Programs Properly
The application must supply your product's name, the location of your application's uninstaller, and so on, so that the Add or Remove Programs applet in the Control Panel can obtain information about the application as needed. You can write this information directly to the registry during install or, if you are using an installation system based on the Windows Installer service, you can set these values by using properties in the Windows Installer-based package.
This requirement is not applicable for an application that does not install - that is, if it executes without installing any components, writing to the registry, modifying the system, or leaving any files on the system other than user created files.
The application's uninstaller must correctly and fully remove the application.
2.8 Support "All Users" Installs
Applications are often used by more than one user on the machine. Your installer must default to all-users or provide all-users installation as the default option.
An unprivileged user may attempt to install the application. If a limited user cannot install the application or cannot install for all-users, the installation must degrade gracefully.
2.9 Support Autorun for CDs and DVDs
For applications distributed on CD, DVD, or other removable media that support Autorun, the first time the disc is inserted, the application must use Autorun to run the application or prompt the user to install. In the case of applications distributed on multiple discs, subsequent discs must either use the Autorun feature or continue installation without prompting the user to press a key or take other action when the CD has been inserted.
It is not acceptable to require the user to use Start/Run to launch the installation from the CD or DVD.
After the application has been successfully installed, reinserting the CD or DVD 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 recommended behavior is to start the game without further user interaction.
Windows XP provides an infrastructure that supports state separation of user data, user settings, and computer settings. Applications that use this infrastructure correctly offer the following benefits:
3.1 Default to the Correct Location for Storing User-Created Data
If files generated by the application are meant to be viewed and/or altered by the user outside of the application then they must be stored in the My Documents (or descendant) folder and a file association must be made. Do not use hard-coded paths to determine the location:
Application data, such as application state, temporary files, and so on, must not be stored within My Documents.
The benefits of using the My Documents folder as the default for data storage are:
3.2 Classify and Store Application Data Correctly
If files generated by the application are NOT meant to be viewed and/or altered by the user outside of the application then they must be stored appropriately. Do not use hard-coded paths to determine these locations.
It is recommended to store application data files appropriately as either common or per-user. That is:
Application data, such as application state, temporary files, and so on, must not be stored within My Documents.
Using the Registry
Applications may also use the registry to store read/write application data and configuration files.
Classifying and storing application data according to the guidelines in this requirement provides these benefits:
3.3 Deal Gracefully with Access-Denied Scenarios
By default on Windows XP, restricted user accounts (for example, Limited Users on Home Edition) cannot write to per-computer locations such as HKLM and the Windows directory. Only applications that classify and store data correctly, as described earlier, will be able to avoid access-denied errors and run successfully in this secure environment.
There are, however, legitimate scenarios in which access-denied errors are encountered by applications that classify and store data correctly, for example:
In these cases, the application must degrade gracefully when the access-denied error is encountered. Graceful handling can be accomplished by displaying an appropriate error message. For example:
Test Cases-3.3
As defined in Designed for Microsoft Windows XP Application Test Framework (see Application Test Framework):
3.4 Support Running as a Limited User
Applications must not require users to have unrestricted access (for example, Administrator privileges) to run. In other words, the application must function properly in a secure Windows environment. Complying with the previous requirements in this section will help to ensure that the application meets this requirement.
An application that does not install (that is: executes without installing any components) must still support use by a Limited User.
A secure Windows environment is defined as the environment exposed to a Limited (non-Administrator) user by default on a clean-installed NTFS system. In this environment, users can write only to these specific locations on a local machine:
However, applications defaulting to use of these folders do not comply with the other requirements of this section.
Users can also write to subkeys and subdirectories of these locations. For example, users can write to CSIDL_PERSONAL (My Documents) because it is a subdirectory of CSIDL_PROFILE. Users have read-only access to the rest of the system.
When the major features of the application can be successfully run by a non-privileged user, minor features are allowed to fail gracefully. These minor features must not be installed by any default mechanism (for example, a minimal or typical install) other than a complete install and must not be considered important for the operation of the program. Examples of such minor features include components necessary to support legacy file formats.