Games for Windows 技术要求：适用于 Windows XP、Windows Vista、Windows 7 和 Windows 8 上游戏的最佳做法

项目
08/07/2024

本文介绍了在 Windows 上运行游戏的技术要求和最佳做法。我们编写这些技术要求和最佳做法主要是为了涵盖 Windows Vista 和 Windows 7 以及旧版的 Windows XP 操作系统。这些最佳做法通常也适用于 Windows 8 上的桌面 Win32 游戏。

本文包含以下部分：

Windows 8 的区别
- 其他信息
Games for Windows
安全性和兼容性
安装
可靠性
适用于 Windows 的 Xbox 360 通用控制器术语
游戏中间件产品指南
资源

Windows 8 的区别

下面总结了将这些技术要求和最佳做法应用于 Windows 8 时的主要区别。

游戏资源管理器 UI 未显示

在游戏资源管理器中注册的所有游戏都将在新的 Windows UI 中以磁贴形式显示，但与游戏相关的许多元数据已不再显示。仍然可以使用游戏定义文件制作工具 (GDFMAKER.EXE)（现在 Windows 软件开发工具包 (SDK) 中提供了该工具）来创作元数据。还可以使用现有机制来部署元数据。继续使用 Windows 7 测试游戏资源管理器注册，并验证在 Windows 8 上安装新的 Windows UI 磁贴时是否显示（请参阅 1.1 游戏资源管理器集成）。

要下载 Windows 8 SDK，请参阅用于开发桌面应用的下载项。

使用游戏资源管理器 API 注册仍然是在 Windows 家长控制中注册游戏的机制

建议在已发布的 Windows 8 版本上运行 Windows SDK 版本的 GDFMAKER，以确保它可以填充当前支持的所有分级系统。

注意

此版本的 GDFMAKER 需要使用 .NET 4.0。

请参阅 1.2 支持家庭安全/家长控制。

现在有三种使用 XINPUT API 的选项，具体取决于需求

Windows 8 内置了 XINPUT 1.4。 Windows 商店应用和桌面 Win32 应用都可以使用 XINPUT 1.4。所有 Windows 版本都可以使用 XINPUT 9.1.0 来简化普通控制器，但 XINPUT 9.1.0 没有再分发包。所有版本的 Windows 还可以使用现有的 DirectX SDK 版本 XINPUT 1.3，该版本需要 DirectSetup 才能部署。

请参阅 1.4 支持适用于 Windows 的 Xbox 360 通用控制器。

Windows RT 上仅支持有限的一组桌面 Win32 应用

在 Windows 7 上运行的游戏可以并应该在 Windows 8 x86 和 x64 平台上正常运行。

请参阅 2.2 支持 Windows x64 版本。

确保正确进行 OS 检查

Windows 8 OS 版本为 6.2。 Windows 8 通过了建议用于游戏部署的当前最低标准测试。

DirectX 终端用户再分发包可在 Windows 8 上成功运行，就像在 Windows 7 上一样，以部署 D3DX9、D3DX10、D3DX11、XINPUT 1.3、XAUDIO 2.7、XACTEngine 等

但是，在只安装了.NET 4.0 的系统上，DirectSetup 存在一个已知的问题，这是因为对旧版托管 DirectX 1.1 程序集的部署处理造成的。此问题既适用于默认安装了 .NET 4.5 的 Windows 8，也适用于安装了 .NET 4.0 运行时的 Windows XP 计算机。但是，此问题不适用于 .NET 4.0 之前的任何 .NET 版本。虽然 Windows 8 有自动解决此问题的应用程序兼容性行为（需要网络访问），但我们建议继续部署 DirectSetup 的游戏更新到 DirectX SDK（2010 年 6 月）的 REDIST 文件刷新版本。与往常一样，如果将 DirectSetup 用于游戏，请将游戏剪裁为所需的最小 CA 集。

请参阅 3.4 正确安装 Windows 资源。

需要 .NET 2.0 兼容运行时（2.0、3.0、3.5）的游戏将继续使用现有的部署机制

这些游戏会触发 Windows 8 上的应用程序兼容性行为，以便自动启用 .NET 3.5 运行时（需要网络访问）。但是，我们建议 .NET 开发人员改为使用 .NET 4.0 运行时。

注意

旧版托管 DirectX 1.1 程序集与 .NET 4.x 运行时不兼容。

请参阅 3.4 正确安装 Windows 资源。

不建议使用依赖于 .NET 的自动运行程序或其他预安装技术

可以假设 Windows Vista 和 Windows 7 上只有 .NET 2.0 兼容运行时（2.0、3.0、3.5）。 Windows 8 默认只兼容 .NET 4.0 运行时。

请参阅 3.7 支持自动运行。

针对 Windows 8 更新了应用程序验证工具

Windows 8 SDK 包含此更新的应用程序验证工具。

请参阅 4.2 消除应用程序验证工具故障。

其他信息

Windows 8 和 Windows Server 2012 兼容性手册
 DirectX SDK 在哪里？

Games for Windows

游戏要求摘要

客户受益

电脑游戏是 Windows 系统上的重要娱乐体验，但多年来，易用性问题一直令用户感到失望。传统上，游戏的安装方式类似于应用程序，但其使用方式更类似于娱乐媒体（例如电影或歌曲）。游戏资源管理器等创新产品以不同于标准应用程序的一致方式展示游戏。这些创新还使游戏与音乐和图片一样，在 Windows 中享有优先地位。以下要求有助于确保 Windows Vista 和 Windows 7 提供更好、更易访问和更统一的游戏体验。同时，它们还能确保与 Windows XP 兼容。

1.1 游戏资源管理器集成

要求

在 Windows Vista 和 Windows 7 上，游戏必须显示在游戏资源管理器（游戏文件夹）中。选择后，游戏还必须显示正确的元数据，其中包括发布者、开发人员、发布日期、版本、Windows 体验索引分值、分级（如适用）和相关超链接。

如果游戏是通过在线游戏服务进行数字发行的，那么服务提供商也应出现在游戏资源管理器中。为确保正确处理提供程序并使用 RSS 源，应使用游戏定义文件 (GDF) 架构的第 2 版。（有关 GDF 的详细信息，请参阅“其他信息”。）

此外，游戏安装程序在 Windows Vista 和 Windows 7 上运行时必须遵守以下规则：

安装时不得在桌面、“开始”菜单或任何其他位置创建启动游戏的快捷方式。
不得创建用于删除的任务和快捷方式。
用户必须能够通过使用 Windows Vista 和 Windows 7 控制面板中的“程序和功能”或 Windows XP 控制面板中的“添加或删除程序”来删除游戏。

在 Windows XP 和以前的 Windows 版本中，游戏安装程序可根据需要自由创建程序组、桌面图标或快捷方式。

理由

Windows 游戏资源管理器的概念与 Windows XP 文件夹我的文档或我的图片类似。这样做的目的是将类似内容集中到一个地方，便于组织和开展与上下文相关的活动。游戏资源管理器扩展了我的文档或我的图片概念，允许对游戏进行更丰富的组织和控制。游戏资源管理器允许游戏玩家查看、组织其系统中安装的所有游戏并进行交互。它还能让游戏发布者更有效地传达重要的游戏信息。系统由数据驱动，便于游戏发布者在产品生命周期内更新游戏信息。

其他信息

要与游戏资源管理器集成，需要编写一个游戏定义文件 (GDF)，这是一个 XML 文本文件，与 Windows 图标一起作为资源嵌入二进制文件（可执行文件或 DLL）中。然后，游戏必须在游戏资源管理器中注册。此外，GDF 还能显示所提供的信息，如游戏名称、发布者、开发人员、网站链接和可选任务。请注意，支持任务只能是指向网站的链接，但播放任务也可用于可选的支持任务。

游戏资源管理器可以使用缩略图位图图像，但建议使用大图标 (256 256) 的 Windows 图标资源。图标资源应包括 24 位（真彩色）和 8 位 (256) 颜色深度的 256 256 48 48、32 32 和 16 16 图像大小。 Visual Studio 2008 和 2010 中提供的图标编辑器支持这些大图标格式，IconWorkshop Lite 也是如此。

DirectX SDK 中提供了与 Windows 游戏资源管理器集成的详细信息。 DirectX SDK 包含一个游戏定义文件 (GDF) 编辑器，以及一个包含在 GDFExampleBinary 示例中的 GDF 示例。另一个示例 GameUxInstallHelper 提供了将所需功能集成到现有安装系统中的例程。游戏定义文件验证工具 (gdftrace.exe) 为评估 GDF 提供调试支持。另请参阅《适用于 C++ 的 DirectX SDK 文档》中的“Windows 游戏资源管理器集成”。

Windows 7 引入了对第二版 GDF 文件架构的支持。新版本包括创建游戏任务的简化方法，以及对更新通知、游戏服务提供商、游戏统计和游戏服务提供商 RSS 源的支持。最新版本的 GameUxInstallHelper 可处理在 Windows Vista 中使用第 2 版 GDF 文件所需的所有注册和旧版支持。使用 2009 年 8 月或更高版本 DirectX SDK 中的工具和示例代码。建议使用第 2 版 GDF 文件，以便支持 RSS 源、游戏统计和更新通知。另请参阅示例 ProviderGDFExampleBinary 和 GameStatisticsExample。

在 Windows Vista 商业版、Windows 7 专业版以及 Windows Vista 和 Windows 7 企业版中，“开始”菜单上的“游戏”链接处于隐藏状态。通过单击“所有程序”，然后单击“游戏”，仍可在“开始”菜单中找到游戏资源管理器。

对于与游戏一起安装的相关应用程序，但不是游戏本身，可以在所有版本的 Windows（包括 Windows Vista 和 Windows 7）上自由创建开始菜单程序组、快捷方式和桌面图标。此类关联的应用程序应通过适用的 Games for Windows 要求；有关详细信息，请参阅游戏中间件产品指南。鼓励游戏服务机构在游戏资源管理器中注册为 Windows 7 游戏提供商。 1

1.2 支持家庭安全/家长控制

要求

游戏必须遵守以下规则，全力支持 Windows 家庭安全：

游戏不得要求用户拥有管理凭据才能玩游戏。安装、修补和删除可能需要管理凭据，但须符合第 3 节中的要求。（与此相关的是要求 2.1”遵循用户帐户控制指南“。）
由 Windows 支持的分级委员会（如 ESRB 和 PEGI）分级的游戏必须在其游戏定义文件 (GDF) 中包含指定的分级信息。 GDF 的每个本地化版本以及语言中立版本都必须包含所有可用的分级数据。
游戏必须在 GDF 中列出其可执行文件，以便为“一般应用限制”提供良好的用户体验，除非游戏使用了反盗版技术，在运行时创建随机命名的可执行文件。
游戏必须在启动过程中调用游戏资源管理器接口的 VerifyAccess 方法（如果可用），并在返回 *pfHasAccess 为 FALSE 时退出。

理由

所有游戏必须在“标准用户”帐户的上下文中执行，以允许受 Windows 家长控制的帐户玩游戏。家长希望有能力监控孩子玩游戏的情况。此外，许多行业、政府和宣传团体都希望有更好的方法让家长监督和控制孩子接触的游戏。结合游戏资源管理器提供的提醒结构，Microsoft 通过 Windows 家长控制为家长提供了这一功能。

即使是不参与分级委员会计划的游戏，要求提升权限也会给大多数用户帐户带来糟糕的游戏体验。如果启用了“家长控制”功能，则每次启动游戏时都需要家长输入管理员密码，情况就更是如此。

Windows 家长控制系统允许家长选择他们认为适合孩子的分级。 “家长控制”支持许多全球分级系统。 “家长控制”还允许家长根据“内容描述符”（如果适用的分级系统支持）限制对游戏的访问，并允许或禁止对单个游戏的访问。

Windows 家长控制的默认分级系统选择基于系统的区域设置，但用户可以在“控制面板”的“地区和语言选项”中进行修改。因此，每种支持的语言都应提供所有可用的分级数据，以便用户自由选择他们想要的分级委员会。

其他信息

没有分级的游戏仍必须满足支持作为标准用户进行游戏和调用 VerifyAccess 的要求。此类游戏默认为未分级类别，在“游戏资源管理器：中显示”未提供分级“文本，并受”家长控制“中”游戏限制“设置的限制。默认限制设置为“允许”。

如果包含的二进制文件未经 Authenticode 正确签名，则 GDF 中的分级信息将被忽略。请参阅要求 2.3。

DirectX SDK 中的“游戏定义文件编辑器”包含所有支持的分级系统，并会将这些信息正确复制到所有本地化版本的 GDF 以及非特定语言版本中。 GDFTrace 工具将解码并验证存在的所有分级信息。使用这些工具的 2009 年 8 月版本或更高版本。

游戏提供商的 GDF 通常不包含分级信息，并会受到未分级内容设置的限制。

操作系统	支持的分级系统
Windows Vista	CERO（日本） ESRB（美国） OFLC（澳大利亚） PEGI（欧洲） PEGI 芬兰（已弃用） PEGI 葡萄牙 PEGI/BBFC（英国） USK（德国）
包含 Service Pack 的 Windows Vista	Windows Vista 的 Service Pack 增加了对以下内容的支持： GRB（韩国） ESRB“轻度”变体内容描述符
Windows 7	Windows 7 支持 Windows Vista 支持的分级系统，并增加了对以下系统的支持： CSRR（台湾）
Windows 8	Windows 8 支持以前的分级系统，并增加了对以下系统的支持： COB-AU（澳大利亚） DJCTQ（巴西） PFB（南非） OFLC-NZ（新西兰） Windows 8 将不再支持以下现已弃用的系统： PEGI-FI（芬兰） OFLC（澳大利亚）

注意

任何包含新 ESRB Windows Vista Service Pack 1 (SP1) 内容描述符的游戏在没有 Service Pack 的 Windows Vista 上都会显示为未分级。

在不支持较新分级数据的操作系统版本上，这些数据将被忽略。 PEGI（芬兰）变体现已弃用，转而采用标准的 PEGI（欧洲）分级系统。在澳大利亚，OFLC 系统现已弃用，转而使用 COB-AU。

有关使游戏与标准用户权限兼容的详细信息，请参阅 DirectX 文章游戏开发人员的用户帐户控制。

有关游戏定义文件 (GDF) 的详细信息，请参阅要求 1.1。

1.3 支持丰富保存的游戏

[此要求已不再适用]

1.4 支持适用于 Windows 的 Xbox 360 通用控制器 [有条件的要求]

要求

支持游戏手柄控制器的游戏必须使用 XInput API 支持 Windows 版 Xbox 360 控制器。如果也支持 DirectInput 外围设备，则也可以使用 DirectInput。但是，如果使用兼容 Xbox 360 的设备，则 XInput 必须是默认的 API。

所有对常用控制器触发器和按钮的引用都必须使用 Xbox 360 名称。有关详细信息，请参阅适用于 Windows 的 Xbox 360 通用控制器术语列表。

当游戏处于暂停或中止状态时，必须关闭控制器振动。

任何时候都不能完全禁用鼠标/键盘控制。至少必须提供一个返回游戏菜单的选项。

理由

这一要求让玩家可以自由选择使用 Xbox 360 手柄或键盘鼠标，具体取决于哪种输入方法的界面更自然、更直观。

其他信息

此要求不适用于仅使用鼠标和/或键盘的游戏。

建议使用广为接受的标准控制器按钮来进行菜单导航：

A - 接受
B - 取消
Start - 接受或暂停
Back - 取消、返回一个屏幕或上一级菜单

有关详细信息，请参阅 XInput。

主题 XInput 和 DirectInput 讨论了同时使用这两个 API 的问题。

建议不要使用 DirectInput 来实现键盘或鼠标控制。键盘和鼠标控制只能使用 Windows 消息和 Win32 API 来实现。有关在不使用 DirectInput 的情况下获取高分辨率鼠标移动信息的详细信息，请参阅充分利用高清鼠标移动功能。

1.5 支持多个纵横比和分辨率

要求

游戏必须至少支持以下纵横比和关联的屏幕分辨率：

4:3 正常（800 600 或 1024 768）
16:10 宽屏 (1280 720)
16:10 宽屏（1152 720 或 1680 1050 或 800 480）

在屏幕分辨率配置和检测方面，游戏必须遵守以下规则：

如果显示设备的桌面分辨率是支持的分辨率，则游戏默认使用该分辨率。如果游戏选择了不同的默认分辨率，则必须将桌面纵横比作为搜索标准。
游戏必须在更改时提示用户确认新的显示设置。如果用户在 15 秒内未接受，显示屏必须恢复为先前的设置。
游戏不得拉伸像素或将 4:3 呈现窗口居中以支持宽屏纵横比。但是，“信箱”格式也可以接受。

理由

在使用 Windows 3D 桌面时，由于以下因素，无法假设特定的纵横比或分辨率：

支持高精细显示。
宽屏显示器的市场份额增加。
适用于 Windows 媒体中心的的 HDTV 部署。
辅助功能要求。

其他信息

理想情况下，游戏默认采用显示器的原始纵横比。但是，要可靠地获取这一信息可能是个难题，因此作为一种更通用的解决方案，游戏可以假定桌面以原始纵横比运行。通过使用 ENUM_REGISTRY_SETTINGS 来调用 EnumDisplaySettings 可获取桌面分辨率。

有关详细信息，请参阅 DirectX 文章面向 Windows 游戏开发人员的 10 英尺体验简介中的纵横比和宽屏部分。

1.6 支持从 Windows 媒体中心启动

[此要求已不再适用。]

1.7 Direct3D 支持

要求

如果游戏使用 Direct3D，那么支持的最低版本必须是 Direct3D 9，并且 Direct3D 必须是默认选择的呈现器。

理由

Windows Vista 和 Windows 7 的核心图形体系结构是围绕 Direct3D 设计的。 Direct3D 8 和更早版本通过重映射传统接口来支持。

强烈建议使用比 Direct3D 9 更新的 Direct3D 版本。请参阅“Games for Windows 展示 S.1”。要求 Direct3D 10 或 Direct3D 11 完全符合要求 1.7。

1.8 启用高 DPI 感知

要求

在 Windows Vista 和 Windows 7 上启用每英寸点数 (DPI) 缩放时，游戏及其安装程序必须能正确运行，不会出现视觉问题（在显示分辨率为 1600 1200 时使用 144 DPI 进行 150% 缩放测试）。

这通常需要游戏可执行文件声明支持 DPI 感知。这可以通过嵌入一个清单元素来实现：<dpiAware>true<dpiAware>。

理由

高质量的液晶显示器作为计算机显示器已司空见惯，以其原始分辨率（通常为 1280 1024、1600 1200 等）显示时效果最佳。在此分辨率下阅读文字和观看图像有困难的客户，通常会将电脑桌面设置为较低分辨率，从而会受到液晶屏缩放造成的视觉假象的影响。相反，客户可以将分辨率保持为原始大小，并更改 Windows 显示器的 DPI，从而在不影响图像质量的情况下使项目和文本显示更大。

虽然这项功能从 Windows XP 开始就以某种形式提供，但客户或 OEM 却很少启用它。根据客户的反馈，目前有一半以上的电脑显示器设置的分辨率都低于显示器的本机分辨率。 Windows 7 使客户在初始设置和更改显示设置时更容易看到这一功能，鼓励他们使用 DPI 缩放而不是更改桌面分辨率。

其他信息

如果在进程启动代码的早期调用 SetProcessDPIAware 函数，则可替代该函数。最好是添加到清单中，以确保在调用主入口点之前不会出现与软件元素（如 DLL）初始化的争用条件。请注意，只有 Windows Vista 和 Windows 7 中提供 SetProcessDPIAware。

在 Visual Studio 2005 和 2008 中添加清单元素非常简单；创建一个名为 dpiaware.manifest 的文件，在其中包含以下文本：

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

然后，在 Visual Studio 中将 dpiware.manifest 添加到项目中。确保在项目属性中将“嵌入清单”设置为“是”。请注意，旧版本的清单工具 (Mt.exe) 会对 DPI 感知清单元素生成虚假警告。要解决此问题，请从 Windows SDK 将 Mt.exe 更新为最新版本。

Visual Studio 2010 在项目属性中包含一个名为“启用 DPI 感知”的设置，该设置无需 dpiaware.manifest 这样的文件。通过展开“配置属性”和“清单工具”，然后选择“输入和输出”，找到“启用 DPI 感知”。

在 Windows 中，传统显示模式默认为 96 DPI，这在 CRT 显示器上很常见。

虽然全屏应用程序会改变显示分辨率，但在设置缓冲区和显示矩形时，它们通常会使用窗口信息和指标。 DPI 虚拟化会导致这些全屏显示模式出现裁剪，而声明 DPI 感知可以避免这些问题。有关详细信息，请参阅编写 DPI 感知 Win32 应用程序。

安全性和兼容性

安全性和兼容性要求摘要

客户受益

以下要求可提高游戏的整体安全性，并有助于确保游戏在不同体系结构、不同配置和不同模式下与 Windows 兼容。

2.1 遵循用户帐户控制指南

要求

每个可执行文件（即扩展名为 .exe 的文件）都必须包含一个嵌入式清单，而该清单通过包含以下标记来定义其执行级别：

            <requestedExecutionLevel>

根据要求 1.2，主游戏和 Autorun 可执行文件的执行级别必须为 asInvoker，以支持标准用户上下文。

在“文件资源管理器”中注册了文件关联的用户数据文件必须放在 CSIDL_PERSONAL 指定的文件夹（也称为“文档”或“我的文档”）的子文件夹中。所有其他用户数据文件必须存储在 CSIDL_LOCAL_APPDATA 或 CSIDL_COMMON_APPDATA 指定的文件夹的子文件夹中。（默认情况下，个人用户和所有用户都会隐藏这些目录。）

理由

如果应用程序只在有必要权限的情况下运行，则用户的 Windows 体验就会更加安全。

其他信息

如果应用程序中只有少数功能需要管理权限（例如，需要配置防火墙的应用程序），则应用程序的主进程仍必须使用标准用户权限运行。需要管理权限的功能必须转移到单独的进程中，如安装程序或配置实用工具。

如果不需要管理权限，则嵌入式清单 XML 应包括以下内容：

            <?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>

如果需要管理权限，则嵌入式清单 XML 应包括以下内容：

            <?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>

在 Visual Studio 2005 中，只需在项目中添加一个包含前述块之一的清单 (.manifest) 文件，并确保在清单工具的项目属性中将“嵌入清单”设置为“是”即可轻松嵌入。对于 Visual Studio 2008 和 2010，UAC 属性可直接在“清单文件”页面上的链接器项目属性中设置。请注意，旧版本的清单工具 (Mt.exe) 会对 UAC 清单元素生成虚假警告。要解决此问题，请从 Windows SDK 将 Mt.exe 更新为最新版本。

有关安装、修补和删除的特殊情况的详细信息，请参阅要求 3.1。

动态链接库 (DLL) 不需要使用此类清单。

有关用户帐户控制的详细信息，请参阅用于游戏开发人员的用户帐户控制。

2.2 支持 Windows x64 版本

要求

为保持与 64 位 Windows 版本的兼容性，游戏应满足以下要求。

游戏和游戏安装程序不得包含任何 16 位代码或依赖任何 16 位组件。
如果游戏依赖内核模式驱动程序运行，则必须提供 x64 版本的驱动程序。游戏设置必须为 64 位版本的 Windows 检测并安装适当的驱动程序和组件。

理由

许多 Windows Vista 和 Windows 7 用户将在产品生命周期内运行 64 位版本的操作系统，因此应用程序与该操作系统兼容至关重要。

其他信息

Windows on Windows 64 (WOW64) 允许在 64 位版本的 Windows 上运行 32 位代码，因此在 64 位版本的 Windows 上无需使用本机 64 位代码。 16 位代码无法在 64 位 Windows 版本上运行。

不要求与 Windows XP Professional x64 Edition 保持兼容，但强烈建议这样做。

有关详细信息，请参阅面向游戏开发人员的 64 位编程。

2.3 文件签名

要求

所有可执行代码文件（通常是扩展名为 .exe 或 .dll 的文件）都必须使用公开有效的 Authenticode 证书签名，并且必须有一个有效的时间戳服务器 URL 用于生产签名。

如果游戏使用 Windows 安装程序，则安装程序包文件（.msi 文件）必须经过签名。

理由

对文件进行签名有助于用户决定是否信任某个应用程序，并向用户保证文件未被篡改。它还让应用程序能够在锁定环境中正常运行。

其他信息

有关详细信息，请参阅面向游戏开发人员的 Authenticode 签名。

如果游戏使用 Windows 安装程序，则建议通过包含 MsiPatchCertificate 表来启用 UAC/LUA 修补。有关详细信息，请参阅用户帐户控制 (UAC) 修补。

我们不建议签署文件柜 (.cab) 文件，除非这些文件相对较小（小于 100 MB）。

2.4 驱动程序签名

要求

游戏安装的任何内核模式驱动程序都必须使用公开有效的 Authenticode 证书进行签名。

游戏安装的任何内核模式硬件设备驱动程序都必须有 Microsoft 签名，该签名可从 Windows 硬件质量实验室 (WHQL) 或驱动程序可靠性签名 (DRS) 程序中获取。

理由

编写不当或恶意软件驱动程序都会严重影响系统的稳定性和安全性。在 64 位版本的 Windows Vista 和 Windows 7 中，未签名驱动程序无法加载。 32 位版本的 Windows Vista 和 Windows 7 也可启用此策略。

其他信息

根据要求 2.2，需要所有内核模式驱动程序的 32 位和 64 位本地版本。

有关 Microsoft 驱动程序签名程序的详细信息，请访问 Windows 硬件开发人员中心。

2.5 执行正确的版本检查

要求

除非最终用户许可协议禁止在未来的操作系统上使用，否则游戏不得无法在 Windows 版本号发生变化的未来操作系统上运行。如果游戏应该失败，它必须通过向用户显示适当的消息来正常执行此操作。

如果进行 Windows 版本检查，则必须使用版本检查 API（GetVersionEx 或 VerifyVersionInfo）来检查操作系统版本。不得通过读取注册表项来确定版本。

游戏中不得存在 DirectX 运行时的显式版本检查。这些版本检查不得出现在启动 DirectX 运行时设置 (DirectSetup) 的安装中。

理由

当 Windows 用户升级其操作系统时，不应仅仅因为 Windows 版本号的增加而阻止他们玩当前的游戏。编写不佳的版本检查程序会不断给软件带来问题，而这些软件在较新版本的 Windows 上或只需添加一个 Windows Service Pack 即可正常运行。

当在不同版本的 Windows 上运行时，DirectX 运行时脆弱的版本检查比较逻辑会导致无数次安装失败。 DirectX 版本号仅适用于核心操作系统组件。它不适用于许多游戏使用的并行 DirectX SDK 组件。

其他信息

安装程序通常会检查操作系统的最低版本。但是，需要谨慎执行此检查，以确保它测试的是大于或等于，而不是简单的相等，从而锁定特定版本的操作系统。使用应用程序验证工具的 HighVersionLie 测试是确定安装程序如何应对 OS 版本号重大变化的一种快速简便的方法。

正确使用 DirectX 运行时再分发包（DirectX 安装程序）需要在安装过程中始终启动它，最好在静默模式下启动。这样，Microsoft 提供的代码就可以执行任何所需的版本更新。它还允许安装任何可选的并行 DirectX SDK 组件，如 D3DX、XACT、MDX 或 XInput。

有关部署 DirectX 运行时的最佳做法，请参阅面向游戏开发人员的 DirectX 安装。

建议支持 Windows XP 的游戏检查 Service Pack 级别是否为 2 或更高，因为 Service Pack 2 (SP2) 和 Service Pack 3 (SP3) 提供了重要的安全改进、简化的 DirectX 运行时再分发要求以及极其广泛的部署。支持 Windows XP 的大多数现代 Microsoft 技术都需要 SP2 或 SP3（XAudio2、Games for Windows - LIVE 等）。

2.6 支持并发用户会话

要求

依赖 3D 图形的游戏不需要通过远程桌面连接运行，但必须在游戏失败时提醒用户。

游戏必须遵守以下规则，以支持标准的 Windows 多任务方案：

游戏不得阻止并发用户会话的使用。
当游戏已经在另一个会话中运行时，必须在新的用户会话中运行。
一个用户会话中的游戏声音不得在另一个用户在不同会话中活动时被听到。
游戏必须支持快速用户切换。
游戏不得尝试禁用标准任务切换。游戏不得禁用 ALT+TAB 快捷键。允许游戏禁用辅助功能键盘快捷键，如在游戏中禁用快捷键中所述。

理由

Windows 用户应能运行并发会话，而不会发生冲突或中断。对于家庭、室友或其他人共用的 Windows 计算机而言，这是很常见的方案。

其他信息

要测试游戏是否在远程会话中启动，请调用 GetSystemMetrics(SM_REMOTESESSION)。非零值表示会话是远程的。

有关详细信息，请参阅快速用户切换。请注意，如果启用了“家长控制”时间限制，则在用户时间结束时会出现“快速用户切换”。有关更多详细信息，请参阅要求 1.2。

2.7 支持长名称

要求

如果游戏支持保存文件，则它必须能够保存名称和路径都很长的文件。游戏必须在任何用于创建文件名或路径的用户输入字段中正确处理特殊的文件系统字符，如 \ / ： * ? " <>。

当用户的用户名较长时，游戏必须正常运行。

理由

玩家习惯在底层操作系统支持的深层路径上使用长名称。

其他信息

长名称是指包含 Windows SDK 中定义的最大值的名称。

安装

安全性和兼容性要求摘要

客户受益

如果应用程序使用官方的系统组件分发方法，客户就可以放心地在 Windows 上安装应用程序，而不会降低操作系统或其他应用程序的性能。简化的安装体验为游戏提供了更方便、更无障碍的开箱即用体验。

3.1 支持简易安装

要求

游戏必须在设置用户界面中提供简化路径，具体实现方法如下：

最多显示一条 EULA 提示。
默认安装路径必须绕过所有安装选择（如安装文件夹或组件选择），假设默认选择，然后在安装成功后运行游戏或启动器，而无需额外提示。如果需要，还可提供定制安装选项，用于高级配置选项。
使用正确的 Microsoft 再分发包安装所需的操作系统组件（如 DirectX 和 Visual C 运行时）。安装应在无提示、无组件版本检查的情况下静默执行。
通过控制面板中的程序和功能删除游戏应用程序和生成的工作文件。建议提供用于删除用户创建的任何数据文件的选项。删除过程必须确保删除所有已安装文件，并清除所有设置（如防火墙例外列表条目和注册表项）。不得删除重新分发的操作系统组件。
如果游戏要求在 Windows 防火墙中添加例外，则设置过程要提示通知用户需要进行此更改。应在安装开始前出现此提示。

安装和删除可能需要管理权限。根据更新频率，修补时可能需要提示输入管理凭据。根据要求 2.1 用户帐户控制指南，游戏的正常运行不得要求具有管理权限。

理由

简易安装是一种以 Windows 为中心的游戏开发理念，旨在简化和精简在运行 Windows 操作系统的计算机上安装游戏的繁琐和混乱过程。通过利用一系列技术和最佳做法，减少了在 Windows 计算机上安装游戏时不必要的复杂性和预期风险，从而实现了轻松安装。

主要目标是：

缩短进入游戏和开始游戏所需的时间。
将对话框和选项的数量减少到极少甚至没有，以简化游戏安装体验。

一些传统的安装程序会出现提示，即使应用程序看起来已成功安装，但仍允许进行非功能性安装。例如，游戏可以要求用户接受 EULA。游戏安装完成后，会出现 DirectX EULA。该 EULA 允许用户拒绝，从而跳过 DirectX 运行时的安装。此方案可能导致游戏因缺少组件而无法运行。

其他信息

有关游戏安装、非传统游戏安装技术、兼容 UAC 的修补解决方案以及处理频繁修补的详细信息，请参阅以下 DirectX 文章：

注意

删除特定用户生成的数据文件只能针对当前用户和共用的用户位置。即使删除需要管理员凭据，也没有强大的方法来扫描系统，无法为其他用户删除特定于用户的文件。

3.2 支持安装的用户帐户控制

要求

游戏安装程序不得假定它与用户在同一上下文中运行。由于管理员凭据的提升，即使是单用户系统，特定用户的位置也会与安装程序和播放器不同。因此，当游戏首次运行时，它必须执行与安装过程不同的用户特定任务。

当用户主持或加入多人游戏时，不得出现 Windows 防火墙例外对话框。任何必要的配置都必须在安装时完成。设置说明应告知用户，该操作将作为设置的一部分进行。

游戏安装程序必须根据要求“2.1 遵循用户帐户控制指南”提供一个嵌入式清单，以指定所需的执行级别。

如果安装程序在安装完成后启动游戏，则必须在原始用户的上下文中启动。

理由

在 Windows Vista 中，Windows 操作系统最大的变化之一就是增加了用户帐户控制 (UAC)，默认情况下以较低的权限运行应用程序。因此，安装程序需要相应地管理权限级别。 Windows 7 也广泛使用了 UAC。虽然 Windows 7 改善了 UAC 的用户体验，但安装程序仍必须满足与 Windows Vista 相同的要求才能正常运行，而不能依赖于可能引起混淆的虚拟化行为。

UAC 在 Windows Vista 和 Windows 7 中默认处于活动状态，绝大多数客户（根据反馈，高达 88% 甚至更多）都启用了这一功能。

其他信息

有关配置 Windows 防火墙的详细信息，请参阅 DirectX 文章面向游戏开发人员的 Windows 防火墙和 FirewallInstallHelper 示例。

如果安装是由标准用户启动的，而且设置过程需要管理员权限（即提示输入管理员凭据），则安装过程结束时游戏的标准启动不符合这一要求的最后一个方面。它还会继承管理权限，而这也是一个潜在的安全风险。相反，安装引导加载程序应在成功调用安装程序后启动游戏。有关详细信息，请参阅 MSDN 杂志文章让应用与 Windows Vista 用户帐户控制完美配合。

3.3 安装到正确的文件夹

要求

默认情况下，为所有用户安装的游戏必须安装到 Program Files 文件夹。用户数据必须在游戏首次运行时写入，而不是在安装过程中写入。

理由

用户应能灵活地在需要的位置安装应用程序。他们还应该对文件的默认位置有一致和安全的体验。

其他信息

游戏可以利用各种已知文件夹位置（如 CSIDL_LOCAL_APPDATA 和 CSIDL_COMMON_APPDATA 指定的位置）来存储大量游戏数据和支持的可执行文件，以实现高级的按需安装和修补方案。

由于在所有用户安装过程中可能需要提升到不同的用户帐户，因此在安装时没有正确的用户位置来存储数据。此外，如果启用了文件加密，则加密文件只能由创建文件的用户帐户访问。

3.4 正确安装 Windows 资源

要求

应用程序不得尝试安装受 Windows 资源保护 (WRP) 保护的文件或注册表项。如果应用程序需要较新版本的系统组件，则必须使用包含系统组件的 Microsoft Service Pack 或 Microsoft 批准的安装包来更新这些组件。系统组件不得重新打包。

理由

Windows 资源保护 (WRP) 旨在确保受保护的系统资源只能通过经 Microsoft 批准的安装或更新机制进行更新。 WRP 可确保安装结果的可预测性，从而提高系统的可靠性。

其他信息

WRP 是 Windows 文件保护的后续版本，它可以保护在 Windows 文件夹中安装的大部分系统组件。 WRP 可保护大多数存储 COM 对象创建设置的注册表项。它还会保留某些供操作系统独占使用的文件夹。尝试访问受保护资源时，通常会出现拒绝访问错误。

有关与游戏一起部署 DirectX 运行时的最佳做法的详细信息，请参阅 DirectX 文章面向游戏开发人员的 DirectX 安装。

3.5 避免在安装过程中重启

要求

游戏安装程序不应假定从再分发包中安装 Windows 组件需要重启，除非返回结果或 Microsoft 文档指出需要重启。

如果游戏安装程序总是强制重启，则必须获得 Microsoft 的批准。

Windows 安装程序包中包含的“使用中的文件”对话框必须包含一个选项，以便在设置完成后自动关闭应用程序并尝试重新启动它们。

理由

安装后重启系统会给用户带来不便，通常也没有必要。

其他信息

有关详细信息，请参阅使用 Windows 安装程序和重启管理器。

3.6 正确使用文件版本控制

要求: 游戏安装程序必须正确检查，以确保安装了最新的文件版本。安装游戏时，绝不能回归任何不是由你生成的文件，或者倒回归并非由你生成的应用程序共享的文件。
理由: 共享组件和系统组件会经常更新，以进行安全修补和扩展功能。安装包含旧版本更新组件的系统不会导致已应用的更新和修复丢失。

3.7 支持自动运行 [有条件的要求]

要求

对于通过 CD、DVD 或其他支持自动运行功能的可移动媒体分发的游戏，在首次插入光盘时，应用程序必须自动运行或提示用户安装游戏，除非用户已禁用自动运行功能。

成功安装应用程序后，将光盘重新插入驱动器不得导致安装自动重新开始。询问用户是否要更新或更改安装选择是可以接受的。

虽然自动运行程序可以启动设置程序或其他需要管理权限的实用程序，但它不得提示用户提升权限（也就是说，根据要求 2.1，它必须在清单中包含 asInvoker）。只有在未安装游戏或用户特别选择游戏的情况下，才会发生权限提升。

理由

自动运行功能简化了媒体分发应用程序的使用体验，如通常需要将光盘插入驱动器中才能玩的游戏。

其他信息

要求用户通过文件资源管理器从 CD 或 DVD 启动安装是不可接受的。

对于在多张光盘上分发的游戏，后续光盘最好使用自动运行功能或继续安装，而不提示用户按键或采取其他操作。

在编写自动运行程序时，确保所有必要组件都已安装到新安装的 Windows 系统中。典型的应用程序依赖于设置程序安装的技术，但自动运行本身会在任何此类设置发生之前执行。一个常见的例子是自动运行程序失败，因为 Visual C 运行时 DLL 并未作为 Windows 安装程序的一部分。因此，自动运行程序必须使用应用程序本地 CRT 部署，或者必须静态链接 CRT。

为在 Windows Vista 之前版本的 Windows 上使用而编写的自动运行程序不应使用 .NET 运行时，因为 Windows XP 或旧版本的 Windows 尚未包含该技术。 Windows Server 2003 和 Windows Vista 是首批将 .NET 运行时作为操作系统一部分的 Windows 版本。

出于类似原因，自动运行程序不能要求必须存在 DirectX SDK 可选并行组件（如 D3DX9、D3DX10、D3DX11、XAudio2、X3DAudio、XACT、XINPUT 和 MDX 1.1）。

有关使用自动运行的示例，请参阅自动运行示例。

可靠性

安全性和兼容性要求摘要

客户受益

这些要求可以最大限度地减少崩溃、挂起和重启的次数，从而提高应用程序的可靠性。可靠性要求有助于确保软件更具可预测性、可维护性、可复原性和可恢复性。

4.1 消除不必要的重启

要求

所有应用程序安装程序都必须利用重启管理器 API 来避免系统重启（请参阅要求 3.5）。

游戏不得阻止关机。

所有应用程序都必须通过侦听和响应以下关机消息来响应重启管理器：

带有 LPARAM 的 WM_QUERYENDSESSION = ENDSESSION_CLOSEAPP (0x1): GUI 应用程序必须立即响应 (TRUE)，为重启做准备。
带有 LPARAM 的 WM_ENDSESSION = ENDSESSION_CLOSEAPP (0x1): 应用程序必须在 5 秒内返回 0 值，然后关闭。
CTRL+C: 接收此消息的控制台应用程序必须立即关闭。

理由

系统重启是一个重大中断。它们会带来糟糕的用户体验，因此应尽量避免。重要的系统更新等操作可能会需要重启。通过侦听关机消息，游戏和其他应用程序可以对重启管理器的请求迅速做出反应。这样，他们就可以避免效的重启请求出现不必要的延迟。

其他信息

如果游戏安装程序使用的是 Windows 安装程序技术 (MSI)，没有任何自定义操作，则会自动提供此功能。 Microsoft 再分发包也支持重启管理器。

有关重启管理器的详细信息，请参阅关于重启管理器。

4.2 消除应用程序验证工具故障

要求

在 Microsoft 应用程序验证器 (AppVerifier)（4.0 或更高版本）下运行游戏时，必须顺利通过以下测试：

基本测试：句柄、堆、锁、内存、TLS
杂项：DangerousAPIs、DirtyStacks

理由

AppVerifier 可测试许多导致 Windows 应用程序崩溃和挂起的已知问题，以及已知的安全漏洞。

其他信息

有关应用程序验证程序的详细信息，请参阅应用程序验证程序和在整个软件开发生命周期中使用应用程序验证程序。

此要求不适用于没有本地互操作的纯托管应用程序。

这些测试应在发布版本上运行。调试生成可能会产生错误故障。某些反盗版和反作弊技术会干扰 AppVerifier 的执行。因此，这些测试应在未启用反盗版和反作弊技术的情况下进行。

可能有必要将 Basics:Heaps 测试的 Full 属性设置为 FALSE，因为 PageHeap 已满会大大增加运行应用程序的内存压力。故障仍会被检测到，但如果只使用部分 PageHeap，可能会更难以跟踪。

如果使用应用程序验证工具中的 UAC/LUA 相关测试来满足用户帐户控制要求 2.1 和 3.2，则应使用标准用户分析器来查看结果。应用程序验证工具还提供了许多其他有用的测试，强烈建议在开发和测试中使用这些测试，以确保与当前和未来版本的 Windows 高度兼容。 HighVersionLie 测试用于验证是否符合要求 2.5。

Visual Studio Team System 包含集成到调试环境中的 AppVerifier 功能的子集。这可能有助于跟踪和解决基本测试：堆、句柄和锁测试中发现的问题。

4.3 支持Windows 错误报告和文件版本信息

要求

要启用 Windows 错误报告支持，游戏必须满足以下要求：

游戏必须只处理已知和预期的异常。不得禁用 Windows 错误报告功能。如果游戏中出现访问违规等故障，必须允许 Windows 错误报告功能报告崩溃。
所有可执行文件（如 .exe 文件或 DLL）必须包含准确的产品名称、公司名称和文件版本。
游戏的正常退出不得导致未知异常故障。

理由

Windows 错误报告 API 为 Microsoft 提供了重要的反馈信息，用于检测应用程序中普遍存在的崩溃和挂起现象。这使 Microsoft 及其合作伙伴能够快速检测并解决导致应用程序故障的系统和驱动程序问题。

其他信息

游戏可以包含自定义的未处理异常处理程序，以执行自定义的支持和报告功能，但必须将任何错误传递给 ReportFault 或 WerReportSubmit 函数。

在 Windows 桌面 UI 中查看文件属性并检查“版本”属性页面，即可验证文件版本信息是否正确。

有关 Windows 错误报告 API 以及如何分析使用该服务时生成的崩溃转储的详细信息，请参阅 DirectX 文章故障转储分析。

适用于 Windows 的 Xbox 360 通用控制器术语

名称	说明
A	A 按钮。
B	B 按钮。
BACK	Back 按钮。
（右/左）缓冲键	控制器右上角和左边缘的按钮。等效于手柄肩键。
方向键	控制器方向键。
方向键	方向键的公认缩写。
DP	方向键缩写和控制器标签。
RB、LB	左右缓冲键缩写和控制器标签。
RS、LS	左右摇杆缩写和控制器标签。
RT、LT	左右触发器缩写和控制器标签。
RSB、LSB	左右摇杆缩写和控制器标签。
START	Start 按钮。
（右/左）摇杆	控制器摇杆。以前叫做操纵杆。
（右/左）摇杆按钮	控制器摇杆按钮。以前叫做操纵杆按钮。
（右/左）触发器	控制器触发器。
振动	控制器马达产生的游戏反馈。不要使用隆隆声。
X	X 按钮。
Y	Y 按钮。
适用于 Windows 的 Xbox 360 控制器	Xbox 360 游戏手柄作为 PC 硬件 SKU 出售，包括一张 Windows 设备驱动光盘。
适用于 Windows 的 Xbox 360 无线控制器	Xbox 360 无线游戏手柄作为 PC 硬件 SKU 出售，包括一张 Windows 设备驱动光盘。

游戏中间件产品指南

介绍

游戏必须满足一系列技术要求，才符合加入 Games for Windows 计划的条件。任何随游戏发布的第三方组件（可执行文件、DLL、驱动程序等）也必须满足这些要求，游戏才符合相关条件。本文档重点介绍了游戏第三方组件要通过合规性测试而必须满足的最常见要求。安装程序和完整的游戏引擎/制作包应查看完整的 Games for Windows 技术要求文档，因为其中许多要求都会受到这些工具的影响。

Games for Windows 展示

介绍

Games for Windows 展示不仅仅是在 Windows PC 上提供可靠的游戏体验。通过实施这些功能，游戏可以在最新的 Windows 平台上为用户带来更精彩的体验。

Games for Windows 必须满足本文列出的所有技术要求，但展示功能是可选的。这些游戏可自由实现部分、全部或不实施这些展示。

S.1 利用 Direct3D 11

要求

Direct3D 11 是适用于 Windows Vista 和 Windows 7 的下一代呈现 API。利用 Direct3D 11 的游戏使用优化的内容、先进的呈现技术和新的硬件功能，可在支持 10、10.1 和 11 的硬件上创建引人注目的体验。

如果游戏也实现了 Direct3D 9，那么并排比较应能证明 Direct3D 11 在内容质量、视觉保真度、性能、场景复杂性和其他图形保真度方面都有明显改善。此支持须符合 Games for Windows 技术要求 1.7。

Direct3D 10level9 技术可用于在 Windows Vista 和 Windows 7 上支持着色器模型 2.0/3.0 Direct3D 9 级视频硬件，而不是使用并行 Direct3D 9 实现来提供广泛的硬件支持。但是，这还不足以证明这一展示。

在运行安装了 Direct3D 11 的 Windows Vista 或 Windows 7 的计算机上，游戏默认情况下应使用 Direct3D 11。

理由

Direct3D 11 API 基于 Windows 显示驱动程序模型 (WDDM) 和 Direct3D 10.1 基础结构，支持以下新功能：硬件分割、计算着色器、多线程呈现和资源创建、新的纹理压缩格式以及更灵活的着色器语言。 Direct3D 11 为现代显卡提供统一的硬件支持，包括最新一代的 Direct3D 11 部件、所有 Direct3D 10 和 10.1 显卡以及许多 Shader Model 2.0/3.0 Direct3D 9 显卡，这是 Aero 3D 桌面所需的最低要求视频硬件。

其他信息

将 Direct3D 9 呈现引擎迁移到使用新的 Direct3D 11 接口是一项定义明确的任务：

取消所有固定函数操作，改用可编程着色器。
将所有现有着色器更新为着色器模型 4.x/5 的新语法。
更新资源管理，以支持新的视图模型。
将所有资产转换为使用新的可用格式列表。
更新呈现状态处理以使用不可变状态块，并将着色器常量重新处理到常量缓冲区中。

这种转换对于启用 Direct3D 11 展示程序至关重要，尽管其结果并不符合利用新 API 的展示要求。

新的 API 和相关的 HLSL 编程模型为增强内容提供了许多机会：

利用现有的 Direct3D 10 硬件功能，如几何着色器、流输出、纹理数组和 BC4/BC5 压缩纹理格式。
利用现有的 Direct3D 10.1 硬件功能，如独立的每个呈现目标混合模式、MSAA 深度回读、MSAA 每个样本着色器访问、立方体映射数组以及呈现为块压缩 (BC) 格式。
在现有 Direct3D 10/10.1 显卡上使用 CS4.x（通过更新显卡驱动程序启用）或在下一代 Direct3D 11 显卡上使用 CS 5.0，使用计算着色器实现高级 GPU 算法。
使用自由线程资源创建和多设备上下文在多线程上进行呈现，从而提高多核系统的性能（使用更新的视频驱动程序）。有关更多信息，请参阅“Games for Windows 展示 S.3”。
利用 Direct3D 11 级视频硬件的新功能，如带有 hull 和域着色器的硬件分割、着色器模型 5.0 HLSL 着色器硬件功能、BC6HBC7 压缩纹理格式和动态着色器链接。

Direct3D 9 可以实现的技术（主要是通过较高的 CPU 利用率）能够高效地卸载到 GPU 上，从而释放 CPU 资源以支持其他游戏需求。

DirectX SDK 中提供 Direct3D 11 应用程序接口、支持工具和示例。另请参阅 Windows 中的图形 API。

S.2 利用 x64 本机

要求

游戏包含一个 64 位本机可执行文件，可在支持 x64 的硬件上运行 x64 版本的 Windows 系统，带来激动人心的全新体验。通过与 32 位版本的游戏进行并排比较，可以发现游戏内容的复杂性有了明显改善，整体加载时间有所缩短而性能也有所下降。

在 64 位版本的 Windows 中，安装时应始终将 64 位本机版本的游戏设置为游戏资源管理器和 Windows XP Professional x64 Edition 中快捷方式的默认设置。如果需要双重安装，则可以为 Windows Vista 和 Windows 7 上的游戏资源管理器指定一个指向 32 位版本的额外游戏任务，但默认情况下仍应保留 64 位本机版本。

请注意，游戏应支持 64 位版本的 Windows Vista 和 Windows 7，以满足此展示建议。鼓励支持 Windows XP Professional x64 Edition，但这并非必需。

理由

x64 技术为使用者和服务器市场提供 64 位寻址能力，包括为现有应用程序提供全速 32 位向后兼容性。 x64 是 AMD (AMD64) 和 Intel (EMT64) 路线图的关键部分，除超移动 CPU 外，所有当前和未来一代处理器都支持该技术。

Windows XP Professional x64 Edition 是第一个支持 x64 技术的面向消费者的 Windows 操作系统 (OS)，而 Windows Vista 和 Windows 7 则显著扩展了操作系统对 64 位消费者计算的支持。由于许多新计算机都标配了 2 GB 内存，因此进一步改进内存缩放并不会使无法寻址超过 2 GB 物理内存的 32 位单个应用程序受益。如今，许多游戏都面临着在 2 GB 虚拟地址空间的限制下容纳所有可用内容的挑战，特别是当与高端 GPU 上的大容量显存相结合时，采用 x64 技术可大大提高可支持的细节级别。

32 位游戏的 x64 兼容性是一项 Games for Windows 技术要求 (2.2)，但要充分利用新技术，则需要 64 位本机实现。

其他信息

64 位寻址的主要优点是能够直接访问超过 2 GB 的物理和虚拟内存。大虚拟内存地址空间允许广泛使用内存映射 I/O，而不必担心 32 位编程中普遍存在的虚拟机地址空间耗尽问题。游戏可以利用新空间大大改善加载时间，或者在某些情况下消除加载内容时的停顿。

在使用启用大地址 (/LARGEADDRESSAWARE) 链接器选项生成应用时，现有的 32 位应用程序可以处理具有完整 32 位数据的地址，从而享受 x64 版本带来的益处。在 32 位版本的 Windows XP 中，特殊启动模式允许此类应用程序寻址高达 3 GB 的 RAM，而 x64 版本则可为大型地址感知 (LAA) 应用程序访问高达 4 GB 的 RAM。虽然在 32 位应用程序中使用 LAA 并不符合这一展示要求，但对于那些未完全执行这一展示要求的 Windows x64 版本来说，这种桥接技术是提供额外缩放优势的极为有用的方法。

有关详细信息，请参阅游戏开发人员网站上的面向游戏开发人员的 64 位编程和 RAM、VRAM 和更多 RAM：64 位游戏现已推出。

注意

此展示的一个关键挑战是确保游戏所依赖的第三方库或组件可用于 64 位本机开发。许多旧版 Microsoft API 也已从 64 位本机环境中删除，这对包含关键系统旧版实现的引擎代码库来说是一个挑战。

S.3 利用多核处理器

要求

游戏实现了利用多核处理器的功能，可缩放到 3 核、4 核甚至更多核。

如果游戏支持单核或双核系统，那么与四核系统的并行比较应能显示出明显的新功能、额外的引人注目的效果、内容质量的改善和/或性能的提升。

由于游戏已经广泛支持双核缩放，而且各种 Direct3D 驱动程序增强功能也会自动利用双核缩放，因此双核缩放并不足以展示这一成果。

理由

CPU 性能的持续增长已从时钟频率的提升转向计算内核的增加。 AMD 和 Intel 的路线图都基于可缩放的多核设计。由于处理器发展的这一根本性转变，所有下一代游戏平台都采用了多核 CPU。单线程应用程序无法再从下一代 CPU 中获得显著收益。当常用的 CPU 内核数增加到三个或更多时，简单的多线程也将无法进行缩放。

其他信息

请注意，核心数不一定是 2 的幂次，因此游戏应线性缩放，并处理 3、4、5、6、7、8 等核心数。

只有在控制通信和线程同步成本的前提下，通过增加应用程序中的线程数量来进行缩放，才能获得收效。在短期内，基于特性的缩放可能会被证明是一种更简单的解决方案，它允许游戏在单核系统上不使用额外线程的情况下正常运行，并在额外的 CPU 能力可用时启用这些线程。

有关详细信息，请参阅 DirectX 文章中的在 Xbox 360 和 Microsoft Windows 中为多核编码和 Xbox 360 和 Microsof Windows 的无锁编程注意事项，以及 DXUTLockFreePipe 实用工具和 CoreDetection 示例。

利用 Direct3D 11 的自由线程资源创建和设备上下文有助于在呈现和加载图形资源时实现多核可伸缩性。请参阅“Games for Windows 展示 S.1”。

请注意，直接使用 CPU 指令 rdtsc 而不是使用 Windows API 在多核系统上计算时序，可能会导致某些硬件和操作系统配置出现问题；请参阅 DirectX 文章中的游戏计时和多核处理器。

S.4 支持 Games for Windows - LIVE

Microsoft 不再支持 Games for Windows - LIVE。

S.5 支持 Windows 触控

要求

在运行 Windows 7 并配备触控显示屏的计算机上，可使用触控和/或手势来玩 Windows 触控游戏。也可以使用键盘输入，但主游戏界面必须是触控式的。

根据技术要求 1.4，启用触控功能不应妨碍使用鼠标或通用控制器。

游戏安装程序预计不支持 Windows 触控功能。

理由

笔记本电脑和台式机都有支持多点触控的显示器，它们是 Windows 7 发布后推广的一项重要硬件功能。 Windows 7 支持整个桌面和常用控制界面的 Windows 触控。

其他信息

本机代码应用程序可通过 WM_TOUCH 消息并结合 RegisterTouchWindow 函数来访问多点触控。另请参阅操作和惯性 API。

Windows Presentation Foundation (WPF) 4.0 为多点触控界面提供了托管解决方案。

有关详细信息，请参阅 Windows 触控 SDK。

S.6 支持增强色

要求

支持增强色的游戏使用 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) 或 16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) 格式作为呈现后缓冲区和全屏显示模式。

通过使用增强色呈现目标，在对 10 位或 16 位范围进行色调映射时，高动态范围 (HDR) 内容可以用扩展或宽色域进行呈现。

理由

多年来，即使在 CRT 显示器盛行的年代，显示器也能达到显示每个通道超过 256 种颜色的水平。显卡上的扫描输出硬件一直都是一个限制因素。现代 GPU（包括大多数 Direct3D 9 类硬件和所有 Direct3D 10 类及更好的硬件）的扫描输出硬件每通道至少能达到 10 位，而硬件能力在未来将增长到每个颜色通道 16 位。高清电视互连系统（HDMI、DisplayPort）在设计上也能处理每通道超过 8 位的信号，模拟 VGA 也能传输此类信号。

其他信息

请注意，“增强色”或“Hi Color”在历史上是指从 256（8 位）颜色显示转为 15 或 16 位色显示。大多数显示系统早已采用真彩色，即 24 位色，或红、绿、蓝每个色彩通道 8 位。这里所说的“增强色”是指新一代的显示系统，每个单独的色彩通道可以超过 8 位。它也被称为“深色”。

建议的最佳做法

介绍

除了满足技术要求并在游戏中采用一个或多个展示外，所有 Windows 游戏都应遵循一些最佳做法。虽然这些建议不属于核心技术要求的范围，但我们强烈建议在所有 Games for Windows 游戏中采用这些要求。

资源

术语	说明
Games for Windows：测试用例	Windows XP、Windows Vista 和 Windows 7 上的游戏最佳做法
Windows SDK	Windows SDKs
用户帐户控制指南	Windows Vista 应用程序开发对用户帐户控制兼容性的要求
DirectX 开发人员门户	Directx 开发人员中心
Games for Windows 和 DirectX SDK 博客	Windows 游戏和 DirectX SDK
其他 DirectX 文章	DirectX 技术文章

通过

Games for Windows 技术要求：适用于 Windows XP、Windows Vista、Windows 7 和 Windows 8 上游戏的最佳做法

Windows 8 的区别

其他信息

Games for Windows

1.1 游戏资源管理器集成

1.2 支持家庭安全/家长控制

1.3 支持丰富保存的游戏

1.4 支持适用于 Windows 的 Xbox 360 通用控制器 [有条件的要求]

1.5 支持多个纵横比和分辨率

1.6 支持从 Windows 媒体中心启动

1.7 Direct3D 支持

1.8 启用高 DPI 感知

安全性和兼容性

2.1 遵循用户帐户控制指南

2.2 支持 Windows x64 版本

2.3 文件签名

2.4 驱动程序签名

2.5 执行正确的版本检查

2.6 支持并发用户会话

2.7 支持长名称

安装

3.1 支持简易安装

3.2 支持安装的用户帐户控制

3.3 安装到正确的文件夹

3.4 正确安装 Windows 资源

3.5 避免在安装过程中重启

3.6 正确使用文件版本控制

3.7 支持自动运行 [有条件的要求]

可靠性

4.1 消除不必要的重启

4.2 消除应用程序验证工具故障

4.3 支持Windows 错误报告和文件版本信息

适用于 Windows 的 Xbox 360 通用控制器术语

游戏中间件产品指南

介绍

更多建议

Games for Windows 展示

介绍

S.1 利用 Direct3D 11

S.2 利用 x64 本机

S.3 利用多核处理器

S.4 支持 Games for Windows - LIVE

S.5 支持 Windows 触控

S.6 支持增强色

建议的最佳做法

介绍

更多建议

资源

反馈

其他资源