Контроль учетных записей для разработчиков игр

  • Статья

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

Обзор управления учетными записями пользователей

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

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

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

Важно отметить, что приложения должны стремиться использовать только стандартные права пользователя, если это возможно. Хотя администраторы могут легко повысить привилегии процесса, повышение прав по-прежнему требует взаимодействия с пользователем и подтверждения при каждом запуске приложения, требующего административных учетных данных. Это повышение прав также необходимо сделать во время запуска программы, поэтому для одной операции требуется предоставить системе больший риск для всего времени выполнения приложения. Стандартные пользователи без каких-либо возможностей повышения привилегий также распространены в семейных и бизнес-параметрах. "Запуск от имени Администратор istrator" не является хорошим решением для совместимости, предоставляет пользователю и системе больший риск безопасности и создает разочарование для пользователей во многих ситуациях.

Примечание.

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

Учетные записи пользователей в Windows Vista

Windows Vista классифицирует каждого пользователя на два типа учетных записей пользователей: администраторов и стандартных пользователей.

Стандартная учетная запись пользователя аналогична учетной записи ограниченного пользователя в Windows XP. Как и в Windows XP, стандартный пользователь не может записывать в папку Program Files, не может записывать данные в HKEY_LOCAL_MACHINE части реестра и не может выполнять задачи, которые изменяют систему, например установку драйвера в режиме ядра или доступ к пространствам процессов уровня системы.

Учетная запись Администратор istrator значительно изменилась с момента выпуска Windows XP. Ранее все процессы, запущенные членом группы Администратор istrator, были предоставлены административные привилегии. С включенной функцией UAC все процессы выполняются со стандартными привилегиями пользователей, если только администратор не повышает их. Это различие делает учетные записи в группе Администратор istrators более безопасным путем снижения риска безопасности, вызванного потенциальными ошибками в большинстве программ.

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

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

Доступ к файлам как стандартный пользователь

Аспект игры, наиболее пострадавший от стандартных ограничений пользователей, — организация файловой системы и специальные возможности. Вы никогда не должны предполагать, что ваша игра может записывать файлы в папку, в которой установлена ваша игра. Например, в Windows Vista права пользователя должны быть повышены операционной системой, прежде чем приложение сможет записать в папку Program Files. Чтобы избежать этого, следует классифицировать файлы данных игры по область и специальным возможностям, а также использовать функцию SHGetFolderPath вместе с константами CSIDL, предоставляемыми оболочкой Windows, для создания соответствующих путей к файлам. Константы CSIDL соответствуют известным папкам в файловой системе, которую операционная система использует и способствует секционированием глобальных и пользовательских файлов.

Попытка создать или написать файл или каталог в папке, которая не предоставляет разрешение на запись в процесс, завершится ошибкой в Windows Vista, если у приложения нет прав администратора. Если исполняемый файл 32-разрядной игры выполняется в устаревшем режиме, так как он не объявил запрошенный уровень выполнения, операции записи будут выполнены успешно, но они будут подвергаться виртуализации, как описано в разделе "Совместимость UAC с старыми играми" далее в этой статье.

Таблица 1. Известные папки

Имя CSIDL Типичный путь (Windows Vista) Стандартные права пользователя Администратор istrator Rights Область доступа Description Примеры
CSIDL_PERSONAL C:\Users\user name\Documents Чтение и запись Чтение и запись Для каждого пользователя Файлы игры, которые считываются и изменяются пользователем, и могут управляться вне контекста игры. Снимки экрана. Сохраненные игровые файлы с сопоставлением расширения файла.
CSIDL_LOCAL_APPDATA C:\Users\user name\AppData\Local Чтение и запись Чтение и запись Для каждого пользователя Файлы игры, которые считываются и изменяются пользователем и используются только в контексте игры. Файлы кэша игр. Конфигурации проигрывателя.
CSIDL_COMMON_APPDATA C:\ProgramData Чтение и запись, если владелец Чтение и запись Все пользователи Игровые файлы, которые могут быть созданы пользователем и считываются всеми пользователями. Доступ на запись предоставляется только создателю файла (владельца). Профили пользователей
CSIDL_PROGRAM_FILES C:\Program Files
or
C:\Program Files (x86)
Только чтение Чтение и запись Все пользователи Статические игровые файлы, написанные установщиком игры, которые считываются всеми пользователями. Игровые ресурсы, такие как материалы и сетки.

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

Кроме того, следует воздержаться от жестко закодированных предположений о известных путях папок. Например, в Windows XP Professional 64-разрядной версии и Windows Vista x64 путь к файлам программы — C:\Program Files (x86) для 32-разрядных программ и C:\Program Files для 64-разрядных программ. Эти известные пути изменяются с Windows XP, и пользователи могут перенастроить расположение многих этих папок и даже найти их на разных дисках. Поэтому всегда используйте константы CSIDL, чтобы избежать путаницы и потенциальных проблем. Программа установки Windows понимает эти известные расположения папок и перемещает данные при обновлении операционной системы из Windows XP; В отличие от этого, использование нестандартных расположений или жестко закодированных путей может завершиться ошибкой после обновления ОС.

Следует обратить внимание на тонкие различия в удобствах между папками, указанными в CSIDL_PERSONAL и CSIDL_LOCAL_APPDATA. Рекомендуемая практика выбора константы CSIDL, используемой для записи файла, заключается в том, чтобы использовать CSIDL_PERSONAL, если пользователь, как ожидается, будет взаимодействовать с файлом, например дважды щелкнуть его, чтобы открыть его в средстве или приложении, и использовать CSIDL_LOCAL_APPDATA для других файлов. Обе папки могут использоваться приложением для хранения и упорядочивания файлов данных, зависящих от пользователей, так как нет различий в доступе область или уровне привилегий. Чтобы создать имена путей, которые достаточно уникальны, чтобы не столкнуться с другими приложениями, но достаточно коротким, чтобы сохранить количество символов в полном пути меньше, чем значение MAX_PATH, 260.

В следующем коде приведен пример записи файла в известную папку:

#include <windows.h>
#include <shlobj.h>
#include <shlwapi.h>
        ...
        ...
        ...
        TCHAR strPath[MAX_PATH];
        if( SUCCEEDED(
        SHGetFolderPath( NULL, CSIDL_PERSONAL, NULL, SHGFP_TYPE_CURRENT, strPath ) ) )
        {
        PathAppend( strPath, TEXT( "Company Name\\Title" ) );

        if( !PathFileExists( strPath ) )
        {
        if( ERROR_SUCCESS != SHCreateDirectoryEx( NULL, strPath, NULL ) )
        return E_FAIL;
        }

        PathAppend( strPath, TEXT( "gamefile.txt" ) );

        // strPath is now something like:
        // C:\Users\<current user>\Documents\Company Name\Title\gamefile.txt
        // Open the file for writing
        HANDLE hFile = CreateFile(strPath, GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

        if( INVALID_HANDLE_VALUE != hFile )
        {
        // TODO: Write to file
        CloseHandle(hFile);
        }
        }

Доступ к реестру как стандартный пользователь

Доступ к реестру стандартным пользователем ограничен аналогично файловой системе. Пользователь уровня "Стандартный" разрешен доступ на чтение ко всем разделам в реестре; Однако доступ на запись предоставляется только в поддереве HKEY_CURRENT_USER (HKCU), который сопоставляется внутренне с подразделом HKEY_USERS\Security ID (SID) текущего пользователя. Приложению, которое должно записываться в любое расположение реестра, отличное от HKEY_CURRENT_USER, требуются права администратора.

Если 32-разрядное приложение не содержит запрошенный уровень выполнения в манифесте, все записи в HKEY_LOCAL_MACHINE\Software будут виртуализированы, а запись в другие места за пределами HKEY_CURRENT_USER завершится ошибкой.

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

Повышение привилегий

В Windows Vista любой приложение, требующее прав администратора, должно объявлять запрос на уровень административного выполнения в манифесте (описано в следующем разделе, настройка уровня выполнения в манифесте приложения).

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

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

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

Рисунок 1. Запрос стандартного пользователя на ввод учетных данных для учетной записи администратора

prompt for a standard user to enter credentials for an administrative account

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

Рисунок 2. Запрос Администратор istrator для авторизации изменений на компьютере

prompt for an administrator to authorize changes to the computer

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

Важно отметить, что процесс с повышенными привилегиями выполняется как администратор, который ввел учетные данные в запросе UAC, а не как стандартный пользователь, вошедший в систему. Это аналогично запускам в Windows XP, который получает папку администратора и разделы реестра при доступе к данным пользователя, а все программы, запускаемые с повышенными привилегиями, также наследуют как административные права, так и расположения учетных записей пользователей. Для администраторов, которые запрашивают подтверждение (продолжить или отмену), эти расположения будут соответствовать расположениям текущего пользователя. Однако процессы, требующие повышения прав, не должны работать с данными для каждого пользователя. Обратите внимание, что это может существенно повлиять на работу установщика! Если установщик, работающий от имени администратора, записывается в HKCU или в профиль пользователя, он может быть написан в неправильном расположении. Рассмотрите возможность создания этих значений для каждого пользователя при первом запуске игры.

Последствия UAC с помощью CreateProcess()

Механизм повышения прав UAC не будет вызываться из вызова функции Win32 CreateProcess() для запуска исполняемого файла, который настроен на более высокий уровень выполнения, чем текущий процесс. В результате вызов CreateProcess() завершится ошибкой с возвратом getLastError() ERROR_ELEVATION_REQUIRED. CreateProcess() будет успешно выполнен только в том случае, если уровень выполнения вызываемого объекта равен или меньше, чем вызывающий объект. Неопровернутый процесс, который должен вызывать повышенные привилегии, должен сделать это с помощью функции ShellExecute(), что приведет к тому, что механизм повышения прав UAC активируется с помощью оболочки.

Настройка уровня выполнения в манифесте приложения

Вы объявляете запрошенный уровень выполнения игры, добавив расширение в манифест приложения. В следующем 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>

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

<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />

Явно задав запрошенное ЗначениеExecutionLevel в asInvoker, в этом примере утверждается операционная система, что игра будет работать правильно без прав администратора. В результате UAC отключает виртуализацию и запускает игру с теми же привилегиями, что и вызывающий объект, который обычно является стандартными привилегиями пользователей, так как Windows Обозреватель работает как стандартный пользователь.

Операционная система может быть проинформирована о том, что игра требует повышения прав администратора, заменив asInvoker на "require Администратор istrator", чтобы создать следующий тег:

<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

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

Распространенное заблуждение заключается в том, что добавление манифеста, который задает запрошенныйExecutionLevel значение "требовать Администратор istrator" обходит необходимость запроса на повышение прав. Это не так. Это просто запрещает операционной системе угадывать, требуется ли настройка или обновление приложения права администратора. Пользователю по-прежнему предлагается авторизовать повышение прав.

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

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

Внедрение манифеста в Visual Studio

Поддержка манифеста была добавлена в Visual Studio начиная с VS2005. По умолчанию исполняемый файл, встроенный в Visual Studio 2005 (или более поздней версии), будет внедрен в него автоматически созданный манифест в процессе сборки. Содержимое автоматически созданного манифеста зависит от определенных конфигураций проекта, указанных в диалоговом окне свойств проекта.

Манифест, автоматически созданный Visual Studio 2005, не будет содержать <блок trustInfo> , так как невозможно настроить уровень выполнения UAC в свойствах проекта. Предпочтительный способ добавить эти сведения заключается в том, чтобы разрешить VS2005 объединить определяемый пользователем манифест, содержащий <блок trustInfo> с автоматически созданным манифестом. Это так же просто, как добавление файла *.manifest в решение, содержащее XML-файл, указанный в предыдущем разделе. Когда Visual Studio сталкивается с файлом манифеста в решении, он автоматически вызывает средство манифеста (mt.exe), чтобы объединить файлы манифеста с автоматически созданным.

Примечание.

В средстве манифеста (mt.exe), предоставленном Visual Studio 2005, возникает ошибка в объединенном и внедренном манифесте, который может вызвать проблемы при запуске исполняемого файла в Windows XP до sp3. Ошибка — это результат того, как средство переопределяет пространство имен по умолчанию при объявлении <блока trustInfo> . К счастью, легко обойти проблему, явно объявив другое пространство имен в <блоке trustInfo> и задав области дочерних узлов в новое пространство имен. Xml, предоставленный в предыдущем разделе, демонстрирует это исправление.

Предостережение при использовании средства mt.exe, включенного в Visual Studio 2005, заключается в том, что при обработке <блока trustInfo> средство не содержит обновленную схему для проверки XML. Чтобы устранить это предупреждение, рекомендуется заменить все файлы mt.exe в каталоге установки Visual Studio 2005 (существует несколько экземпляров) с помощью mt.exe, предоставленного в последнем пакете SDK для Windows.

Начиная с Visual Studio 2008, теперь можно указать уровень выполнения приложения в диалоговом окне свойств проекта (рис. 3) или с помощью флага компоновщика /MANIFESTUAC. Установка этих параметров приведет к автоматическому созданию и внедрению манифеста с соответствующим <блоком trustInfo> в исполняемый файл Visual Studio 2008.

Рисунок 3. Настройка уровня выполнения в Visual Studio 2008

setting the execution level in visual studio 2008

Внедрение манифеста в более ранних версиях Visual Studio без поддержки манифеста по-прежнему возможно, но требует больше работы от разработчика. Пример этого можно найти в проекте Visual Studio 2003, включенном в любой пример в пакете SDK DirectX до выпуска за март 2008 г.

Совместимость UAC со старыми играми

Если ваша игра, как представляется, сохраняет и загружает файл в каталог Program Files, но нет доказательств файла iOn Windows Vista, любое 32-разрядное приложение, которое не содержит запрошенный уровень выполнения в своем манифесте, считается устаревшим приложением. До Windows Vista большинство приложений обычно выполняются пользователями с правами администратора. В результате эти приложения могут свободно читать и записывать системные файлы и разделы реестра, и многие разработчики не внесите изменения, необходимые для правильной работы с ограниченными учетными записями пользователей в Windows XP. Однако в Windows Vista эти же приложения теперь завершаются ошибкой из-за нехватки привилегий доступа в рамках новой модели безопасности, которая обеспечивает стандартное выполнение пользователей для устаревших приложений. Чтобы снизить влияние этого, виртуализация также была добавлена в Windows Vista. Виртуализация будет поддерживать тысячи устаревших приложений, работающих в Windows Vista, не требуя, чтобы эти приложения имели повышенные привилегии в любое время просто для успешного выполнения нескольких дополнительных операций. обнаружены шансы, что ваша игра работает в устаревшем режиме и подвергалась виртуализации.

Виртуализация влияет на файловую систему и реестр путем перенаправления системных операций записи (и последующих операций файлов или реестра) в расположение для каждого пользователя в профиле текущего пользователя. Например, если приложение пытается записать в следующий файл:

C:\\Program Files\\Company Name\\Title\\config.ini

Запись автоматически перенаправляется в:

C:\\Users\\user name\\AppData\\Local\\VirtualStore\\Program Files\\Company Name\\Title\\config.ini

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

HKEY\_LOCAL\_MACHINE\\Software\\Company Name\\Title

Вместо этого он будет перенаправлен на:

HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Company Name\\Title

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

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

Рисунок 4. Процесс виртуализации

virtualization process

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

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

Обратите внимание, что если UAC отключен, виртуализация также отключена. Если виртуализация отключена, стандартные учетные записи пользователей работают точно так же, как ограниченные учетные записи пользователей в Windows XP, а устаревшие приложения могут работать неправильно для стандартных пользователей, которые в противном случае были бы успешными из-за виртуализации.

Устаревшие сценарии и манифесты

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

Существует особый случай, когда программа помечена как "требовать Администратор istrator" в манифесте UAC. В Windows XP и Windows Vista или Windows 7 с отключенным элементом управления учетными записями пользователя элементы манифеста UAC игнорируются системой. В этом случае пользователи с учетными записями администратора всегда будут запускать все программы с полными правами администратора, поэтому эти программы будут работать должным образом. Пользователи с ограниченным доступом Windows XP и стандартные пользователи, работающие в Windows Vista или Windows 7, всегда будут запускать эти программы с ограниченными правами, а все операции уровня администратора завершаются ошибкой. Поэтому рекомендуется, чтобы программы, помеченные как "requiret Администратор istrator", вызывали IsUserAn Администратор при запуске и отображали неустранимое сообщение об ошибке, если возвращает значение FALSE. Для приведенного выше сценария большинства это всегда будет успешно, но обеспечивает более удобный интерфейс пользователя и четкое сообщение об ошибке для этой редкой ситуации.

Заключение

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

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

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

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

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

Дополнительные сведения об управлении учетными записями пользователей см . в Windows Vista: управление учетными записями пользователей в Microsoft TechNet.

Другим полезным ресурсом является статья "Обучение приложений, чтобы играть приятно с помощью управления учетными записями пользователей Windows Vista", из журнала MSDN, январь 2007 года. В этой статье рассматриваются общие вопросы совместимости приложений, а также преимущества и проблемы использования пакетов установщика Windows в Windows Vista.

Дополнительные сведения об ошибке и исправлении для mt.exe, инструмент, используемый Visual Studio 2005 для автоматического слияния и внедрения манифеста в исполняемый файл, см. в статье "Изучение манифестов" части 2. Пространства имен по умолчанию и манифесты UAC в Windows Vista в блоге Криса Джексона в MSDN.