Games for Windows - FAQ

Games for Windows titles are expected to work correctly on Windows XP Home Edition, Windows XP Professional Edition, Windows XP Media Center Edition (2005), Windows Vista Home Basic (x86 and x64), Windows Vista Home Premium (x86 and x64), Windows Vista Ultimate (x86 and x64).

Note   It is acceptable for a 64-bit (x64) only title to be branded Games for Windows and therefore only work on Windows Vista x64 and possibly Windows XP x64 Edition.

All technical requirements apply to Windows 7, and this will be reflected in the GFW TR 2009 update.

Windows 7 Home Premium (X86 and X64) and Windows 7 Professional (X86 and X64) are expected to be the primary editions of Windows 7 running games. There will be some users with Windows 7 Ultimate (X86 and X64).

Windows 7 Starter Edition is expected to be shipped on entry-level PCS such as netbooks, but these machines are unlikely to be 'gaming machines' in terms of capabilities. Casual games may find it worthwhile to support Starter Edition (X86 only).

Windows 7 Home Basic is shipping in emerging markets. Games looking to ship into China, India, Russia, or other emerging markets may find it useful to target Windows 7 Home Basic (X86 and X64x64).

All editions of Windows Vista use the same codebase and share the same technology base, with different editions using different defaults and enabling additional functionality. The Windows Vista Business and Enterprise editions include the same gaming technologies in all versions of Windows Vista, but reduce the visibility of the Game Explorer and do not support Windows Parental Controls / Family Safety features. We do not perform branding tests on these editions of Windows Vista, nor do we expect gamers to be running them.

Developers and publishers are free to support the corporate versions of Windows Vista, but they should be aware that these are often running in locked down environments that prevent users from elevating to administrator privileges.

For more details about the differences between Windows Vista editions, see the DirectX FAQ—in particular, "Q: What are the differences between the various editions of Windows Vista? How do they impact my DirectX application?"

All editions of Windows 7 use the same codebase and share the same technology base. The Windows 7 Professional and Enterprise Editions include Game Explorer and Windows Parental Controls, but these features are hidden or disabled by default. Game Explorer can be found under Start/All Programs/Games, and the Start/Games link can be enabled by the user. Windows Parental Controls is disabled when a machine is joined to a domain (domain join is supported by Windows 7 Professional, Enterprise, and Ultimate editions), but can be re-enabled by someone with administrator rights. Inbox games are not installed by default on Windows 7 Professional and Enterprise, but can be installed by someone with administrator rights as well.

Windows 7 Enterprise and Windows 7 Ultimate offer all the same features. Windows 7 Enterprise is available only through Volume Licensing, and Windows 7 Ultimate is available only through OEM or retail channels.

We encourage but do not require branded titles to support Windows XP Professional x64 Edition (Service Pack 2) and Windows XP Tablet PC Edition (2005). We currently do no testing on these versions of Windows in our verification tests.

There are no Games for Windows branding requirements or testing scenarios that cover older now unsupported versions of Windows, such as Windows 2000 Professional, Windows 95, Windows 98, Windows 98 SE, and Windows Millennium Edition. Games are free to support these versions of Windows, or not, as publishers choose, but such support must not interfere with meeting the technical requirements on the platforms we do test.

This practice adheres to Microsoft's Windows Life-Cycle policy:

http://www.microsoft.com/windows/lifecycle/default.mspx 

We do not test branded games on the Server editions of Windows. These versions of Windows are not aimed at consumers, and often have key multimedia functionality for games disabled or removed. Little or no application compatibility testing for gaming is performed for these versions of Windows.

Therefore, we recommend game developers and publishers not concern themselves with supporting or deploying their titles onto Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Business Server Editions, or Windows Home Server Editions.

The primary issue this TR is trying to cover is to discourage OS version checking at all. This tends to be done incorrectly, and is a major source of appcompat bugs. Instead, developers should be doing feature checks and not make assumptions about how this relates to the OS version. For example: Try to create a Direct3D 10.1 device to see if 10.1 is available. Don't check to see if the OS version indicates Windows Vista Service Pack 1 or later.

That said, many installers will block installation if an OS check fails. We strongly discourage any 'future-failing' OS checks. In other words, don't test to see if the OS version IS Windows XP or Windows Vista; check to see if it is AT LEAST Windows XP. >= fine. == bad

Because there are so many bad version checks in the field, the Windows 7 version number is actually "6.1".

One piece of advice we are suggesting is to not require "Windows XP or later," but to require "Windows XP Service Pack 2 or later." This check should only be done only in the installer, and should not be locked to a specific version. We pick this as a minimum for a number of reasons. For one, this delineates when the DirectX Runtime became part of the OS. If the product requires Windows XP Service Pack 2 or later, then DirectSetup will never need to install the core components such as "D3D", DSOUND, DINPUT, and so on. It will be needed only to install the required side-by-side libraries such as "D3DX9", "D3DX10", XINPUT, XACT, "XAUDIO2", and so on. This will greatly cut down the size of required REDIST.

Beyond this, many of our current game technologies are supported only on Windows XP Service Pack 2 or later. This would include GFWL, XACT, "XAUDIO2", and so on.

Part of the metadata populated into the Game Explorer GDF file are the game's recommended and minimum WEI scores. Many developers have been leaving these values at their default in the GDF Maker tool, so many games have default WEI scores. Windows Vista supports scores from 1 to 5, but few games run successfully on systems rated 1 or 2, and likely run well on systems rated 4 or 5.

Ideally, you would configure a system that matches your minimum spec and recommended spec, run the Windows System Assessment tool, and use those numbers as your baseline. This would be the minimum spec for a Windows Vista machine.

You can find general information about WEI at:

Note that for Windows 7 there have been some changes to the storage/disk performance test and new numbers introduction for ratings 6 and 7. See Windows 7 Known Issuesfor more details.

Games sometime install a number of non-game related applications such as Gamespy's tools or Adobe Acrobat Reader. It is acceptable for these applications to create shortcuts and start menu groups as long as (a) these applications are not games and are not subject to parental controls, and (b) they are not installed into the same directory as the game.

Add/Remove Programs should be supported on both Windows XP and Windows Vista, but you are free to create uninstall shortcuts on Windows XP if you choose, although we discourage it.

For GFW 2009, the GDF v2 schema is recommended. For games distributed digitally through an online service, registration of that service with GE is required. Also, we used to recommend the use of a thumbnail image. For GFW 2009, we recommend using Vista large icons instead.

Windows 7 includes an updated Game Explorer, GE 2, with some notable changes:

The March 2009 DX SDK includes an updated "GameUxInstallHelper" to support both the old and new versions of GE, as well as an updated GDF Maker.

The Game Explorer is present on corporate editions of Windows Vista, but the 'Start\Games' link is not there. Users must go to 'Start\ All Programs\Games' to find the Games Explorer.

Inbox games may or may not be present depending on the domain settings, and are not installed by default.

The Game Explorer is present on all editions of Windows 7. The 'Start\Games' link is not present by default on Windows 7 Professional Edition or Enterprise Edition. You can still find it by going to 'Start\All Programs\Games'. You can also enable it by going to Properties on the Start menu (click Start and right-click the blank part of the menu), select Customize, and set Games to Display as link.

Inbox games may or may not be present depending on the domain settings, and are not installed by default.

A number of games, including some Games for Windows branded titles, were not providing a sufficiently large thumbnail for Game Explorer to show nice images for 'large' icons. This is due to not providing the correct thumbnail, or providing one that is too small. The thumbnail provided as part of TR 1.1 should be 256 x 256 in size and scale well down to 48 x 48. The June 2008 DX SDK version of gdftrace checked for this, and ensures there is an icon present as well in the GDF containing binary for use in cases where the thumbnail is too big.

See the Game Explorer documentation under "Thumbnail Formats"

http://msdn2.microsoft.com/en-us/library/bb173443.aspx

NOTE   Windows displays thumbnail images with drop shadows; it does not add shadows to icons. This is why the in-box game icons do not have shadows. (They do not provide thumbnails, and use high-resolution icons instead.

The newer advice from the Game Explorer team is to not use the thumbnail at all, but instead provide a 256 x 256 x 24-bit color image in the icon. The August 2009 DirectX SDK gdftrace will warn about this.

In sum, the current recommendation is to not use a thumbnail image, but instead use a Vista large icon. The icon data should be provided in both 8-bit and 24-bit color depths for 256x256, 48x48, 32x32, and 16x16 sizes.

NOTE   Visual Studio 2005's icon editor does not support authoring these large 256x256 icon files. Visual Studio 2008's icon editor does. The Visual Studio team offers a free copy of IconWorkshop Lite as well.

Support for the CSRR (Taiwan) game rating system was added for Windows 7. The March 2009 DirectX SDK version of GDF Maker and gdftrace support this new rating system

Every game needs to support the prerequisites to use Parental Controls (runs as a Standard User per TR 2.1, installs to the Game Explorer per TR 1.1) and should perform the manual Verify Access call noted in the TR 1.2, even if it is unrated.

It is possible for a game to appear unrated despite having the rating information present. This is most likely because there was a failure to Authenticode sign the binary containing the GDF file that provides the rating information. This is covered under TR 1.1 and 2.3. Another reason might be if you included any of the new ESRB descriptors for Windows Vista SP 1 and are testing on Windows Vista RTM. See below for details.

There has been some confusion about how to author ratings data. The GDF localization story requires making a GDF for each language, but it is important that all supported ratings data be populated into every language's GDF. This is because the system defaults to a rating system based on the system's locale setting, but users are free to switch ratings systems as they see fit. In other words, while a Japanese version of Windows will default to CERO, a user could select ESRB or PEGI as the rating system.

The GDF Maker tool (aka Game Definition File Editor) in the DirectX SDK replicates this information automatically, but this means that all the localization & rating information needs to be brought together to create the correct GDF data. The GDF Trace tool in the DirectX SDK looks for this problem.

The content descriptors supported by Windows Vista match exactly those content descriptors on the ESRB website at the time. There were four content descriptors in early versions of the GDF Maker that are deprecated for Windows Vista: "Mild Language", "Gambling", "Mature Sexual Themes", and "Mild Lyrics". The GUIDS in the GDF Maker prior to the DirectX SDK (November 2007) version for these values map as follows in Windows Vista: "Mild Language" shows up as "Language", "Gambling" shows up as "Simulated Gambling", "Mature Sexual Themes" shows up as "Sexual Themes", and "Mild Lyrics" shows up as "Lyrics".

There is some concern here because the ESRB is giving publishers ratings with the "Mild" modifier in a way that does not strictly match their website listing. This was addressed in Service Pack 1, including properly showing "Mild Lyrics" and "Mild Language" GUIDS as above. See below under "Service Pack 1 vs. RTM" for details.

The PEGI Finland rating system is a PEGI variant where the 12+ category is replaced with 11+ and the 16+ category is replaced with 15+. This was the rating system used by Finland at the time Windows Vista was released. In 2007, Finland passed a law to mandate video game ratings and at that time they adopted standard PEGI. Game publishers are now getting 12+ or 16+ ratings from Finland which cannot be expressed in the PEGI-Finland rating system. They are standard PEGI ratings.

PEGI-Fi is considered deprecated, and the August 2009 DX SDK tools will highlight this. Developers should use PEGI instead. Details on servicing the Windows OS with respect to to the PEGI-Finland rating system are being worked out post–Windows 7 RTM.

Windows Vista supports CERO, ESRB, OFLC, PEGI, PEGI Finland, PEGI Portugal, BBFC, and USK. Windows Vista SP 1 adds support for the new Korean GRB. The GDF Maker tool as of the DirectX SDK (June 2007) release supports populating Korean GRB rating information. Such information will be ignored by Windows Vista, but will appear if the user selects GRB with Windows Vista SP1 installed.

In addition to stopping the user from launching a game, Parental Controls will block the entire subdirectory for the game. This means that multiple games should not share the same directory. Although this can be a problem for expansion packs, it is really only an issue if the expansion pack is given a different rating than the original game. The only solution is to do a side-by-side installation in different directories.

Windows Vista gold supports: CERO (Japan), ESRB (US/NA), OFLC (Australia), PEGI (Europe), PEGI Finland, PEGI Portugal, PEGI/BBFC (Britain), and USK (Germany). Windows Vista SP 1 adds GRB (South Korea). Windows 7 adds CSRR (Taiwan).

If a game has a rating in a supported system, we expect that data to be in the GDF. If the game is not rated in a given supported system, then it should not have data in the GDF and will be treated as an "Unrated" game. If the game is rated in a system not supported by Windows Vista, then obviously there is no requirement or ability to express that rating in the GDF.

What’s new in Windows Vista SP1 in terms of parental controls?

The GDF Maker as of Direct X SDK (November 2007) adds support for the ESRB descriptors changes listed above. What this means:

The corporate editions of Windows Vista do not support Windows Parental Controls / Family Safety features. All games appear unrated on these editions.

NOTE   Windows Parental Controls is supported on all editions of Windows 7. WPC is disabled by default when the machine is joined to a domain. See below.

For Windows Vista Ultimate, Windows 7 Professional, Windows 7 Enterprise, or Windows 7 Ultimate, Windows Parental Controls is disabled by joining the machine to a domain. It can be re-enabled by someone with admin rights to the machine.

The key aspect of this requirement is for games to support properly appearing content on aspect ratios other than the traditional 4:3. Specifically, we expect support for traditional 4:3, HDTV widescreen 16:9, and common widescreen monitor 16:10 aspect ratios.

Black bars on the top and bottom indicate letterboxing, which is acceptable, but black bars on the left or right would indicate centering, which is not acceptable.

Try the game on a widescreen monitor and verify it doesn’t stretch (i.e., that it has a wider field of view or uses black bars at the top/bottom for letterboxing) and that it doesn’t center (black bars on the left/right are not acceptable).

When implementing widescreen support, developers are strongly encouraged to increase the field-of-view when running widescreen resolutions rather than decrease it. While an open matte technique is a valid film method for doing theatrical widescreen and standard TV conversions, the results are less satisfying for games, particularly first-person views.

The TR simply requires true widescreen support, so either choice is valid for the branding.

For true 3D rendering, supporting widescreen modes properly is a straightforward case of using a different field-of-view setting and rendering to a widescreen render target. The challenge lies in coping with fixed-sized artwork assets like a HUD. TR 1.5 is similar to the existing Xbox 360 TCRs for supporting standard TV and HD resolution ("480p", "720p", etc.), so many developers are already doing the work to deal with this requirement.

Games using traditional 2D artwork have a bigger challenge to support widescreen. They need to create artwork elements for both standard size and widescreen formats. They could potentially create 4:3 and 16:9 content, and then use 16:9 content on 16:10 resolutions using letterboxing, but this is still more artwork than just doing 4:3 support.

Standard 4:3Streched 4:3 to widescreenTrue widescreenCenteringLetterboxing 

The essence of this TR is that a title cannot be Games for Windows branded if it supports only "Direct3D8" or some older API. Some game engines also support "Direct3D7" and "Direct3D8" rendering paths. This is acceptable as long as the default case for modern hardware is to use "Direct3D9" or later.

This TR is specifically written to not exclude "OpenGL" games from the branding program. If the game supports only OGL, then it meets the TR. If the game supports both OGL and Direct3D, then it must default to the Direct3D path to meet the branding. This is because most Windows systems come with Direct3D supporting drivers preinstalled, but only some have OGL drivers already installed.

The key point of this requirement is to force the use of embedded manifests with requested execution level. This implicitly disables any Limited User Account mitigations, and therefore forces the game to be LUA compliant.

It is important that a game that requires a patcher to be run to play (like, say, an MMORPG), that the patch solution not require elevation. Otherwise, every time a Parental Control account (Standard User) wants to play the game, they have to get a parent to come enter a password to get it patched before they can play.

For general patching solutions, we recommend the following article, which covers basics:

For the preferred MMO solution and example code for changing the ACL, we recommend the article:

TR 2.2 mandates that the game work on x64 versions of Windows, which can be accomplished with a 32-bit version of the game. We encourage developers to consider a 64-bit native version of the game for Windows x64 if they can implement additional value and features beyond the 32-bit version of the game, but x64 native versions of the game are not required.

All editions of Windows 7 (except Starter) are available in both x86 (32-bit) and x64 (64-bit) versions. Customers with a retail Product ID are free to use that PID on the x86 or the x64 version of a given edition of Windows 7. There is no upgrade path to move from x86 to x64, but the same PID can be reactivated on a fresh install of the x64 version of that edition. Windows Easy Transfer can be used to move data between x86 and x64 machines.

All the retail packages for Windows 7 include both the 32-bit and 64-bit media.

Windows 7 Starter is available only through OEM channels. Windows 7 Home Basic is available only in emerging markets. Windows 7 Enterprise is available only through volume licensing.

The GFW 2006 TR 2.2 implied that all x64 Editions of Windows had to be supported to meet the branding requirements. For GFW 2007, we updated the TR to focus on Windows Vista x64 support. We encourage, but do not mandate, support for Windows XP Professional x64 Edition.

There are benefits to running on x64 Editions of Windows even with 32-bit applications. A key one is that applications linked with /LARGEADDRESSAWARE can get 4 GB of virtual address space without any special boot modes. The best 32-bit versions of Windows can provide is 3 GB with special boot flags that may result in reduced system stability. As such, we expect to see games even without 64-bit native versions to still have some additional detail levels available when run on x64 versions of Windows.

See the Gamefest 2007 System-track talk "Why Your Windows Game Won't Run In 2,147,352,576 Bytes":

On both the x86 and x64 versions of the OS, 32-bit applications require the 32-bit CRT (VCREDIST_X86.EXE). On the x64 versions of the OS, 64-bit native applications require the 64-bit CRT (VCREDIST_X64.EXE). This means if you are installing both 32-bit and 64-bit native .exe files on 64-bit versions of Windows, you will need to run both redist packages.

One piece of advice we are suggesting these days is to not require "Windows XP or later" but to require "Windows XP Service Pack 2 or later". This check should only be done in the installer, and should not be locked to a specific version. We pick this as a minimum for a number of reasons. For one, this delineates when the DirectX Runtime became part of the OS. If the product requires Windows XP Service Pack 2 or later, then Direct Setup will never need to install the core components such as "D3D", DSOUND, DINPUT, and so on. It will only be needed to install the required side-by-side libraries such as "D3DX9", "D3DX10", XINPUT, XACT, "XAUDIO2", and so on. This will greatly cut down the size of required REDIST.

Beyond this, many of our current game technologies are supported only on Windows XP Service Pack 2 or later. This would include GFWL, XACT, "XAUDIO2", and so on.

The argument of adoption should be a non-issue. Microsoft put an unprecedented amount of effort into getting SP 2 into the hands of users. We sent out millions of CDS, put out ads, and the result is that almost all users of Windows XP have it. Anyone who doesn't have it already is directed to get it if they visit Windows Update. Requiring Service Pack 3 is not as easy a sell, but Service Pack 2 is really the proper baseline.

The Games for Windows branding does not mandate the use of VeriSign. Any authorized Certificate Authority for Microsoft Authenticode signing is fine. VeriSign is required by the winqual site to get direct access to Windows Error Reporting data, but this is again not mandated.

This is only a partial list. Note that there are lots of companies selling SSL (i.e., secure https web browsing) and organizational Class 2 Digital Certificates, but Authenticode requires a Class 3 Digital Certificate.

The GFW 2006 version of the TR only listed .exe and .dll files as required to be signed. For GFW 2007, we added .msi files. Ideally, .cab files would also be signed per Windows security procedures, the Windows Installer threat model, and the Certified for Windows Vista program requirements. For reasons explained below, we did not list .cab files as required to be signed, and warned about possible problems doing so.

GFW 2007 mandates that .exe, .dll, and .msi files be signed. It warns against signing .cab files to avoid problems with large .cab files. Small-sized .cab files work perfectly fine.

See Microsoft KB: http://support.microsoft.com/default.aspx/kb/925336/

Install Shield supports signing .msi files but only if you also sign .cab files. This is part of the Microsoft SWI requirements. This means developers have to a) support only Windows Vista or later; b) leave MSI unsigned, or sign it manually after the build; c) avoid the use of .cab files; or d) ensure that smaller .cab files are generated.

See Macrovision KB: http://support.installshield.com/kb/view.asp?articleid=Q113676

See Technical Requirement TR 2.7:

A common issue that is occurring is that game developers are not handling special path characters when forming file names from user input. In the GFW 2006 TR 2.7, we didn't explicitly mention this case but we did in the matching test case. For the GFW 2007 updated TR, this test case was reflected in the core requirement itself.

For example, a user can type the path character '\' in their input, and this creates a save game file name that creates a folder and a file. This is rather confusing when you try to reload it.

Part of the Easy Installation TR is to launch the game automatically after installation (at least for the Express or Default install path). If using an MSI-based installation, this typically works fine, but many game developers are using other solutions. If they mark their setup with "requireAdministrator", then typically launching the game directly from the setup will cause the game to run as administrator the first time they play it as all processes inherit the rights of their calling parent.

This is a problem both from a security perspective in that the game is running as admin, but this also means that per-user files are written to the administrator's account. If the original setup was started by a different account, the saved games and other files disappear when the game is exited the first time and rerun. The data all goes to the wrong account.

The most common solution here is to have the setup not launch the game directly. Instead, the Autorunner that started the install remains running, and upon a successful installation it launches the game on behalf of the setup. This means that the Autorunner must be marked as "asInvoker", which is already covered by the Autorun TR, and that starting the install process manually will not result in the game launching at the end of the installation process. The Autorunner needs to stay running for this to work, because if the setup tries to launch the Autorunner at the end, the problem still occurs.

See the MSDN article http://msdn.microsoft.com/msdnmag/issues/07/01/uac/ under "Problems During Installation" for details about this problem and this proposed solution.

The spirit of Easy Installation is to minimize Q/A, and just get the game installed and running with a minimum of fuss. We've addressed most of the common needs here, but the one remaining concern is games that ship with third-party programs like GameSpy Comrade that users typically want optional but that would introduce another prompt. The important thing is to prompt the user up-front before the installation starts, rather than pausing in the middle or at the end. The ideal solution is to combine this kind of option with another dialog box. For example, the "Express vs. Advanced" install dialog box can include an opt-in or opt-out check mark for GameSpy Comrade. This allows users to opt-out of this kind of optional service, while still having a minimum of prompts and questions.

The Games for Windows 2006 version of the TR document mentioned the Windows Firewall as part of TR 2.1, but this was often overlooked. As a result, the GFW 2007 version explicitly lists the Windows Firewall as part of TR 3.1 and 3.2.

There are two issues with the DirectX Redist that we tend to see most often. The first is that people continue to use the old school “prompt before installing” option. This can lead to serious problems, and is why we mandate that DX be installed silently in the Easy Installation TR. The second issue is that people tend to include everything and the kitchen sink in the DX SDK REDIST folder, although the game is almost guaranteed to need only a fraction of the files. They can save space on their media by customizing which CAB files to include. Be sure to highlight the following article to developers: http://msdn2.microsoft.com/en-us/library/bb219742.aspx

Note   The "...x86.cab" files are for 32-bit applications on both x86 and x64 versions of Windows. The "...x64.cab" files are needed only for 64-bit native applications.

Some installer writers forget that the game even has a dependency on the Visual Studio runtime. Some Windows XP era games worked fine but fail on Windows Vista, but only because those running Windows XP already had a particular version of the CRT installed by another popular program. No version of Windows comes with the CRT already installed, so game installers need to deal with this.

Typically, the installer is marked as "requireAdministrator", so on default Windows Vista it can never be started without admin rights. On Windows XP, the default account has admin rights so this works as well despite the fact that Windows XP ignores the UAC manifest details. One problem is that such a setup will start but likely fail on Windows XP Limited User Accounts. In general we do not cover the Windows XP Limited User Account scenario directly in the branding as it is largely the same as the Windows Vista Standard User, and LUA was seldom used on Windows XP.

The scenario can come up for Windows Vista if UAC is disabled. In this case, Windows Vista acts exactly like Windows XP by ignoring manifests. It is assumed that with UAC disabled, most users will revert to the Windows XP behavior of running with admin rights.

Some developers have noted this behavior and asked what to do. A simple solution is to check for admin rights inside the setup, and fail with an error if they don't have them. As the setup is marked as "requireAdministrator", this will always pass except in this LUA on Windows XP or Standard User on Windows Vista with UAC off case.

If you are using an MSI-based solution, this test might not be as easy to implement if the manifest is marked as "asInvoker". The MSI team recommends manifests be marked as "highestAvailable", which may or may not elevate and therefore can run both with and without admin rights. Such a condition might have to be checked in this case anyhow.

From a technical perspective, we want to avoid (a) failed installations resulting from users opting out of EULAS for required components like the DX REDIST, (b) annoying prompts for EULAS, and (c) prompts interrupting the installation process once it's begun. Therefore, we say always install required REDISTS silently (TR 3.4), and if you display a EULA, to combine them together into a single prompt (TR 3.1) at the start of the install.

Some games have felt they must show more than one EULA and have users accept them individually. This should be designed such that all these EULA prompts are shown before the install process begins.

The most common problem we've encountered is that Install Shield 12 has the wrong default manifest if using Install Script. "highestAvailable" is the recommended setting for MSI installs, but is not correct for Install Script, which needs "requireAdministrator".

There is a Macrovision KB that addresses this issue.

Be sure to be aware that applying this fix may create the problem of first-run-as-admin, as noted in Easy Installation.

There are really two different parts to DirectX REDIST: The core runtime bits (typically called "DirectX 9.0c") and the various SDK side-by-side components (D3DX for 9, D3DX for 10, XACT Engine, XINPUT API, etc.). Both are installed by Direct Setup / DXSETUP. It is not allowed by our EULA to distribute any of the SDK side-by-side components (or any other Direct X component) as a raw DLL in the application folder.

Games typically need to redistribute the version of the C Runtime they require. This TR requires that they use valid Microsoft REDIST rules. For 32-bit applications on either the x86 or x64 versions of the OS, they need to include the 32-bit CRT DLL files / REDIST package. For 64-bit applications on x64 versions of the OS, they need to include the 64-bit CRT DLL files / REDIST package.

The Direct3D 11 API and related technologies (DXGI 1.1, WARP10, 10level9, Direct2D, DirectWrite, and updated Direct3D 10.1) are all built into Windows 7. They will be included in a future Windows Vista Service Pack as well. They can be installed on Windows Vista SP2 by applying a system update KB971644 (aka Windows 7 Transition Pack for Windows). The DX SDK Sample D3D11InstallHelper shows how to do this detection and use the Windows Update API to download and install this update from an installer. Users with Windows Vista RTM or SP1 have to install the latest service pack. Offline customers cannot get KB971644. If they have automatic updates enabled, these should already be present on their system not long after the final bits are released.

D3DX11 and the HLSL compiler DLL D3DCompile is distributed through DirectSetup as usual, and are not included in any version of the OS.

See Technical Requirement TR 3.5:

http://msdn.microsoft.com/en-us/library/bb173456(VS.85).aspx#_3.5

DirectX Setup

Historically, installing DirectX runtime redist bits required a reboot. As such, many game install writers got in the habit of forcing one at the end of the install. These days, a reboot is rarely required after install, and should be avoided if at all possible.

The only time DirectX Setup requires a reboot is if it must update the core DirectX runtime bits like "Direct3D", "DirectSound", etc. It never requires a reboot to install SDK optional side-by-side components such as XACT engine, "D3DX9", "D3DX10", XINPUT API, etc. The core runtime bits are never updated on Windows XP SP2 or later because these are now all a part of the OS. Therefore, the only time Direct Setup will request a reboot will be on Windows XP or Windows XP SP1. Even then, it's unlikely to happen if they ever connected to Windows Update.

To get the proper result codes, developers should call the Direct Setup API directly and look for "SUCCESS or "SUCCESS_RESTART". They should require a reboot only if "SUCCESS_RESTART" is returned.

DXSETUP EXE when called with /silent will also return the Direct Setup API result code, so a 0 indicates success, 1 indicates success reboot, and negative numbers indicate error conditions (see http://msdn2.microsoft.com/en-us/library/bb173029.aspx). There are some install frameworks that will not return the exit code back unchanged, so in that case they may have to use the Direct Setup API directly instead.

See Technical Requirement TR 3.7:  

http://msdn.microsoft.com/en-us/library/bb173456(VS.85).aspx#_3.7

It is important that the autorun program never be marked as "requireAdministrator", and instead should always be marked as "asInvoker". Not having a manifest in the autorun at all is likely to cause Windows Vista to assume it needs elevation, which creates a poor user experience of getting an elevation prompt every time the disk is inserted into the drive.

The importance of this issue is highlighted in the GFW 2007 requirements by the addition of the following text:

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.

Dependencies

Because the Autorunner is the very first thing to run, it cannot have any external dependencies that are not already in-box with supported Windows versions. For example, the Autorunner cannot rely on the Visual Studio CRT DLLS to be installed because the game's installer may have to actually deploy them. This is the one case where we'd recommend statically linking the C Runtime.

The Autorunner also cannot rely on dot NET being present. The dot NET runtime is inbox with Windows Server 2003 and Windows Vista, but is not inbox on any version of Windows XP. It is pushed via Windows Update to Windows XP machines, but a fresh install of Windows XP will not have it. It is highly recommended that the Autorunner be written as a native application with minimal dependencies.

Windows Vista, Windows Server 2008 includes .NET 3.0 RTM 

Windows 7, Windows Server 2008 R2 includes .NET 3.5 SP1

For similar reasons, the Autorunner cannot require the presence of Direct X SDK side-by-side optional components like "D3DX9", "D3DX10", XACT, "X3DAUDIO", "XAUDIO2", XINPUT, MDX 1.1, etc. They can write the Autorunner to use these if present once the game setup has been completed, but it cannot require these components to run the first time.

NOTE   Version 1.2.0008 of the TR document includes notes about this issue.

See Technical Requirement TR 4.2:

http://msdn.microsoft.com/en-us/library/bb173456(VS.85).aspx#_4.2

Meeting the Application Verifier requirement for GFW has proven a challenge. Despite the tool having been around for years, few game developers ever paid it much attention. The public documents for TR 4.2 include links to documentation and support for using AV, but there are a few issues that crop up regularly documented here.

Which version to use

We've had some customers confused by the fact that there are three different versions of Application Verifier: amd64, ia64, and x86. x86 is the one they most likely need for a 32-bit game. amd64 is for 64-bit native (x64) games, and is the internal build name for the 'x64' technology now available from both AMD ("AMD64", aka "x86-64") and Intel ("Intel 64", aka "EM64T" or "IA-32e"). ia64 is for Itanium applications, which is unlikely to apply to any Windows-based game.

Immediate AV failure

Often trying to run the game with the App Verifier results in an immediate stop. On investigation, it turns out that this stop is random or seems to happen in a nonsense location. This is almost always because the .exe being tested is copy protected. Most copy protection technology (like "SecuRom" or "Tages") includes anti-debug technology. The AV tool looks and acts like a debugger, and it is recommended to run the application under a debugger to get the most detail.

Therefore, the public instructions state that such testing should be done on an unprotected release build of the game. Debug builds can cause false positives, and only unprotected builds will actually work correctly. Note that on a 'self-verified' log test a successful run is an empty file.

Turning on too many tests

The technical requirements mandate a specific set of tests. If other tests are turned on, there may be stops that appear to be branding blockers that are not. While other tests can be useful for their own purposes, they should not be enabled for the purposes of GFW compliance testing. The 4.2 test case itself is correct.

Running out of memory

One of the mandated tests, Basics:Heaps, implements a tool called pageheap. This tool detects memory leaks, but increases the amount of memory and virtual address space required to run the application. This can cause games tight on address space to crash. By setting the full property to false, you can greatly reduce the memory pressure and allow games to successfully complete this test.

Note that on Windows Vista gold there are additional VA memory pressures from the driver model compared to Windows XP. See the following KB article for more details and resolution: http://support.microsoft.com/default.aspx/kb/940105.

Use of a Debugger

Several of the tests mandated will trigger a 'debugger recommended' dialog box in the tool. This happens because when these Basics tests fail, the tool triggers a breakpoint. If the game is not running under a debugger, this will cause the application to crash. The windbg tool is an excellent free debugger that can be used, and when stops occur the game can often be continued to see if there are further stops.

Lack of Symbols

When the AV tool stops with an error, it will include a stack trace in the log. The value and detail of this log depends heavily on the ability to reverse the call stack. This can be improved by having matching .pdb symbol files for all modules. This means analysis of any problem is much easier if you have matching release .pdbs for your .exe and .dlls.

The system should also have use of the Microsoft Symbol Server set up to ensure full symbols for Windows components are available. Set an environment variable using the Control Panel as follows:

Windows XP: System / Advanced / Environment Variables / New

Windows Vista: System / Advanced system settings / Environment Variables / New

"_NT_SYMBOL_PATH" set to "srv*c:\symcache*http://msdl.microsoft.com/download/symbol"

and create the c:\symcache directory.

This is covered in a KB: http://support.microsoft.com/default.aspx/kb/311503

More information on using the Symbol Server can be found at: http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx

See Technical Requirement TR 4.3:

http://msdn.microsoft.com/en-us/library/bb173456(VS.85).aspx#_4.3

Changes to the TR

The majority of this TR is really about File Version Information, although the motivation is enabling better Windows Error Reporting. In combination with TR 2.3 Sign Files, this TR covers the requests from the WER team for all Windows software.

Accessing WER Data

In order for Microsoft to provide direct access to the WER data to a developer/publisher, you need to actually have used a Verisign ID to meet TR 2.3 Sign Files. Technically, any Certificate Authority will meet the TR, but the winqual website works only with VeriSign. For details on how third parties can get access to their application's WER data, see: http://msdn2.microsoft.com/en-us/isv/bb190483.aspx

File Version Information

http://msdn2.microsoft.com/en-us/library/ms646981.aspx

Company Name vs. Copyright

 The required values are Company Name, Product Name, and File Version. The possible confusion is that the Version info page on Windows XP shows Copyright, but the Windows Vista version of that dialog box does not show Copyright information.

Localization

Another issue we ran into was that Visual Studio 2005 will create the VERSION INFO record in the local system language. So the language for VERSION INFO could be English, or Japanese, or some other location. Early test results would flag the VERSION INFO as missing if it was not present as English. Windows is happy to display any language version

UAC Manifests

The Visual Studio 2005 manifest support deals only with their CRT Fusion requirements. It has no support at all for UAC manifests. This is fixed in VS 2008. You can configure it to deal with the UAC needs by setting an "Additional Manifest File" under the Manifest Tool property page in the project settings. Examples of these files are as follows:

asInvoker.manifest:                                

requireAdministrator.manifest:                                

Windows 9X/ME

Visual Studio 2005 does not support deployment on Windows 98 or Windows ME. It supports only Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and future versions of Windows.

Improvements from Visual Studio 2005 Service Pack 1

Windows 9X/ME/2000

Deployment of programs onto Windows 2000 is no longer supported in VS 2008. Windows 9X and Windows ME support was dropped as of VS 2005. VS 2008 supports only Windows XP, Windows Vista, Windows Server 2003, and future versions of Windows.

CRT Fusion Manifest Requirements

To meet the EULA for VS 2005/2008's CRT, you have three choices:

In any of these cases, you need to have the correct CRT dependency information in a manifest for your EXE to meet the EULA.

http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=90548130-4468-4BBC-9673-D6ACABD5D13B&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=eb4ebe2d-33c0-4a47-9dd4-b9a6d7bd44da&DisplayLang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&DisplayLang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=bd2a6171-e2d6-4230-b809-9a8d7548c1b6&DisplayLang=en

http://www.microsoft.com/downloads/details.aspx?familyid=D5692CE4-ADAD-4000-ABFE-64628A267EF0&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=7B50FDDF-4798-4FCE-8A8B-A8DFE556C8E4&displaylang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&DisplayLang=en

http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en

On both the x86 and x64 versions of the OS, 32-bit applications require the 32-bit CRT (VCREDIST_X86.EXE). On the x64 versions of the OS, 64-bit native applications require the 64-bit CRT (VCREDIST_X64.EXE). This means if they are installing both 32-bit and 64-bit native EXE files on 64-bit versions of Windows, they will need to run both redist packages.

We've had a few games in branding fail to run with an error that states:

The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail.

This indicates one of two problems:

Some developers/publishers fail to test their application on fresh Windows installs and make the false assumption that the Visual Studio CRT is already installed on Windows. It is not, although some games got away with it through the years because Office installed the version they used. No version of the CRT is preinstalled on any release of Windows.

There is a special case here: the Autorunner program you include should not depend on the Visual Studio CRT DLL because it will run before anything has a chance to install it. You can either statically link the CRT for the Autorunner or include the CRT DLLS side-by-side on the disk. The statically linked solution is probably best.

To unblock testing, you can manually install the Visual Studio CRT to get around this problem. If the manifest is completely missing, this may still not work on Windows Vista x64 even if you install the proper CRT.

There is also a Windows programming blog entry on the diagnosis of SXS errors: http://blogs.msdn.com/junfeng/archive/2006/04/14/576314.aspx

"D3DERR_NOTAVAILABLE"

During startup, some games have been running into problems where CreateDevice returns "D3DERR_NOTAVAILABLE". This is because Direct3D does not have access to the hardware when the secure desktop is active. Once the game starts, this is handled as a "D3DERR_LOSTDEVICE" situation, so the problem typically manifests itself only at startup.

The secure desktop comes up when the user locks their desktop, when the screen-saver activates, and on Windows Vista when the UAC elevation prompt comes up.

Games should handle this by retrying the device creation with some reasonable timeout. To cover all scenarios, they should not only call CreateDevice again but should destroy and recreate the Direct3D 9 device.

For Direct3D 9 Ex and Direct3D 10, this problem does not occur.

VA Space Fix

The VA space issue applies to all versions of Direct3D on Windows Vista, and is important when trying to exploit the large VRAM sizes available on many Direct3D 10 parts. This is included in Windows Vista Service Pack 1.

http://support.microsoft.com/default.aspx/kb/940105

ALT+TAB Behavior Change

The "Direct3D9" and prior era behavior with a full-screen application is that ALT+TAB returns to the desktop, and doing it again returns to full-screen. DXGI's default behavior for "Direct3D10" is for ALT+TAB to return to the desktop, and ALT+TAB brings the application forward again but in a windowed state. You have to hit ALT+ENTER to return to full screen.

Many developers have complained that this is confusing and that many users don't even know about the ALT+ENTER shortcut. Many titles have therefore implemented a work-around that causes ALT+TABing back to the application to put it back into a full-screen state when using D3D10. DXUT demonstrates how to do this with some handling of WM_ACTIVATEAPP messages.

See DXSDK Samples\C++\DXUT\Core\DXUT.cpp and search for WM_ACTIVATEAPP in "DXUTStaticWndProc".

In box HLSL compiler

Some developers have been confused by shader problems trying to use D3D10. In some cases this has been because they are using the inbox HLSL compiler via the D3D10Compile* APIs instead of using D3DX10Compile* APIs. The in box compiler has been unchanged since before the RTM date of Windows Vista, November 2006. There have been numerous fixes, improvements, and updates to the D3DX version of the HLSL compiler since that time. The in box API does not support shader model 4.1, and is generally inferior in terms of performance. Developers should use the D3DX10 API or the D3DCompiler.DLL directly.

FX 10.1

The Effects system for 10.1 does not support texture cube-map arrays. The HLSL will compile, but will fail to create the effect instance.

WDDM Timeout

When writing really complex shaders or running at low FPS, games can run into problems where Windows Vista thinks the GPU has hung and resets it. The registry keys documented in the article below are useful for testing, but should never be set by a deployed application. Typically, adding Flush calls on a more regular basis can help, but for some scenarios complexity needs to be reduced.

http://www.microsoft.com/whdc/device/display/wddm_timeout.mspx

Intel Integrated Graphics

Intel Integrated Graphics parts pose a number of challenges to developers to support, especially given the large variety of legacy devices, abandoned devices, and out-dated drivers.

The best advice available on supporting these components can be found on the Intel website:

http://software.intel.com/en-us/articles/intel-graphics-media-accelerator-developers-guide/

What's New in Service Pack 2

Service Pack 2 contains all the Service Pack 1 content, roll-ups of hot fixes since then, plus a few updates, none of which are big news for gamers or game developers. See http://technet.microsoft.com/en-us/library/dd335036.aspx for details.

The most notable thing about SP2 is that it will be a hard prerequisite for the down-level story for Direct3D 11 through the Windows 7 Transition Pack for Windows.

There was also a change in behavior of asynchronous I/O operations from Windows Vista RTM/SP1 to SP2 when done with cached files. Windows 7 and Windows Vista SP2 have been reverted back to the XP-era behavior when doing cached asynchronous I/O operations. Unbuffered asynchronous I/O operations work truly asynchronously across many platforms, so that is recommended (using FILE_FLAG_NO_BUFERING). Details of the issue that gave rise to this change are in:

http://support.microsoft.com/kb/961719

What's New in Service Pack 1

Full details of what's new in SP 1 is really beyond the scope of this Wiki. Here I'm highlighting the changes of particular importance to games

NOTE   System control panel in SP 1 now reports physically installed memory, not usable memory. This means it will happily report 4 GB or even 32 GB of RAM on 32-bit versions of Windows Vista even though the OS can never use more than about 3.5 GB or less. X64 versions of Windows are the only way to truly support 4 GB of RAM or larger. This seems to have been done to appease OEMS, but it really only serves to hide the need for moving to x64 technology. See KB 929605 and 946003.

http://support.microsoft.com/kb/929605/http://support.microsoft.com/kb/946003/

See also Parental Controls, Exploit Direct 3D 10

Tech Net documentation on SP 1

http://technet2.microsoft.com/WindowsVista/en/library/20184cb6-7038-4e82-a32c-4bc10ffe56ab1033.mspx?mfr=true

KB Articles for included Fixes

http://support.microsoft.com/default.aspx/kb/940105

http://support.microsoft.com/kb/936710/en-us

http://support.microsoft.com/kb/945149/en-us 

Some KB articles about issues that might arise getting Service Pack 1 from Windows Update

http://support.microsoft.com/kb/948187

http://support.microsoft.com/kb/948343

Vista Basic Color warning

A number of games are disabling Windows Vista's Desktop Windows Manager. Normally when a game starts up in full-screen mode, this is automatically disabled to remove a performance overhead of the composition. Several games, however, are using either a fake full-screen mode (actually a windowed mode) or have a very complicated Windows-based UI (such as Flight Simulator uses). To prevent the performance problems, they are programmatically calling "DwmEnableComposition" (http://msdn2.microsoft.com/en-us/library/aa969510.aspx) with the "DWM_EC_DISABLECOMPOSITION" parameter to disable DWM. In these cases, as the game launches, Windows Vista displays a notification that the desktop is switching to "Basic Color" mode. This is expected and there is no way to hide this notification. The standard desktop mode will automatically be restored when the application exits.

Windows Vista introduced a new display driver model, WDDM (formerly known as LDDM). There are many changes to the driver model, but a key one is how DEFAULT vs. MANAGED resources are handled. As a result of this implementation in Windows Vista gold, some 32-bit games been running out of Virtual Address space and crashing. Since the game is typically pushing the limits of 32-bit VA space on Windows XP, the extra usage in Windows Vista is killing the game. The bug might not show up as a failed memory allocation, and is likely in some API call that is indirectly trying to allocate memory.

A workaround for this issue is to a) supply a 64-bit native version of the game (see GFW Showcases), or b) supply a 32-bit version of the game with LARGEADDRESSAWARE enabled. To make use of the LARGEADDRESSAWARE mitigation, users must either have 64-bit versions of Windows or set boot options on their 32-bit version of Windows.

A change to WDDM to mitigate the disparity between Windows XP WDM and Windows Vista WDDM is now available as KB 940105 (http://support.microsoft.com/default.aspx/kb/940105). This change will be in Windows Vista SP 1.

Full technical details on this issue can be found in the Gamefest 2007 System-track talk "Why Your Windows Game Won't Run In 2,147,352,576 Bytes":

See also VAQFEDetect.

http://download.microsoft.com/download/e/3/c/e3c25fea-2b53-4174-8729-29a4ec16583b/Why%20Your%20Windows%20Game%20Won%27t%20Run%20In%202,147,352,576%20Bytes.zip

DirectX Runtime Differences for Windows Vista

In general the Windows Vista version of the DirectX Runtime (referred to as "DirectX 10" on Windows Vista RTM and "DirectX 10.1" on Windows Vista Service Pack 1 by DXDIAG) is very similar to "DirectX 9.0c" that is included in Windows XP SP 2 and the Direct X SDK (Summer 2004) release.

There are some differences, particularly for deprecated components, that may come up for games: "DirectPlay Voice" and "Direct3D Retained Mode" are not available. Also, the "DX7" and "DX8" support for Visual Basic 6.0 is not available on Windows Vista. This is the primary reason why "DirectPlay Voice" and "Direct3D Retained Mode" headers and libraries were removed from the Direct X SDK as of the November 2007 release.

More details and other differences are noted in the DirectX FAQ: http://msdn2.microsoft.com/en-us/library/bb219721.aspx

See also:http://support.microsoft.com/kb/969150http://support.microsoft.com/kb/970978http://support.microsoft.com/kb/971028

Program Compatibility Assistant

Many existing applications run on Windows Vista as a 'legacy' application. Many shims, UAC virtualization, and other techniques are employed for such applications. As a result, such applications are run as part of a job object called "PCA", and some extra dialogs may be presented as a result.

We've had some developers run into problems by wanting to use job objects on programs that may or may not be run under PCA. Normally you cannot change the job for a process, which means the implicit PCA job caused a problem. The standard Create Process method includes a flag to indicate that the job can be changed, but there's no direct equivalent for the Shell Execute method. Create Process cannot show UAC elevation, so they were stuck with Shell Execute. There is a flag for Shell Execute Ex SEE_MASK_FLAG_NO_UI which has the side-effect of not placing the process into the PCA job.

By following the Games for Windows requirement of adding UAC information into an embedded manifest, branded games will not be treated as legacy applications and will not be subject to PCA functionality in Windows Vista.

Seehttp://msdn.microsoft.com/en-us/library/ms684161.aspxand http://www.microsoft.com/msj/0399/jobkernelobj/jobkernelobj.aspx

Windows Vista Audio

The new OS includes an entirely new audio stack. "DirectSound" was updated to support this new audio stack on Windows Vista, which is basically the same functionality on Windows XP with better multichannel support but without any hardware acceleration. The net impact of this change on games is that EAX and similar technologies do not work through Direct Sound on Windows Vista, and all 'hardware' buffers fail to create.

For existing applications, these changes shouldn't break audio as they were both already optional and they had to handle software fallback for Windows XP applications. The biggest problem is with surround sound/multichannel support. Typically, games will try hardware multichannel, try hardware stereo, and then fallback to software stereo. They should really try hardware multichannel, try software multichannel, try hardware stereo, then fallback to software stereo. On Windows XP, only hardware multichannel will ever work, and only on specific devices and drivers. On Windows Vista, software multichannel will pretty much always work, but hardware buffers of any kind will always fail. This made it appear for some games that Windows Vista broke surround sound, when in fact it really provided more universal surround support.

Note that, in general, most games are using systems like RAD Game Tools MSS, FMOD, or some other middleware that is doing all the work in software and just using DirectSound to output. As long as these technologies are updated to handle the 'try stereo multichannel' option, most of the games will be covered. Games with custom audio engines will need to add this, and XAudio2 does the right thing. For those few game developers who feel that hardware-accelerated audio effects are a key part of their business, we should direct them to Creative's "OpenAL". Their 'Alchemy' Direct Sound hack is not something we are particularly happy about, and at this point we are not commenting on it.

Compatibility Mode

Sometimes problems with games under Windows Vista are 'fixed' when run with the Compatibility Mode enabled. It is not acceptable for a branded title to require this setting, but if problems arise and appear to be corrected by turning this setting on, it can provide a hint as to the root cause. For more details, see Windows Vista Compat Layers.

It would also be a clear violation of User Account Control guidelines to require or set the "Run as administrator" checkbox in a shortcut.

System Restore Monitor

A number of file extensions have special meaning, and Windows includes a system to automatically monitor important file extensions and back them for System Restore. Games should avoid using any of these file extensions for their custom data formats in order to avoid the performance penalty associated with this monitor activity, and this seems to affect Windows XP and well as Windows Vista.

A list of monitored file extensions is documented on MSDN:http://msdn2.microsoft.com/en-us/library/aa378870.aspx

High-Resolution Icons

Windows Vista will scale icons larger than Windows XP would, which can high-light low quality icons. If there is no 256x256 icon image, then the up-scaling can result in an ugly looking icon.

Standard Windows Vista Icons should include the following:

  256x256 at 24bit+alpha (should be PNG compressed) and 8-bit

The VS 2005 icon editor doesn't support this, but VS 2008+ does. The VS team also recommends a third party solution:

http://blogs.msdn.com/vcblog/archive/2008/08/11/iconworkshop-lite-now-available-for-download.aspx

See the following for more information:

http://msdn.microsoft.com/en-us/library/aa511280.aspx

Windows 7

Windows Experience Index

Windows 7 increases the maximum rating from 5.9 (Windows Vista) to 7.9. The intention is for the scores to be more or less stable, so if your machine rates a 4 now it will always rate a 4 within a few tenths. If your system was capped out at 5.9 in a particular area with Windows Vista, it may get a higher number for Windows 7.

The Gaming Graphics score can only be 6 or higher if it is D3D10. D3D9 is limited to 5.9. Note that the D3D10 tests are only run with WDDM 1.1 drivers. A WDDM 1.0 driver will limit the score to 5.9.

The Memory score will be limited to 5.5 with less than 3 GB of RAM, and to 5.9 with less than 4 GB of RAM.

The CPU score does not have an explicit core count cap, but should roughly correspond to: 6.3–6.9 for triple core, 6.9–7.x for quad-core, 7.9 for 8-core with HT.

There was, however, a major change made to the storage/disk performance test for Windows 7. Many users were having performance issues that were traced to a write policy cache problem with the hard drive. The Windows 7 WINSAT tests were updated to specifically test for this issue and that can limit the score to 2 or 3. Some users may well see their overall score drop with Windows 7 due to the storage/disk score being clamped as a result of this new test. Getting a new hard drive will likely improve overall system performance.

Windows Vista era WEI values are explained in depth here:

http://windowsteamblog.com/blogs/windowsvista/pages/windows-experience-index-an-in-depth-look.aspx

DirectX Runtime Differences for Windows 7

The Windows 7 version of the DirectX Runtime is the same as Windows Vista with the addition of Direct3D 11, WARP10, 10level9, DXGI 1.1, an updated Direct3D 10.1 to support WARP10 and 10level9, Direct2D, and DirectWrite. No new components are deprecated.

Deploying the updated DirectX Runtime on Windows Vista is done through the Windows 7 Transition Pack for Windows.

NOTE   DirectMusic "core" API (i.e., timestamped MIDI) is now available for x64 native applications on Windows 7. This support is not available down-level.