Поделиться через

Игры для Windows Technical Requirements: рекомендации по играм в Windows XP, Windows Vista, Windows 7 и Windows 8

  • Статья

В этой статье приведены технические требования и рекомендации по играм, работающим в Windows. Мы написали эти технические требования и рекомендации в первую очередь для покрытия Windows Vista и Windows 7, а также устаревшей операционной системы Windows XP. Эти рекомендации также обычно применяются к классическим играм Win32 в Windows 8.

В этой статье содержатся следующие разделы:

Различия для Windows 8

Ниже приведена сводка ключевых различий при применении этих технических требований и рекомендаций к Windows 8.

Пользовательский интерфейс обозревателя игр не отображается

Все игры, которые вы регистрируете в обозревателе игр, отображаются как плитки в новом пользовательском интерфейсе Windows, но большая часть метаданных, связанных с заголовком, больше не отображается. Вы по-прежнему используете средство создания файлов определения игр (GDFMAKER.EXE), которое теперь доступно в пакете sdk для разработки программного обеспечения Windows, чтобы создать метаданные. Вы также используете существующие механизмы для развертывания метаданных. Продолжайте тестировать регистрацию обозревателя игр с помощью Windows 7 и убедитесь, что новая плитка пользовательского интерфейса Windows отображается при его установке в Windows 8 (см . интеграцию 1.1 Games Explorer).

Чтобы скачать пакет SDK для Windows 8, см. статью "Загрузки" для разработки классических приложений.

Регистрация с помощью API обозревателя игр по-прежнему является механизмом регистрации игры с помощью элементов управления родительскими элементами Windows

Рекомендуется запустить версию пакета SDK для Windows GDFMAKER в выпущенной версии Windows 8, чтобы убедиться, что она может заполнять все поддерживаемые системы оценки.

Примечание.

Для этой версии GDFMAKER требуется .NET 4.0.

См. раздел 1.2 поддержки семейной безопасности / родительских элементов управления.

Теперь существует три варианта использования API XINPUT в зависимости от ваших требований.

XINPUT 1.4 встроен в Windows 8. Приложения Магазина Windows и классические приложения Win32 могут использовать XINPUT 1.4. Все версии Windows могут использовать XINPUT 9.1.0 для упрощенных общих контроллеров, но нет пакета распространения с XINPUT 9.1.0. Все версии Windows также могут использовать существующую версию пакета SDK DirectX XINPUT 1.3, которая требует развертывания DirectSetup.

См. раздел 1.4. Поддержка общего контроллера Xbox 360 для Windows.

В Windows RT поддерживаются только ограниченный набор классических приложений Win32

Игры, которые работают в Windows 7, могут работать правильно на платформах Windows 8 x86 и x64.

См. статью 2.2 Поддержка версий Windows x64.

Убедитесь, что все проверки ОС выполнены правильно

Версия ОС Windows 8 — 6.2. Windows 8 передает текущие тесты минимальной полосы, которые мы рекомендуем для развертывания игр.

Пакет распространения конечных пользователей DirectX успешно работает в Windows 8, так как это делает в Windows 7, для развертывания D3DX9, D3DX10, D3DX11, XINPUT 1.3, XAUDIO 2.7, XACTEngine и т. д.

Но известная проблема существует с DirectSetup в системах только с установленным .NET 4.0 из-за обработки развертывания устаревших сборок Managed DirectX 1.1. Эта проблема относится как к Windows 8, которая поставляется с .NET 4.5 по умолчанию, так и к новым компьютерам Windows XP с установленной средой выполнения .NET 4.0. Но эта проблема не применяется к любой версии .NET до .NET 4.0. Хотя Windows 8 имеет поведение совместимости приложений для автоматического устранения этой проблемы (для которого требуется сетевой доступ), рекомендуется, чтобы игры, которые продолжают развертывать обновление DirectSetup в пакете SDK DirectX (июнь 2010 г.) обновленных версий файлов REDIST. Как всегда, если вы используете DirectSetup для заголовка, обрезите название до минимального требуемого набора ЦС.

См. статью 3.4. Правильное установка ресурсов Windows.

Игры, требующие совместимой среды выполнения .NET 2.0 (2.0, 3.0, 3.5) продолжают использовать существующие механизмы развертывания.

Эти игры активируют поведение совместимости приложений в Windows 8, чтобы включить среду выполнения .NET 3.5 автоматически (для этого требуется сетевой доступ). Но мы рекомендуем разработчикам .NET перейти в среду выполнения .NET 4.0.

Примечание.

Устаревшие сборки Managed 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

Пакет SDK для Windows 8 включает этот обновленный средство проверки приложений.

См. раздел 4.2. Устранение сбоев проверяющего приложения.

Дополнительная информация

Книга по совместимости Windows 8 и Windows Server 2012
Где находится пакет SDK для DirectX?

Игры для Windows

Сводка требований к играм

Преимущества клиентов

Компьютерные игры являются ключевым опытом развлечений в Windows, но проблемы с удобством использования вызвали разочарование клиентов на протяжении многих лет. Традиционно игры устанавливаются как приложения, но они используются больше как развлекательные средства массовой информации (фильмы или песни, например). Инновации, такие как Games Explorer, предоставляют игры согласованно, отличающиеся от стандартных приложений. Эти инновации также дают играм статус гражданина первого класса в Windows, вместе с музыкой и фотографиями. Следующие требования помогают обеспечить улучшенный, более доступный и унифицированный игровой интерфейс Windows Vista и Windows 7. В то же время они обеспечивают совместимость с Windows XP.

Интеграция 1.1 Games Explorer

Требование

Игра должна быть видна в обозревателе игр ( папка "Игры ") в Windows Vista и Windows 7. При выборе игра также должна отображать правильные метаданные, включая издателя, разработчика, дату выпуска, версию, оценки windows Experience Index, рейтинг (если применимо), а также связанные гиперссылки.

Если игра распространяется через онлайн-службу игр, поставщик услуг также должен появиться в Game Explorer. Чтобы обеспечить правильную обработку поставщика и включить использование RSS-каналов, следует использовать схему 2 схемы для файлов определения игр (GDFs). (Дополнительные сведения о GDFS см. в разделе "Дополнительные сведения".)

Кроме того, установщики игр должны соблюдать следующие правила при запуске в Windows Vista и Windows 7:

  • Установка не должна создавать ярлык для запуска игры на рабочем столе, в меню или в любом другом расположении.
  • Задачи и сочетания клавиш для удаления не должны быть созданы.
  • Пользователи должны иметь возможность удалить игру с помощью программ и компонентов в панель управления в Windows Vista и Windows 7 или добавить или удалить программы в панель управления в Windows XP.

В Windows XP и в предыдущих версиях Windows установщик игр может создавать группы программ, значки рабочего стола или ярлыки по мере необходимости.

Логическое обоснование

Обозреватель игр Windows аналогичен концепцией папок Windows XP "Мои документы " или "Мои рисунки". Идея заключается в том, чтобы централизировать аналогичное содержимое в одном месте и упростить организацию и контекстно-конфиденциальные действия. Обозреватель игр расширяет концепцию "Мои документы " или "Мои фотографии ", позволяя более богатой организации и контролировать игры. Game Explorer позволяет игрокам просматривать, упорядочивать и взаимодействовать со всеми играми, установленными в своих системах. Она также позволяет издателям игр более эффективно обмениваться важной информацией о игре. Система управляется данными, что упрощает обновление сведений о игре в течение всей жизни продукта.

Дополнительная информация

Для интеграции с Game Explorer требуется создать файл определения игры (GDF), который является XML-текстовым файлом, внедренным в двоичный файл (исполняемый файл или dll) в качестве ресурса, а также значком Windows. Затем игра должна быть зарегистрирована в Game Explorer. GDF также позволяет отображать предоставленные сведения, такие как название игры, издатель, разработчик, ссылки на веб-сайты и необязательные задачи. Обратите внимание, что задачи поддержки могут быть только ссылками на веб-сайты, но также можно использовать для дополнительных задач поддержки.

Обозреватель игр может использовать изображение растрового изображения эскиза, но рекомендуется предоставить ресурс значка Windows с большими значками (256 256). Ресурс значка должен содержать размеры изображений 256 256 48 48, 32 32 и 16 16 в 24-разрядном (истинном цвете) и 8-разрядной (256) глубине цвета. Редактор значков, предоставляемый в Visual Studio 2008 и 2010, поддерживает эти форматы больших значков, как и IconWorkshop Lite.

Сведения об интеграции с Обозревателем игр Windows приведены в пакете SDK DirectX. Пакет SDK DirectX включает редактор определения игры (GDF), а также пример GDF, включенный в GDFExampleBinary, пример. Другой пример GameUxInstallHelper предоставляет подпрограммы для интеграции необходимых функций в существующие системы установки. Проверяющий файл определения игры (gdftrace.exe) предоставляет поддержку отладки для оценки GDF. См. также статью "Интеграция Обозревателя игр Windows" в документации по пакету SDK DirectX для C++.

Windows 7 предоставляет поддержку второй версии схемы для файлов GDF. Новая версия включает упрощенный метод для создания задач воспроизведения и поддержки уведомлений об обновлениях, поставщиков услуг игр, статистики игр и RSS-каналов для поставщиков услуг игр. Последняя версия GameUxInstallHelper обрабатывает всю поддержку регистрации и устаревшей версии, необходимую для использования файла GDF версии 2 с Windows Vista. Используйте средства и пример кода из пакета SDK DirectX с августа 2009 г. или более поздней версии. Использование GDF-файла версии 2 рекомендуется включить поддержку RSS-каналов, статистики игр и уведомлений об обновлении. Кроме того, см. примеры ProviderGDFExampleBinary и GameStatisticsExample.

В Windows Vista Business Edition Windows 7 Профессиональная Edition и выпуск Enterprise Windows Vista и Windows 7 ссылка на игры на меню скрыта. Обозреватель игр по-прежнему доступен на меню , щелкнув "Все программы", а затем щелкнув "Игры".

Для связанных приложений, установленных с вашей игрой, но не сами игры, вы можете создавать меню группы программ, ярлыки и значки на рабочем столе во всех версиях Windows, включая Windows Vista и Windows 7. Такие связанные приложения должны передавать применимые игры для требований Windows; Дополнительные сведения см. в руководстве по по промежуточному поверх игр. Игровые службы рекомендуется зарегистрировать в Game Explorer в качестве поставщика игр для Windows 7. 1

1.2 Поддержка семейной безопасности / родительских средств контроля

Требование

Игры должны полностью поддерживать Безопасность семьи Windows, следуя следующим правилам:

  • Игры не должны требовать, чтобы у пользователя были административные учетные данные для игры. Установка, исправление и удаление могут потребовать административных учетных данных в соответствии с требованиями в разделе 3. (Это требование 2.1. Следуйте рекомендациям по управлению учетными записями пользователей.)
  • Игры, оцененные советами рейтингов, поддерживаемыми Windows, например ESRB и PEGI, должны содержать сведения о назначенных оценках в файле определения игры (GDF). Все доступные данные оценок должны быть включены в каждую локализованную версию GDF, а также в версию, нейтральную на языке.
  • Игры должны перечислять свои исполняемые файлы в GDF, чтобы обеспечить хороший пользовательский интерфейс для общих ограничений приложений, если игра не использует технологию защиты от пиратства, которая создает случайным образом именованные исполняемые файлы во время выполнения.
  • Игры должны вызывать метод VerifyAccess интерфейса Обозревателя игр во время запуска, если он доступен, и выйти, если он возвращает *pfHasAccess как FALSE.

Логическое обоснование

Все игры должны выполняться в контексте учетной записи стандартного пользователя, чтобы разрешить учетные записи, контролируемые родительскими элементами управления Windows, играть в игру. Родители хотят, чтобы способность отслеживать и контролировать доступ своих детей к играм. Кроме того, многочисленные отраслевые, государственные и пропагандистские группы хотят лучше, чтобы родители могли отслеживать и контролировать игры, к которым подвергаются их дети. В сочетании с архитектурой, предлагаемой Games Explorer, корпорация Майкрософт предоставляет родителям эту возможность с помощью элементов управления родительскими элементами Windows.

Даже для игр, которые не участвуют в программе рейтингов, требуя повышенных привилегий, создает плохой игровой интерфейс для большинства учетных записей пользователей. Это особенно касается включения родительских элементов управления, для которых родитель должен ввести пароль администратора при каждом запуске игры.

Система управления родительскими элементами Windows позволяет родителям выбирать рейтинги, которые они считают подходящими для своих детей. Родительские средства контроля поддерживают многие из мировых систем рейтингов. Родительский контроль также позволяет родителям ограничить доступ к играм на основе дескрипторов содержимого (если соответствующая система рейтингов поддерживает их) и разрешить или запретить доступ к отдельным играм.

Выбор системы оценки по умолчанию для родительских элементов управления Windows основан на настройке языкового стандарта системы, но может быть изменен пользователем в региональных и языковых параметрах в панель управления. Таким образом, каждый поддерживаемый язык должен предоставлять все доступные данные о рейтингах, чтобы пользователь был свободен выбрать любой совет рейтингов, который они хотят.

Дополнительная информация

Игры без рейтинга по-прежнему должны соответствовать требованиям для поддержки игры в качестве стандартного пользователя и вызова VerifyAccess. Такие игры по умолчанию относятся к категории "Не оцененные", отображают текст "No Rating Provided" in Games Explorer и применяются к параметру "Ограничения игры" в родительских элементах управления для неоцененных игр. Параметр ограничений по умолчанию — Allow.

Сведения о рейтинге в GDF будут игнорироваться, если содержащий двоичный файл не является должным образом подписанным Authenticode. См. требование 2.3.

Редактор файла определения игры в пакете SDK DirectX включает все поддерживаемые системы рейтингов и правильно реплицирует эти сведения ко всем локализованным версиям GDF, а также языковой нейтральной версии. Средство GDFTrace декодирует и проверяет все сведения о рейтингах. Используйте версию август 2009 г. или более позднюю версию этих средств.

GDF для поставщика игр обычно не содержит сведений о рейтинге, и он зависит от параметров для неоценимого содержимого.

Операционная система Поддерживаемые системы оценки
Windows Vista
  • CERO (Япония)
  • ESRB (США)
  • OFLC (Австралия)
  • PEGI (Европа)
  • PEGI Финляндия (не рекомендуется)
  • PEGI Португалия
  • PEGI/BBFC (Соединенное Королевство)
  • USK (Германия)
Windows Vista с пакетом обновления Пакеты обновления для Windows Vista добавляют поддержку следующих компонентов:
  • GRB (Южная Корея)
  • Дескрипторы содержимого ESRB "Mild"
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 с пакетом обновления 1 (SP1), будут отображаться как неоцененные в Windows Vista без пакета обновления.

Новые данные о рейтингах игнорируются в версиях операционных систем без поддержки. В настоящее время вариант PEGI (Финляндия) устарел в пользу стандартной системы рейтингов PEGI (Европа). Система OFLC в настоящее время устарела в пользу COB-AU для Австралии.

Дополнительные сведения о том, как сделать игру совместимой со стандартными привилегиями пользователей, см. в статье DirectX "Управление учетными записями пользователей для разработчиков игр".

Дополнительные сведения о файле определения игры (GDF) см. в описании требования 1.1.

1.3 Поддержка расширенных сохраненных игр

[Это требование прекращено]

1.4 Поддерживает общий контроллер Xbox 360 для Windows [условное требование]

Требование

Игры, поддерживающие контроллеры геймпадов, должны поддерживать контроллер Xbox 360 для Windows с помощью API XInput . Если также поддерживаются периферийные устройства DirectInput, можно также использовать DirectInput. Однако XInput должен быть API по умолчанию, если используется устройство, совместимое с Xbox 360.

Все ссылки на общие триггеры контроллера и кнопки должны использовать имена Xbox 360. Дополнительные сведения см. в списке распространенных контроллеров Xbox 360 для терминологии Windows.

Вибрация контроллера должна быть отключена, когда игра находится в приостановленном или приостановленном состоянии.

Управление мышью и клавиатурой не может быть полностью отключено в любое время. Как минимум, должен быть доступен вариант возврата в игровые меню.

Логическое обоснование

Это требование дает игрокам свободу выбора, чтобы использовать контроллер Xbox 360 или клавиатуру и мышь, в зависимости от того, какой метод ввода более естественный и интуитивно понятный интерфейс.

Дополнительная информация

Это требование не применяется к играм, которые используют только мышь и /или клавиатуру.

Мы рекомендуем реализовать навигацию по меню, чтобы использовать широко принятые стандартные кнопки контроллера:

  • A — принять
  • B - Отмена
  • Пуск — принятие или приостановка
  • Назад — отмена, назад один экран или вверх по уровню меню

Дополнительные сведения см. в разделе XInput.

В разделе XInput и DirectInput рассматриваются проблемы с использованием обоих API одновременно.

Рекомендуется не использовать DirectInput для реализации элементов управления клавиатурой или мышью. Элементы управления клавиатурой и мышью должны быть реализованы только с помощью сообщений Windows и API Win32. Дополнительные сведения о получении сведений о движении мыши с высоким разрешением без использования DirectInput см. в разделе "Преимущества перемещения мыши с высоким определением".

1.5 поддерживает несколько пропорций и разрешений

Требование

Игра должна поддерживать по крайней мере следующие пропорции и связанные разрешения экрана:

  • 4:3 нормально (800 600 или 1024 768)
  • 16:9 широкий экран (1280 720)
  • 16:10 широкий экран (1152 720 или 1680 1050 или 800 480)

Для настройки разрешения экрана и обнаружения игра должна соответствовать следующим правилам:

  • Игра использует разрешение на рабочем столе устройства дисплея по умолчанию, если это поддерживаемое разрешение. Пропорции рабочего стола должны использоваться в качестве критерия поиска, если игра выбирает другое разрешение по умолчанию.
  • Игра должна предложить пользователю подтвердить новые параметры отображения при изменении. Если пользователь не принимает в течение 15 секунд, дисплей должен вернуться к предыдущему параметру.
  • Игра не должна растянуть пиксели или центр окна отрисовки 4:3 для поддержки пропорций широкоэкранного экрана. Тем не менее, почтовые ящики приемлемы.

Логическое обоснование

При использовании рабочего стола Windows 3D нельзя предположить определенное соотношение аспектов или разрешение из-за следующих факторов:

  • Поддержка отображения высокой детализации.
  • Увеличение доли рынка широкоэкранных мониторов.
  • Развертывания HDTV для Windows Media Center.
  • Требования к специальным возможностям.

Дополнительная информация

В идеале игра по умолчанию используется в собственном пропорции дисплея. Однако получение этой информации надежно может быть проблемой, так как более общее решение игры может предположить, что рабочий стол работает в собственном пропорции. Разрешение рабочего стола можно получить путем вызова EnumDisplaySettings с ENUM_REGISTRY_SETTINGS.

Дополнительные сведения см. в разделах "Пропорции" и "Широкий экран" статьи DirectX " Общие сведения о 10-футовом интерфейсе для разработчиков игр Windows.

Запуск поддержки 1.6 из Windows Media Center

[Это требование было прекращено.]

Поддержка Direct3D 1.7

Требование

Если в игре используется Direct3D, минимальная версия должна быть Direct3D 9, а Direct3D должна быть выбранной отрисовщиком по умолчанию.

Логическое обоснование

Архитектура графики Windows Vista и Windows 7 предназначена для Direct3D. Direct3D 8 и более ранние версии поддерживаются путем повторного сопоставления устаревших интерфейсов.

Использование версий Direct3D более поздних версий, чем Direct3D 9, настоятельно рекомендуется. См. игры для Windows Showcase S.1. Требование Direct3D 10 или Direct3D 11 полностью соответствует требованиям 1.7.

1.8 Включение высокого уровня DPI

Требование

Игры и их установщики должны работать правильно без визуальных проблем при включении масштабирования точек на дюйм (DPI) (протестировано с 144 DPI для 150 % масштабирования при разрешении отображения 1600 1200) в Windows Vista и Windows 7.

Обычно для этого требуется, чтобы исполняемый файл игры объявлял DPI-поддержкой. Это достигается путем внедрения элемента манифеста: <dpiAware>true<dpiAware> .

Логическое обоснование

Высококачественные мониторы LCD являются распространенными в качестве отображения компьютера, и они лучше всего выглядят при их собственных разрешениях (как правило, 1280 1024, 1600 1200 и т. д.). Клиенты, которые испытывают трудности с чтением текста и просмотр изображений в этом разрешении, часто устанавливают компьютерные компьютеры на более низкое разрешение и страдают визуальными артефактами от масштабирования LCD. Вместо этого клиенты могут оставить разрешение в собственном размере и изменить DPI дисплея Windows, что делает элемент и текст более большим, не жертвуя качеством изображения.

Хотя эта функция доступна в некоторой форме с Windows XP, она редко включается клиентами или изготовителами оборудования. Более половины всех компьютеров, отображаемых сегодня, имеют более низкое разрешение, чем собственное разрешение монитора на основе отзывов клиентов. Windows 7 делает эту функцию гораздо более видимой для клиентов во время начальной настройки и при изменении параметров отображения, поощряя их использовать масштабирование DPI, а не изменять разрешение рабочего стола.

Дополнительная информация

Вместо этого можно использовать функцию SetProcessDPIAware , если он вызывается в начале кода запуска процесса. Добавление в манифест предпочтительнее, чтобы гарантировать отсутствие условий гонки с программными элементами (например, библиотеки DLL), которые могут инициализироваться до вызова основной точки входа. Обратите внимание, что SetProcessDPIAware присутствует только в Windows Vista и Windows 7.

Добавление элемента манифеста легко сделать с Помощью 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. Чтобы устранить эту проблему, обновите Mt.exe до последней версии из пакета SDK для Windows.

Visual Studio 2010 включает параметр в свойствах проекта с именем Enable DPI Awareness, который устраняет необходимость в файле, например dpiaware.manifest. Найдите функцию "Включить осведомленность о DPI", расширив свойства конфигурации и инструмент манифеста, а затем выбрав входные и выходные данные.

В Windows традиционный режим отображения по умолчанию используется в 96 DPI, что было распространено для мониторов CRT.

Хотя полноэкранные приложения изменяют разрешение дисплея, они часто используют сообщения окна и метрики при настройке буферов и отображения прямоугольников. Виртуализация DPI приводит к тому, что эти полноэкранные режимы отображения будут обрезаны, и объявление о том, что поддержка DPI предотвратит эти проблемы. Дополнительные сведения см. в статье "Написание приложений Win32 с поддержкой DPI".

Безопасность и совместимость

Сводка требований к безопасности и совместимости

Преимущества клиентов

Следующие требования повышают общую безопасность игр и помогают обеспечить работу с 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. Чтобы устранить эту проблему, обновите Mt.exe до последней версии из пакета SDK для Windows.

Дополнительные сведения об установке, исправлении и удалении см. в требованиях 3.1.

Библиотеки динамических ссылок (DLL) не требуют таких манифестов.

Дополнительные сведения об управлении учетными записями пользователей см. в разделе "Управление учетными записями пользователей" для разработчиков игр.

2.2 Поддержка версий Windows x64

Требование

Для обеспечения совместимости с 64-разрядными выпусками Windows игры должны соответствовать следующим требованиям.

  • Заголовки и установщики заголовков не должны содержать 16-разрядный код или полагаться на любой 16-разрядный компонент.
  • Если игра зависит от драйверов в режиме ядра для операций, должны быть доступны версии x64 этих драйверов. Программа установки игры должна обнаруживать и устанавливать соответствующие драйверы и компоненты для 64-разрядных выпусков Windows.

Логическое обоснование

Многие пользователи Windows Vista и Windows 7 будут запускать 64-разрядные выпуски операционной системы в течение всего времени существования продукта, поэтому важно, чтобы приложения были совместимы с этой операционной системой.

Дополнительная информация

Windows в Windows 64 (WOW64) позволяет 32-разрядному коду работать в 64-разрядных выпусках Windows, поэтому не обязательно, чтобы приложение было собственным 64-разрядным кодом в 64-разрядных выпусках Windows. Шестнадцатилетний код не выполняется в 64-разрядных выпусках Windows.

Поддержка совместимости с Windows XP Professional x64 Edition не требуется, но настоятельно рекомендуется.

Дополнительные сведения см . в 64-разрядном программировании для разработчиков игр.

Файлы подписи 2.3

Требование

Все исполняемые файлы кода (как правило, файлы с расширением .exe или .dll) должны быть подписаны с общедоступным действительным сертификатом Authenticode и должны иметь допустимый URL-адрес сервера метки времени для подписи рабочей среды.

Если в игре используется установщик Windows, необходимо подписать файлы пакета установщика (.msi файлы).

Логическое обоснование

Подписывание файла помогает пользователям решить, следует ли доверять приложению, и гарантирует пользователям, что файлы не были изменены. Он также позволяет приложениям правильно работать в заблокированных средах.

Дополнительная информация

Дополнительные сведения см. в разделе "Подписывание Authenticode для разработчиков игр".

Если в игре используется установщик Windows, рекомендуется включить исправление UAC/LUA, включив таблицу MsiPatchCertificate. Дополнительные сведения см. в разделе "Управление учетными записями пользователей" (UAC).

Мы не рекомендуем подписывать файлы (.cab), если они не являются относительно небольшими (менее 100 МБ).

2.4 Драйверы подписей

Требование

Любой драйвер в режиме ядра, установленный игрой, должен быть подписан с общедоступным действительным сертификатом Authenticode.

Любой драйвер аппаратного устройства в режиме ядра, установленный игрой, должен иметь подпись Майкрософт, которая может быть получена из программы "Лаборатории качества оборудования Windows" (WHQL) или из программы сигнатуры надежности драйвера (DRS).

Логическое обоснование

Плохо написанные или вредоносные драйверы могут сильно повлиять на стабильность и безопасность системы. В 64-разрядных выпусках Windows Vista и Windows 7 не загружаются неподписанные драйверы. Эта политика также может быть включена для 32-разрядных выпусков Windows Vista и Windows 7.

Дополнительная информация

Требуются 32-разрядные и 64-разрядные версии всех драйверов в режиме ядра для каждого требования 2.2.

Дополнительные сведения о программах подписывания драйверов Майкрософт см. в Центр разработки оборудования Windows.

2.5. Проверка правильной версии

Требование

Игры не должны выполняться в будущих операционных системах, как указано изменениями в номере версии Windows, если лицензионное соглашение не запрещает использование в будущих операционных системах. Если игра должна завершиться ошибкой, она должна сделать это правильно, отображая соответствующее сообщение пользователю.

Если проверка версий Windows выполняется, для проверки версии необходимо использовать API проверки версий (GetVersionEx или VerifyVersionInfo). Разделы реестра не должны быть прочитаны, чтобы определить версию.

Явные проверки версий для среды выполнения DirectX не должны присутствовать в игре. Эти проверки версий не должны присутствовать в установке, которая запускает программу установки среды выполнения DirectX (DirectSetup).

Логическое обоснование

Когда пользователи Windows обновляют свои операционные системы, они не должны быть заблокированы для воспроизведения текущих игр, так как номер версии Windows увеличился. Плохо написанные средства проверки версий продолжают создавать проблемы для программного обеспечения, которое, в противном случае, работает хорошо над более новыми версиями Windows или просто с добавлением пакета обновления Windows.

Логика сравнения хрупких версий для среды выполнения DirectX создала множество неудачных установок при запуске в разных версиях Windows. Номер версии DirectX применяется только к основным компонентам операционной системы. Он не применяется к компонентам пакета SDK DirectX, которые используются многими играми.

Дополнительная информация

Обычно установщики проверяют минимальную версию ОС. Однако эта проверка должна быть выполнена с осторожностью, чтобы убедиться, что она проверяет наличие большего или равного, а не простого равенства, тем самым блокируя определенную версию операционной системы. С помощью теста HighVersionLie средства проверки приложений можно быстро и легко определить, как установщик будет реагировать на значительное изменение номера версии ОС.

Правильное использование пакета распространения среды выполнения DirectX (программа установки DirectX) включает всегда запускать его во время установки, предпочтительно в автоматическом режиме. Это позволяет корпорации Майкрософт выполнять все необходимые обновления версий. Он также позволяет устанавливать любые необязательные компоненты пакета SDK DirectX, такие как D3DX, XACT, многомерные выражения или XInput.

Рекомендации по развертыванию среды выполнения DirectX см. в разделе "Установка DirectX для разработчиков игр".

Рекомендуется, чтобы игры, поддерживающие windows XP, проверяли уровень пакета обновления 2 или выше, так как пакет обновления 2 (SP2) и пакет обновления 3 (SP3) обеспечивают значительные улучшения безопасности, упрощенное требование к распространению среды выполнения DirectX и чрезвычайно широкое развертывание. Большинство современных технологий Майкрософт, поддерживающих Windows XP, требуют sp2 или SP3 (XAudio2, Игры для Windows — LIVE и т. д.).

2.6 Поддерживает одновременные сеансы пользователей

Требование

Игры, использующие трехмерную графику, не требуются для работы через подключение к удаленному рабочему столу, но пользователь должен быть оповещен, когда игра завершается ошибкой.

Игры должны поддерживать стандартные сценарии многозадачности Windows, следуя следующим правилам:

  • Игры не должны блокировать использование одновременных сеансов пользователей.
  • Игра должна выполняться в новом сеансе пользователя, когда она уже запущена в другом сеансе.
  • Звук игры в одном сеансе пользователя не должен быть услышан, когда другой пользователь активен в другом сеансе.
  • Игры должны поддерживать быстрое переключение пользователей.
  • Игры не должны пытаться отключить стандартное переключение задач. Игры не должны отключать сочетание клавиш ALT+TAB. Игры могут отключить сочетания клавиш специальных возможностей, как описано в разделе "Отключение сочетаний клавиш в играх".

Логическое обоснование

Пользователи Windows должны выполнять одновременные сеансы без конфликтов или нарушений. Это распространенный сценарий для компьютера Windows, совместно используемого семьей, товарищами по комнате или другими пользователями.

Дополнительная информация

Чтобы проверить, запущена ли игра в удаленном сеансе, вызовите GetSystemMetrics(SM_REMOTESESSION). Значение, отличное от нуля, указывает, что сеанс удален.

Дополнительные сведения см. в разделе "Быстрое переключение пользователей". Обратите внимание, что быстрое переключение пользователей происходит, если ограничения времени родительского контроля включены, когда время пользователя истекает. Дополнительные сведения см. в описании требования 1.2.

2.7 поддерживает длинные имена

Требование

Если игра поддерживает сохранение файлов, она должна иметь возможность сохранять файлы с длинными именами и путями. Игра должна правильно обрабатывать специальные символы файловой системы, такие как \ / : * ? " <>в любых полях ввода пользователя, которые используются для создания имен файлов или путей.

Игры должны работать правильно, если у пользователя есть длинное имя пользователя.

Логическое обоснование

Игроки привыкли использовать длинные имена на глубоких путях, поддерживаемых базовой операционной системой.

Дополнительная информация

Длинные имена определяются как те, которые содержат максимальные значения, определенные в пакете SDK для Windows.

Установка

Сводка требований к безопасности и совместимости

Преимущества клиентов

Клиенты могут быть уверены, что приложения будут устанавливаться в Windows, не ухудшая операционную систему или другие приложения, если приложения используют официальные методы распространения компонентов системы. Упрощенная установка обеспечивает более удобный и бесплатный интерфейс для игр.

3.1 Поддержка простой установки

Требование

Игры должны предоставлять упрощенный путь в пользовательском интерфейсе установки, реализуя следующее:

  • Отображение не более одного запроса EULA.
  • Путь установки по умолчанию должен обойти все выбранные варианты установки (например, папки установки или выбор компонентов), предположить выбор по умолчанию, а затем запустить игру или средство запуска при успешной установке без дополнительных запросов. При необходимости можно указать настраиваемый параметр установки для дополнительных параметров конфигурации.
  • Установите все необходимые компоненты операционной системы (например, среды выполнения DirectX и Visual C) с помощью правильных пакетов распространения Майкрософт. Установка должна выполняться автоматически без запроса и без проверки версий компонентов.
  • Предоставление удаления через программы и компоненты в панель управления для игрового приложения и созданных рабочих файлов. Рекомендуется удалить все файлы данных, созданные пользователем. Процесс удаления должен обеспечить удаление всех установленных файлов и очистку всех параметров (например, записей списка исключений брандмауэра и разделов реестра). Распространяемые компоненты операционной системы не должны быть удалены.
  • Если игра требует добавления исключений в брандмауэр Windows, процесс установки может предложить пользователям сообщить о необходимости этого изменения. Этот запрос должен появиться перед началом установки.

Установка и удаление могут требовать права администратора. Исправление может потребовать запроса на получение учетных данных администратора в зависимости от частоты обновления. Обычная игра в игре не должна требовать прав администратора, в соответствии с требованием 2.1 следуйте рекомендациям по управлению учетными записями пользователей.

Логическое обоснование

Простая установка — это философия разработки игр, ориентированной на Windows, которая предназначена для упрощения и упрощения иногда мученного и запутанного процесса установки игр на компьютерах под управлением операционных систем Windows. Простая установка включается с помощью набора технологий и рекомендаций, которые снижают ненужную сложность и предполагаемый риск установки игр на компьютерах Windows.

Ключевыми целями являются следующие задачи.

  • Уменьшите время, чтобы попасть в игру и начать играть.
  • Уменьшите количество диалоговых окон и вариантов до очень мало или нет, чтобы упростить установку игры.

Некоторые традиционные установки имеют запросы, разрешающие нефункциональную установку, даже если приложение, как представляется, успешно установлено. Например, игра может требовать от пользователя принять EULA. Затем будет установлена игра, а затем появится EULA DirectX. Этот EULA позволяет пользователям отклоняться и таким образом пропускать установку среды выполнения DirectX. Этот сценарий может привести к тому, что игра не выполняется из-за отсутствующих компонентов.

Дополнительная информация

Дополнительные сведения об установке игр, не традиционных способах установки игр, решениях исправления, совместимых с UAC, и об обработке частых исправлений см. в следующих статьях DirectX:

Примечание.

Удаление созданных пользователем файлов данных должно выполняться только для текущего пользователя и для общих расположений пользователей. Нет надежного способа сканирования системы, чтобы удалить файлы, относящиеся к пользователю, для других пользователей, даже если удаление требует административных учетных данных.

3.2 Поддержка управления учетными записями пользователей для установки

Требование

Установщик игры не должен предполагать, что он работает в том же контексте, что и пользователь. Расположения, относящиеся к пользователю, будут отличаться от установщика и проигрывателя даже для однопользовательских систем из-за повышения прав администратора. Поэтому при первом запуске игры она должна выполнять определенные пользователем задачи отдельно от процесса установки.

Диалоговое окно исключения брандмауэра Windows не должно отображаться, когда пользователь размещает или присоединяется к многопользовательской игре. Любая требуемая конфигурация должна выполняться во время установки. Инструкции по настройке должны сообщить пользователю, что эта операция будет выполняться в процессе установки.

Установщик игры должен предоставить внедренный манифест, указывающий необходимый уровень выполнения, в соответствии с требованием 2.1 Следуйте рекомендациям по управлению учетными записями пользователей.

Если игра запускается установщиком после завершения установки, она должна быть запущена в контексте исходного пользователя.

Логическое обоснование

Одним из крупнейших изменений в операционной системе Windows в Windows Vista является добавление контроля учетных записей пользователей (UAC), которое запускает приложения с ограниченными привилегиями по умолчанию. В результате установщики должны соответствующим образом управлять уровнями привилегий. Windows 7 также широко использует UAC. Хотя Windows 7 улучшает пользовательский интерфейс UAC, установщики по-прежнему должны соответствовать тем же требованиям, что и в Windows Vista для правильной работы, не полагаясь на потенциально запутанное поведение виртуализации.

UAC активна по умолчанию в Windows Vista и Windows 7, и подавляющее большинство клиентов (88% или более на основе отзывов) оставьте эту функцию включенной.

Дополнительная информация

Дополнительные сведения о настройке брандмауэра Windows см. в статье Брандмауэр Windows для разработчиков игр и пример брандмауэра FirewallInstallHelper.

Стандартный запуск игры в конце процесса установки не соответствует последнему аспекту этого требования, если установка запускается стандартным пользователем, и если процесс установки требует прав администратора (то есть запрашивает учетные данные администратора). Он также наследует права администратора, что является потенциальным риском безопасности. Вместо этого загрузчик установки должен запустить игру после успешного вызова установщика. Дополнительные сведения см. в статье msdn Magazine Learn Your Apps to Playly with Windows Vista User Account Control.

3.3. Установка в правильные папки

Требование

Игры, установленные для всех пользователей, должны быть установлены в папку Program Files по умолчанию. Пользовательские данные должны быть записаны при первом запуске игры, а не во время установки.

Логическое обоснование

Пользователи должны иметь гибкость для установки приложений, где им нужны. Они также должны иметь согласованный и безопасный интерфейс с расположением файлов по умолчанию.

Дополнительная информация

Игры могут использовать различные известные расположения папок (например, указанные CSIDL_LOCAL_APPDATA и CSIDL_COMMON_APPDATA) для хранения значительных объемов игровых данных и вспомогательных исполняемых файлов для реализации расширенных сценариев установки по запросу и исправлений.

Так как при установке может потребоваться повышение прав на другую учетную запись пользователя во время установки всех пользователей, нет правильного расположения пользователя для хранения данных во время установки. Кроме того, если шифрование файлов включено, зашифрованные файлы можно получить только с помощью учетной записи пользователя, созданной им.

3.4 Правильно установите ресурсы Windows

Требование

Приложения не должны пытаться установить файлы или разделы реестра, защищенные Защитой ресурсов Windows (WRP). Если приложению требуются более новые версии системных компонентов, необходимо обновить эти компоненты с помощью пакета обновления Майкрософт или утвержденного корпорацией Майкрософт пакета установки, содержащего системный компонент. Системные компоненты никогда не должны быть перепаковыты.

Логическое обоснование

Защита ресурсов Windows (WRP) предназначена для обеспечения обновления защищенных системных ресурсов только с помощью утвержденных корпорацией Майкрософт механизмов установки или обновления. WRP повышает надежность системы, гарантируя, что результаты установки прогнозируются.

Дополнительная информация

WRP является преемником защиты файлов Windows, который защищает большинство системных компонентов, установленных в папке Windows. WRP защищает большинство разделов реестра, которые хранят параметры для создания com-объектов. Он также резервирует определенные папки для использования исключительно операционной системой. Попытки доступа к защищенным ресурсам обычно приводят к ошибке отказа доступа.

Дополнительные сведения о рекомендациях по развертыванию среды выполнения DirectX с игрой см. в статье DirectX По установке DirectX для разработчиков игр.

3.5 Избегайте перезагрузки во время установки

Требование

Установщик игр не должен предполагать, что установка компонентов Windows из пакетов распространения требует перезагрузки, если перезагрузка не указана результатом возврата или документацией Майкрософт.

Если установщик игры всегда заставляет перезагрузку, это должно быть одобрено корпорацией Майкрософт.

Диалоговые окна использования файлов, включенные в пакеты установщика Windows, должны содержать параметр автоматического закрытия приложений и попытки перезапустить их после завершения установки.

Логическое обоснование

Перезагрузка системы после установки является неудобным нарушением для пользователей и обычно не требуется.

Дополнительная информация

Дополнительные сведения см. в разделе "Использование установщика Windows с диспетчером перезапуска".

3.6 Правильно использовать управление версиями файлов

Требование

Программа установки игр должна правильно проверить, что установлены последние версии файлов. Установка игры никогда не должна регрессии каких-либо файлов, которые не создаются или совместно используются приложениями, которые не создаются.

Логическое обоснование

Общие компоненты и системные компоненты часто обновляются для исправлений безопасности и расширенных функциональных возможностей. Установка, содержащая более раннюю версию обновленных компонентов, не должна привести к потере обновлений и исправлений, которые уже применены.

3.7 Поддержка автоматического запуска [условное требование]

Требование

Для игр, распределенных на компакт-диске, DVD-диске или других съемных носителях, поддерживающих автозапуск, когда диск вставляется в первый раз, приложение должно автоматически запускать или запрашивать у пользователя установку игры, если пользователь не отключил функцию автоматического запуска.

После успешной установки приложения повторно вставка диска на диске не должна привести к автоматической установке. Можно попросить пользователей обновить или изменить варианты установки.

Приложение автозапуска не должно запрашивать повышение прав (т. е. оно должно иметь asInvoker в манифесте для каждого требования 2.1, хотя оно может запустить программу установки или другую служебную программу, требующую прав администратора. Повышение прав должно происходить только в том случае, если игра не установлена или пользователь специально выбирает его.

Логическое обоснование

Автоматическое выполнение упрощает использование распределенных мультимедиа приложений, таких как игры, которые обычно требуют, чтобы диск присутствовал на диске, чтобы играть в игру.

Дополнительная информация

Не допускается, чтобы пользователь переходить в проводник для запуска установки с компакт-диска или DVD-диска.

Для игр, распределенных на нескольких дисках, последующие диски должны в идеале использовать функцию автоматического запуска или продолжить установку без запроса пользователя нажать клавишу или выполнить другое действие.

При создании программы автоматического запуска убедитесь, что все необходимые компоненты присутствуют в свежих установках Windows. Типичные приложения зависят от технологий, установленных программой установки, но автоматический запуск выполняется перед любой такой настройкой. Одним из распространенных примеров является сбой программ автоматического запуска, так как библиотеки DLL среды выполнения Visual C не были включены в программу установки Windows. Поэтому программа автоматического запуска должна использовать локальное развертывание CRT приложения или статически связать CRT.

Программы автоматического запуска, написанные для использования в версиях Windows до Windows Vista, не должны использовать среду выполнения .NET, так как эта технология не входит в состав Windows XP или более ранних версий Windows. Windows Server 2003 и Windows Vista — это первые версии Windows, которые включают среду выполнения .NET в состав своей операционной системы.

По аналогичным причинам программы автоматического запуска не могут требовать наличия дополнительных компонентов пакета SDK DirectX, таких как D3DX9, D3DX10, D3DX11, XAudio2, X3DAudio, XACT, XINPUT и МНОГОМЕРНЫЕ выражения 1.1.

Пример использования автозапуска см. в разделе "Пример автозапуска".

Надежность

Сводка требований к безопасности и совместимости

Преимущества клиентов

Эти требования делают приложение более надежным путем минимизации количества сбоев, зависания и перезагрузки. Требования к надежности могут помочь гарантировать, что программное обеспечение является более предсказуемым, обслуживаемым, устойчивым и восстанавливаемым.

4.1 Устранение ненужных перезагрузк

Требование

Все установщики приложений должны воспользоваться API диспетчера перезапуска, чтобы избежать перезагрузки системы (см. требование 3.5).

Игры не должны блокировать завершение работы.

Все приложения должны отвечать на диспетчер перезапуска, прослушивая и отвечая на следующие сообщения о завершении работы:

WM_QUERYENDSESSION с LPARAM = ENDSESSION_CLOSEAPP (0x1)

Приложения графического интерфейса должны немедленно реагировать (TRUE) при подготовке к перезапуску.

WM_ENDSESSION с LPARAM = ENDSESSION_CLOSEAPP (0x1)

Приложения должны возвращать значение 0 в течение 5 секунд, а затем закрыть.

CTRL+C

Консольные приложения, получающие это сообщение, должны немедленно закрыться.

Логическое обоснование

Перезагрузки системы являются серьезным нарушением. Они приводят к плохому интерфейсу пользователя и должны быть сведены к минимуму. Для некоторых операций, таких как критически важные обновления системы, могут потребоваться перезагрузки. Прослушивая сообщения о завершении работы, игра и другие приложения могут оперативно реагировать на запросы от диспетчера перезапуска. Таким образом, они могут избежать ненужных задержек в допустимых запросах перезагрузки.

Дополнительная информация

Если установщик игр использует технологию установщика Windows (MSI) без пользовательских действий, эта функция предоставляется автоматически. Пакеты распространения Майкрософт также поддерживают диспетчер перезапуска.

Дополнительные сведения о диспетчере перезапуска см. в разделе "О диспетчере перезапуска".

4.2 Устранение сбоев проверяющего приложения

Требование

Игра не должна создавать сбоев, выполняемых в Microsoft Application Verifier (AppVerifier), версии 4.0 или более поздней, в следующих тестах:

  • Основы: дескрипторы, кучи, блокировки, память, TLS
  • Прочие: DangerousAPIs, DirtyStacks

Логическое обоснование

Тесты AppVerifier для многих известных проблем, которые вызывают сбои и зависания в приложениях Windows, а также известные уязвимости системы безопасности.

Дополнительная информация

Дополнительные сведения о средстве проверки приложений см. в разделе "Проверка приложений" и "Использование средства проверки приложений" в рамках жизненного цикла разработки программного обеспечения.

Это требование не применяется к чистым управляемым приложениям без собственного взаимодействия.

Эти тесты должны выполняться в сборке выпуска. Отладка сборок может привести к ложным сбоям. Некоторые антипиратские и анти-обманные технологии могут препятствовать выполнению AppVerifier. Таким образом, эти тесты должны выполняться без поддержки антипиратских и анти-обманных технологий.

Возможно, потребуется задать для полного свойства теста Basics:Heaps значение 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) должны содержать точное имя продукта, имя компании и версию файла.
  • Обычный выход из игры не должен привести к ошибке неизвестного исключения.

Логическое обоснование

API-интерфейсы отчеты об ошибках Windows предоставляют важные отзывы корпорации Майкрософт для обнаружения распространенных сбоев и зависания в приложениях. Это позволяет корпорации Майкрософт и ее партнерам быстро обнаруживать и устранять проблемы системы и драйвера, которые приводят к сбоям приложений.

Дополнительная информация

Игры могут включать пользовательские необработанные обработчики исключений для выполнения пользовательских функций поддержки и отчетов, но они должны передавать любые ошибки в функции ReportFault или WerReportSubmit .

Правильные сведения о версии файла можно проверить, просмотрев свойства файла в классическом пользовательском интерфейсе Windows и проверив страницу свойств version.

Дополнительные сведения об API-интерфейсах отчеты об ошибках Windows и анализе аварийных дампов, создаваемых при использовании этой службы, см. в статье Аналитика аварийного дампа DirectX.

Общий контроллер Xbox 360 для терминологии Windows

Имя Описание
а Кнопка A.
Б Кнопка B.
НАЗАД Кнопка "Назад".
Бампер (справа или влево) Кнопка в правом верхнем и левом крае контроллера. Эквивалентно плечевой кнопке.
направление площадки Панель направления контроллера.
D-pad Принято сокращенное название боковой панели.
DP Сокращенная панель направления и метка контроллера.
RB, LB Сокращения правого и левого бампера и меток контроллера.
RS, LS Сокращения правой и левой палки и метки контроллера.
RT, LT Аббревиаций справа и слева триггеров и меток контроллера.
RSB, LSB Сокращения правой и левой палки и метки контроллера.
НАЧАЛО Кнопка "Пуск".
(справа/слева) палка Палка контроллера. Ранее палец.
(справа или влево) кнопка прилипания Кнопка "Придерживаться контроллера". Ранее кнопка с пальцем.
Триггер (справа или слева) Триггер контроллера.
Вибрация Отзывы о игровом процессе, созданные двигателем контроллера. Не используйте рухи.
X Кнопка X.
Y Кнопка Y.
Контроллер Xbox 360 для Windows Геймпад Xbox 360 продается как номер SKU оборудования компьютера, включая диск драйвера устройства Windows.
Беспроводной контроллер Xbox 360 для Windows Беспроводной игровой панель Xbox 360 продается как номер SKU оборудования компьютера, включая диск драйвера устройства Windows.

Рекомендации по по промежуточному поверх игр

Введение

Для игр, которые должны соответствовать программе Windows, они должны соответствовать списку технических требований. Любые сторонние компоненты, поставляемые с заголовком (исполняемые файлы, библиотеки DLL, драйверы и т. д.), также должны соответствовать этим требованиям, чтобы игра соответствовала требованиям. В этом документе описаны наиболее распространенные требования, которые также должны соответствовать сторонним компонентам для игры, чтобы пройти тесты соответствия. Установщики и полные игровые пакеты и рабочие пакеты должны просмотреть полный документ о технических требованиях Для Windows, так как многие из этих требований влияют на эти средства.

Дополнительные рекомендации

Помимо обеспечения того, чтобы ваш компонент поддерживал создание названий, соответствующих требованиям для игр для Windows, следует учитывать ряд других аспектов, которые следует учитывать при разработке и развертывании библиотеки или служебной программы поддержки для игры Windows.

  • Для поддержки разработчиков, работающих с 64-разрядными приложениями x64, предоставьте 32-разрядные и 64-разрядные версии собственных библиотек. 32-разрядная версия должна быть совместима с 64-разрядной версией на 2,2. Библиотеки для 32-разрядных приложений не должны предполагать, что высокий бит любого 32-разрядного адреса не используется для поддержки использования в приложениях x86 LARGEADDRESSAWARE.

  • Если вы предоставляете заголовки машинного кода (C/C++), используйте синтаксис атрибута "Стандартный язык заметок" (SAL), чтобы декорировать процедуры общедоступного API. Это позволит пользователям библиотеки получить максимальное преимущество использования статического анализа кода (/анализа), который является частью Visual Studio Team System 2005, Visual Studio Team System 2008, Visual Studio 2010 Premium и Visual Studio 2010 Ultimate, а также общедоступных средств компилятора Windows SDK.

  • Если ваш продукт создает потоки в процессе пользователя, обязательно присвойте каждому потоку имя, чтобы средства отладки могли правильно подтвердить выполнение потоков.

  • Если вы пишете подпрограммы, которые должны вызываться в основном цикле игры, используйте подпрограммы D3DX D3DPERF_BeginEvent/EndEvent и D3DPERF_SetMarker для упрощения идентификации узких мест с помощью PIX для Windows.

    Примечание.

    Для функций графических диагностика Visual Studio 2012 эти подпрограммы D3DX и PIX заменяются интерфейсом ID3DUserDefinedAnnotation.

  • Для сетевых библиотек предоставьте нейтральную IP-реализацию и избегайте устаревших процедур IPv4 только для поддержки технологий IPv6 и Teredo в Windows XP с пакетом обновления 2, Windows Vista и Windows 7.

  • Поставщики игровых услуг должны зарегистрировать себя в Game Explorer с помощью схемы GDF версии 2 и использовать функцию RSS для предоставления новостей, связанных с обслуживанием.

Игры для Демонстрации Windows

Введение

Игры для Windows демонстрации выходят за рамки обеспечения надежного игрового интерфейса на компьютерах с Windows. Реализуя эти функции, игры могут добавить больше удовольствия к пользовательскому интерфейсу на последних платформах Windows.

Игры для названий Windows должны соответствовать всем техническим требованиям, перечисленным в этой статье, но демонстрации функций являются необязательными. Эти названия свободны для реализации некоторых, ни одного из этих демонстраций.

S.1 Эксплойт Direct3D 11

Требование

Direct3D 11 — это API отрисовки следующего поколения для Windows Vista и Windows 7. Игры, использующие Direct3D 11, используют оптимизированное содержимое, расширенные методы отрисовки и новые аппаратные функции, чтобы создать привлекательный интерфейс на оборудовании, поддерживающем 10, 10.1 и 11.

Если игра также реализует Direct3D 9, параллельное сравнение должно продемонстрировать заметное улучшение качества контента, наглядности, производительности, сложности сцены и других областей графической точности для Direct3D 11. Эта поддержка распространяется на игры для Windows Technical Requirement 1.7.

Технологию Direct3D 10level9 можно использовать для поддержки шейдерной модели 2.0/3.0 Direct3D 9-класса видео аппаратного обеспечения в Windows Vista и Windows 7, а не параллельной реализации Direct3D 9 для широкой поддержки оборудования. Однако это недостаточно, чтобы продемонстрировать эту демонстрацию.

На компьютерах под управлением Windows Vista или Windows 7 с установленным Direct3D 11 игра должна по умолчанию использовать Direct3D 11.

Логическое обоснование

API Direct3D 11 основывается на инфраструктуре WDDM и Direct3D 10.1 для поддержки новых возможностей: аппаратного тесселяции, вычислительных шейдеров, многопоточных отрисовок и создания ресурсов, новых форматов сжатия текстур и более гибкого языка шейдеров. Direct3D 11 обеспечивает унифицированную поддержку оборудования для современных видеоадаптеров, включая последние части Direct3D 11, все видеокартки Direct3D 10 и 10.1, а также многие шейдер модели 2.0/3.0 Direct3D 9, что является минимальным оборудованием видео, необходимым для рабочего стола Aero 3D.

Дополнительная информация

Перенос обработчика отрисовки Direct3D 9 для использования нового интерфейса Direct3D 11 является четко определенной задачей:

  • Исключите все операции с фиксированными функциями в пользу программируемых шейдеров.
  • Обновите все существующие шейдеры до нового синтаксиса модели шейдера 4.x/5.
  • Обновите управление ресурсами для поддержки новой модели представления.
  • Преобразуйте все ресурсы для использования нового списка доступных форматов.
  • Обновите обработку состояния отрисовки, чтобы использовать неизменяемые блоки состояния и переработать константы шейдера в буферы констант.

Это преобразование важно для включения демонстрации Direct3D 11, хотя результат не соответствует демонстрации требования к использованию нового API.

Новый API и связанная модель программирования HLSL предлагает множество возможностей для расширенного содержимого:

  • Использование существующих аппаратных функций Direct3D 10, таких как геометрия шейдера, Stream Out, массивы текстур и форматы сжатых текстур BC4/BC5.
  • Использование существующих аппаратных функций Direct3D 10.1, таких как независимые режимы смешения для каждого отрисовки, чтение глубины MSAA, доступ msAA на выборку шейдеров, массивы карт куба и отрисовка в форматы блочного сжатия (BC).
  • Реализация расширенных алгоритмов GPU с помощью шейдера вычислений с CS4.x на существующих видеокартах Direct3D 10/10.1 (включено обновленными драйверами видео) или CS 5.0 на видеокартах direct3D 11 следующего поколения.
  • Отрисовка на нескольких потоках с помощью создания свободного потока ресурсов и нескольких контекстов устройств для повышения производительности в многоядерных системах (с обновленными драйверами видео). Дополнительные сведения см. в разделе "Игры для Windows Showcase S.3".
  • Использование новых функций видеоустройства Direct3D 11 класса, например аппаратного тесселяции с шейдерами корпусов и доменов, шейдер модели 5.0 HLSL аппаратных функций BC6HBC7 сжатых форматов текстур и динамической компоновки шейдеров.

Методы, которые можно реализовать с помощью Direct3D 9 (в значительной степени с высокой стоимостью ЦП), можно эффективно загружать на GPU, таким образом освобождая ресурсы ЦП для поддержки других требований игры.

API Direct3D 11, вспомогательные средства и примеры доступны в пакете SDK DirectX. Также см. API графики в Windows.

S.2 Эксплойт x64 Native

Требование

Игра включает в себя 64-разрядный исполняемый файл, который обеспечивает убедительный новый интерфейс, включенный выпусками x64 Windows, работающими на оборудовании с поддержкой x64. Параллельное сравнение с 32-разрядной версией игры должно показать заметное улучшение сложности содержимого, снижение общей нагрузки и производительность.

В 64-разрядных выпусках Windows установка должна всегда настраивать 64-разрядную версию игры в качестве сочетаний клавиш по умолчанию в Game Explorer и Windows XP Professional x64 Edition. Если требуется двойная установка, можно указать дополнительную задачу воспроизведения для обозревателя игр в Windows Vista и Windows 7, которая указывает на 32-разрядную версию, но по умолчанию должна оставаться 64-разрядная версия.

Обратите внимание, что игра должна поддерживать 64-разрядные выпуски Windows Vista и Windows 7, чтобы удовлетворить эту рекомендацию. Поддержка Windows XP Professional x64 Edition рекомендуется, но не требуется.

Логическое обоснование

Технология x64 предоставляет 64-разрядные возможности адресации для рынков потребителей и серверов, которые включают 32-разрядную 32-разрядную обратную совместимость для существующих приложений. x64 является ключевой частью стратегии для AMD (AMD64) и Intel (EMT64), и, за исключением ультра-мобильных процессоров, поддерживает технологию для всех текущих и будущих процессоров поколения.

Windows XP Professional x64 Edition была первой ориентированной на потребителем операционной системы Windows (OS) для поддержки технологии x64, а Windows Vista и Windows 7 значительно расширяют доступность 64-разрядных вычислительных систем ос. При использовании 2 ГБ ОЗУ в качестве стандартного на многих новых компьютерах дальнейшее улучшение масштабирования памяти не будет способствовать 32-разрядным отдельным приложениям, которые не могут обращаться к более чем 2 ГБ физической ОЗУ. Многие игры сегодня сталкиваются с проблемами, которые подходят для всех доступных содержимого в ограничениях в 2 ГБ виртуального адресного пространства, особенно при сочетании с большими видеозапомяниями, доступными на высокоуровневых GPU, и переход на технологию x64 значительно увеличивает поддержку уровней детализации.

Совместимость x64 для 32-разрядных игр — это техническое требование для Windows (2.2), но для использования новых технологий требуется 64-разрядная собственная реализация.

Дополнительная информация

Основным преимуществом 64-разрядной адресации является возможность прямого доступа к более чем 2 ГБ физической и виртуальной памяти. Большое адресное пространство виртуальной памяти позволяет широко использовать сопоставленные с памятью операции ввода-вывода без проблем с исчерпанием пространства виртуальных машин, распространенных в 32-разрядном программировании. Игры могут воспользоваться новым пространством, чтобы значительно улучшить время загрузки или, в некоторых случаях, чтобы исключить паузы для загрузки содержимого.

Существующие 32-разрядные приложения могут воспользоваться выпусками x64, имея возможность обрабатывать адреса с полными 32-разрядными данными при построении с параметром компоновщика Enable Large Addresses (/LARGEADDRESSAWARE). В 32-разрядных версиях Windows XP специальные режимы загрузки позволяют таким приложениям решать до 3 ГБ ОЗУ, а выпуски x64 предоставляют доступ до 4 ГБ ОЗУ для приложений с учетом крупных адресов (LAA). Хотя использование LAA в 32-разрядном приложении не соответствует этому требованию, эта технология моста является чрезвычайно полезным способом предоставления дополнительных преимуществ масштабирования в версиях Windows для тех, кто не полностью реализует это требование.

Дополнительные сведения см . в 64-разрядном программировании для разработчиков игр и ОЗУ, VRAM и других ОЗУ: 64-разрядная игра здесь на веб-сайте разработчика игр.

Примечание.

Ключевой задачей для этой демонстрации является обеспечение того, чтобы любые сторонние библиотеки или компоненты, на которые ваша игра опирались, доступны для 64-разрядной разработки. Многие устаревшие API Майкрософт также были исключены из 64-разрядной собственной среды, которая может оказаться проблемой для баз кода ядра, содержащих старые реализации ключевых систем.

S.3 эксплуатируют процессоры со многими ядрами

Требование

Игра реализует функции, которые используют многоядерные процессоры, масштабирование до 3, 4 или более ядер, если они доступны.

Если игра поддерживает однопроцессорные или двухядерные системы, параллельное сравнение с четырехядерными системами должно продемонстрировать убедительные новые функции, дополнительные убедительные эффекты, улучшение качества содержимого и /или повышение производительности.

Так как масштабирование с двумя ядрами уже широко поддерживается играми, а также автоматически используется различными усовершенствованиями драйверов Direct3D, масштабирование с двумя ядрами недостаточно для демонстрации этой демонстрации.

Логическое обоснование

Продолжающийся рост производительности ЦП переключился с улучшения частоты часов на добавление вычислительных ядер. Стратегии AMD и Intel основаны на масштабируемых многоядерных конструкциях. Все игровые платформы следующего поколения имеют многоядерные ЦП из-за этого фундаментального изменения в эволюции процессоров. Однопоточные приложения больше не будут видеть значительные выгоды от процессоров следующего поколения. Простое многопоточность также не сможет масштабироваться, так как число ядер ЦП в общем использовании увеличивается до трех или более.

Дополнительная информация

Обратите внимание, что количество ядер не должно быть мощностью двух, поэтому игры должны масштабироваться линейно и обрабатывать количество ядер 3, 4, 5, 6, 7, 8 и т. д.

Масштабирование путем увеличения числа потоков в приложении предоставляет возврат только в том случае, если затраты на синхронизацию обмена данными и потоками сохраняются в проверке. Масштабирование на основе функций может оказаться более простым решением в краткосрочной перспективе, позволяя игре работать нормально без дополнительных потоков в одноядерных системах и включить их, когда дополнительная мощность ЦП доступна.

Дополнительные сведения см. в статье "Написание кода для нескольких ядер" в Xbox 360 и Microsoft Windows и рекомендации по программированию без блокировки для Xbox 360 и Microsoft Windows в статьях DirectX, а также служебную программу DXUTLockFreePipe и пример CoreDetection.

Использование свободного потока ресурсов Direct3D 11 и контекстов устройств полезно для достижения масштабируемости на многих ядрах при отрисовке и загрузке графических ресурсов. См. статью "Игры для Windows Демонстрация S.1".

Обратите внимание, что использование инструкции ЦП rdtsc напрямую вместо использования API Windows для вычисления времени на многоядерных системах может привести к проблемам в некоторых конфигурациях оборудования и ОС; См . раздел "Время игры" и "Многоядерные процессоры " в статьях DirectX.

Игры поддержки S.4 для Windows — LIVE

Игры для Windows — LIVE больше не поддерживаются корпорацией Майкрософт.

S.5 поддерживает Windows Touch

Требование

Игры с поддержкой сенсорного ввода Windows можно играть с помощью сенсорных и /или жестов на компьютерах под управлением Windows 7 с сенсорным дисплеем. Кроме того, можно использовать ввод клавиатуры, но основной интерфейс воспроизведения должен быть сенсорным.

Включение касания не должно препятствовать использованию мыши или общего контроллера в соответствии с техническим требованием 1.4.

Установщик игры, как ожидается, не поддерживает функции Windows Touch.

Логическое обоснование

Экраны с поддержкой нескольких сенсорных устройств для компьютеров доступны для ноутбуков и настольных компьютеров, и они представляют ключевую функцию оборудования, которая продвигается в выпуске Windows 7. Windows 7 поддерживает Windows Touch на рабочем столе и общих интерфейсах элементов управления.

Дополнительная информация

Приложения машинного кода могут получать доступ к много сенсорным сообщениям WM_TOUCH в сочетании с функцией RegisterTouchWindow. См. также API манипуляций и инерции.

Windows Presentation Foundation (WPF) 4.0 предоставляет управляемое решение для много сенсорных интерфейсов.

Дополнительные сведения см. в пакете SDK для Windows Touch.

S.6 поддерживает высокий цвет

Требование

Игры, поддерживающие высокий цвет, используют формат 10:10:10:2 (DXGI_FORMAT_R10G10B10A2, D3DFMT_A2B10G10R10) или 16:16:16:16 (DXGI_FORMAT_R16G16B16A16, D3DFMT_A16B16G16R16) для режима отображения обратного буфера и полноэкранного отображения.

Используя целевой объект отрисовки с высоким цветом, содержимое с высоким динамическим диапазоном (HDR) можно отобразить с расширенным или широким диапазоном при выполнении сопоставления тонов с 10-разрядным или 16-разрядным диапазоном.

Логическое обоснование

Мониторы могут отображать более 256 цветового уровня на канал в течение многих лет, даже если дисплеи CRT были распространены. Сканирование оборудования на видеокартах было фактором ограничения. Современные графические процессоры, включая большинство оборудования Direct3D 9 класса и все класс Direct3D 10 и лучшее оборудование, имеют возможность сканирования оборудования, поддерживающего по крайней мере 10 бит на канал, и аппаратные возможности будут расти до 16 бит на цветной канал в будущем. Системы взаимодействия HD TV (HDMI, DisplayPort) предназначены для обработки более 8-разрядных систем на канал, а аналоговая VGA уже будет нести такие сигналы.

Дополнительная информация

Обратите внимание, что высокий цвет или цвет hi исторически относится к переходу от 256 (8-разрядного) цвета до 15- или 16-разрядных дисплеев. Большинство систем отображения уже давно перешли на True Color, который является 24-разрядным цветом или 8-разрядным каналом цвета для красного, зеленого и синего. По высокому цвету здесь мы имеем в виду новое поколение систем отображения, которые могут работать с более чем 8-разрядными на отдельный канал цветов. Он также называется глубоким цветом.

Введение

Помимо соответствия техническим требованиям и принятия одного или нескольких демонстраций в заголовке, есть ряд рекомендаций, которые следует соблюдать для всех игр Windows. Хотя эти рекомендации выходят за рамки основных технических требований, настоятельно рекомендуется использовать их для всех игр для названий Windows.

Дополнительные рекомендации

  • Используйте последний компилятор и среду выполнения Visual Studio. Более новые версии компилятора реализуют значительные улучшения качества кода, созданного и для проблем с безопасностью, и используют современные стратегии оптимизации процессора. Обновление компилятора и использование последней среды выполнения C — это простой способ миграции в современные методики написания кода.
  • Используйте версию библиотеки динамической компоновки (DLL) среды выполнения C, а не статических ссылок и используйте Secure CRT. (Исключения можно сделать в специальных случаях предварительной установки, например для программы автоматического запуска или для самого установщика).
  • Для воспроизведения звука используйте XAudio2, X3DAudio и /или XACT, а не DirectSound. Для звуковых подсистем, которые выполняют все перемешивание и преобразование скорости источника и требуют только решения с низкой задержкой для вывода звука, используйте DirectSound в Windows XP (только) и WASAPI в Windows Vista и Windows 7.
  • Избегайте использования устаревших и устаревших API: DirectDraw, DirectSound, DirectPlay, Уровня производительности DirectMusic, DirectPlay Voice и Direct3D В сохраненном режиме. Обратите внимание, что режим хранения directPlay Voice и Direct3D недоступен вообще в Windows Vista или Windows 7. Уровень производительности DirectPlay и DirectMusic недоступны для приложений на основе x64.
  • Оптимизация с помощью наборов инструкций SSE/SSE2 SIMD. См. API DirectXMath в пакете SDK для Windows в качестве кроссплатформенного решения для математических операций, оптимизированных для SIMD.
  • Используйте современные рекомендации по безопасности Windows (включая параметры компилятора и компоновщика, такие как /NXCOMPAT, /GS, /SAFESEH, /DYNAMICBASE, /SDL и т. д.). Дополнительные сведения см. в разделе "Рекомендации по обеспечению безопасности" в разработке игр.
  • Используйте последние компоненты и библиотеки пакета SDK для Windows. Удалите зависимости от устаревших компонентов DirectSetup, развернутых вне диапазона, таких как D3DX9, D3DX10 и D3DX11. Рекомендуется использовать DirectXTex или DirectXTK или оба варианта.
  • Избегайте использования более старого компилятора HLSL и вместо этого используйте современный компилятор HLSL. Если поддержка шейдера пикселей 1.x требуется для приложения, используйте сборку шейдера, а не HLSL, или ограничьте использование старого компилятора только для этих сценариев.

Ресурсы

Срок Description
Игры для Windows: тестовые случаи
Рекомендации по играм в Windows XP, Windows Vista и Windows 7
Windows SDK
Пакеты SDK для Windows
Рекомендации по управлению учетными записями пользователей
Требования к разработке приложений Windows Vista для обеспечения совместимости управления учетными записями пользователей
Портал разработчика DirectX
Центр разработчиков Directx
Блог по пакетам SDK для Windows и DirectX
 Игры для Windows и пакета SDK DirectX
Дополнительные статьи DirectX
 Технические статьи DirectX