Controle de conta de usuário para desenvolvedores de jogos

Este artigo descreve as diretrizes e as práticas recomendadas para que os desenvolvedores de jogos trabalhem efetivamente com o recurso de segurança UAC (Controle de Conta de Usuário) introduzido no Windows Vista.

• Visão geral do controle de conta de usuário
• Contas de usuário no Windows Vista
• Acesso a arquivos como um usuário padrão
• Acesso ao Registro como um usuário padrão
• Elevação de privilégio
• Implicações do UAC com CreateProcess()
• Definindo o nível de execução no manifesto do aplicativo
• Inserindo um manifesto no Visual Studio
• Compatibilidade do UAC com jogos mais antigos
• Cenários e manifestos herdados
• Conclusão
• Leitura Adicional

Visão geral do controle de conta de usuário

O UAC (Controle de Conta de Usuário), introduzido no Windows Vista, é um recurso de segurança projetado para ajudar a impedir que invasores mal-intencionados usem pontos fracos ou bugs encontrados em aplicativos amplamente usados para alterar o sistema operacional ou outros programas instalados. Isso é feito executando a grande maioria dos programas e processos como um Usuário Padrão (também conhecido como Usuário Limitado, Usuário Restrito ou Usuário Least-Privileged), mesmo que a conta do usuário atual tenha credenciais administrativas. Um processo com privilégios de usuário padrão tem muitas restrições inerentes que o impedem de fazer alterações em todo o sistema.

O UAC também é responsável pela elevação de privilégio de um processo usando um esquema de autenticação baseado em caixa de diálogo iniciado após a execução de determinados processos designados como exigindo privilégios administrativos. A elevação de privilégio permite que os administradores executem a maioria de seus aplicativos em um nível de privilégio seguro (o mesmo que qualquer outro usuário padrão), mas também permitem processos e operações que exigem privilégios administrativos. O UAC dá suporte à autenticação over-the-shoulder para que um administrador possa conceder privilégios elevados a um programa enquanto um usuário padrão estiver conectado ao sistema no momento.

O recurso UAC está habilitado por padrão. Embora seja possível para um administrador desabilitar o UAC em todo o sistema, isso tem várias ramificações negativas. Primeiro, isso enfraquece a segurança de todas as contas administrativas, pois todos os processos seriam executados com credenciais administrativas, mesmo quando a maioria dos aplicativos realmente não as exige. Com o UAC desabilitado, um aplicativo de usuário padrão que expõe uma vulnerabilidade explorável na segurança pode potencialmente ser usado para roubar informações privadas, instalar rootkits ou spyware, destruir a integridade do sistema ou hospedar ataques zumbis em outros sistemas. Enquanto com o UAC habilitado, a execução da maioria dos softwares como um usuário padrão limita muito o dano potencial de tal bug. Em segundo lugar, desativar o UAC desabilita muitas das soluções alternativas para compatibilidade de aplicativos que permitem que os verdadeiros usuários padrão executem com êxito uma ampla gama de aplicativos. A desabilitação do UAC nunca deve ser recomendada como uma solução alternativa de compatibilidade.

É importante observar que os aplicativos devem se esforçar apenas para usar direitos de usuário padrão, se possível. Embora os administradores possam elevar facilmente os privilégios de um processo, a elevação ainda requer interação e confirmação do usuário sempre que um aplicativo é executado que requer credenciais administrativas. Essa elevação também deve ser feita no momento em que o programa é iniciado, portanto, exigir credenciais administrativas até mesmo para uma única operação requer expor o sistema a um risco maior durante todo o tempo de execução do aplicativo. Usuários padrão sem qualquer capacidade de elevar seus privilégios também são comuns nas configurações da família e dos negócios. "Executar como administrador" não é uma boa solução alternativa para compatibilidade, expõe o usuário e o sistema a um risco de segurança maior e cria frustração para os usuários em muitas situações.

Observação

O recurso Controle de Conta de Usuário introduzido no Windows Vista também está presente no Windows 7. Embora a experiência do usuário trabalhando com os vários recursos do sistema tenha sido aprimorada em relação ao Controle de Conta de Usuário, o impacto nos aplicativos é basicamente o mesmo. Todas as recomendações do Windows Vista neste artigo também se aplicam ao Windows 7. Para obter detalhes sobre as alterações na interface do usuário do UAC para Windows 7, consulte Interface do Usuário – Caixa de diálogo Controle de Conta de Usuário Atualizações.

Contas de usuário no Windows Vista

O Windows Vista categoriza cada usuário em dois tipos de conta de usuário: administradores e usuários padrão.

Uma conta de usuário padrão é semelhante a uma conta de usuário limitado no Windows XP. Assim como no Windows XP, um usuário padrão não pode gravar na pasta Arquivos de Programas, não pode gravar na parte HKEY_LOCAL_MACHINE do registro e não pode executar tarefas que alteram o sistema, como instalar um driver no modo kernel ou acessar espaços de processo no nível do sistema.

A conta administrador mudou significativamente desde que o Windows XP foi lançado. Anteriormente, todos os processos iniciados por um membro do grupo Administradores recebiam privilégios administrativos. Com o UAC habilitado, todos os processos são executados com privilégios de usuário padrão, a menos que sejam especificamente elevados por um administrador. Essa diferença torna as contas no grupo Administradores mais seguras, reduzindo o risco de segurança representado por possíveis bugs na maioria dos programas.

É importante que todos os aplicativos, especialmente os jogos, operem de forma eficaz e responsável quando executados como um processo de usuário padrão. Todas as operações que exigem privilégios administrativos devem ser feitas no momento da instalação ou por programas auxiliares que solicitam explicitamente credenciais administrativas. Embora a elevação de privilégio seja bastante trivial para um membro do grupo Administradores, os usuários padrão devem adiar para alguém com credenciais administrativas para inserir fisicamente sua senha para elevar privilégios. Como as contas protegidas pelos controles dos pais devem ser usuários padrão, essa será uma situação muito comum para os jogadores que estão usando o Windows Vista.

Se o jogo já estiver funcionando no Windows XP com contas de usuário limitado, a mudança para o Controle de Conta de Usuário no Windows Vista deverá ser muito fácil. A maioria desses aplicativos funcionará no momento, embora a adição de um manifesto do aplicativo seja altamente recomendada. (Os manifestos são descritos posteriormente neste tópico em Definindo o nível de execução no manifesto do aplicativo.)

Acesso a arquivos como um usuário padrão

O aspecto do jogo mais afetado pelas restrições de usuário padrão é a organização do sistema de arquivos e a acessibilidade. Você nunca deve assumir que seu jogo pode gravar arquivos na pasta em que o jogo está instalado. No Windows Vista, por exemplo, os privilégios de um usuário devem ser elevados pelo sistema operacional antes que um aplicativo possa gravar na pasta Arquivos de Programas. Para evitar isso, você deve categorizar os arquivos de dados do jogo por escopo e acessibilidade e usar a função SHGetFolderPath , juntamente com as constantes CSIDL fornecidas pelo shell do Windows, para gerar os caminhos de arquivo apropriados. As constantes CSIDL correspondem a pastas conhecidas no sistema de arquivos que o sistema operacional usa e promove para particionar arquivos globais e específicos do usuário.

A tentativa de criar ou gravar um arquivo ou diretório em uma pasta que não concede permissão de gravação ao processo falhará no Windows Vista se o aplicativo não tiver privilégios administrativos. Se o executável do jogo de 32 bits estiver em execução no modo herdado, porque ele não declarou um nível de execução solicitado, suas operações de gravação terão êxito, mas serão submetidas à virtualização, conforme descrito na seção "Compatibilidade do UAC com jogos mais antigos" mais adiante neste artigo.

Tabela 1. Pastas Conhecidas

Nome CSIDL	Caminho típico (Windows Vista)	Direitos de Usuário Padrão	Direitos de administrador	Escopo de acesso	Descrição	Exemplos
CSIDL_PERSONAL	C:\Users\user name\Documents	Leitura/Gravação	Leitura/Gravação	Por Usuário	Arquivos de jogo específicos do usuário que são lidos e modificados e podem ser manipulados fora do contexto do jogo.	Capturas de tela. Arquivos de jogo salvos com uma associação de extensão de arquivo.
CSIDL_LOCAL_APPDATA	C:\Users\user name\AppData\Local	Leitura/Gravação	Leitura/Gravação	Por Usuário	Arquivos de jogo específicos do usuário que são lidos e modificados e são de uso somente dentro do contexto do jogo.	Arquivos de cache de jogos. Configurações do player.
CSIDL_COMMON_APPDATA	C:\ProgramData	Leitura/gravação se proprietário	Leitura/Gravação	Todos os Usuários	Arquivos de jogos que podem ser criados por um usuário e lidos por todos os usuários. O acesso de gravação é concedido somente ao criador do arquivo (proprietário).	Perfis de Usuário
CSIDL_PROGRAM_FILES	C:\Arquivos de Programas ou C:\Arquivos de Programas (x86)	Somente leitura	Leitura/Gravação	Todos os Usuários	Arquivos de jogos estáticos gravados pelo instalador do jogo que são lidos por todos os usuários.	Ativos do jogo, como materiais e malhas.

Normalmente, o jogo será instalado em uma pasta na pasta representada pela constante CSIDL_PROGRAM_FILES. No entanto, esse nem sempre é o caso. Em vez disso, você deve usar um caminho relativo do arquivo executável ao gerar cadeias de caracteres de caminho para arquivos ou diretórios localizados na pasta de instalação.

Você também deve se abster de suposições embutidas em código sobre os caminhos de pasta conhecidos. Por exemplo, no Windows XP Professional 64 bits Edition e no Windows Vista x64, o caminho dos arquivos de programa é C:\Arquivos de Programas (x86) para programas de 32 bits e C:\Arquivos de Programas para programas de 64 bits. Esses caminhos conhecidos são alterados do Windows XP e os usuários podem reconfigurar o local de muitas dessas pastas e até mesmo localizá-las em unidades diferentes. Portanto, sempre use as constantes CSIDL para evitar confusão e possíveis problemas. A Instalação do Windows entende esses locais de pasta conhecidos e moverá os dados ao atualizar o sistema operacional do Windows XP; Por outro lado, o uso de locais não padrão ou caminhos embutidos em código pode falhar após uma atualização do sistema operacional.

Deve-se dar atenção às diferenças sutis de usabilidade entre as pastas específicas do usuário especificadas por CSIDL_PERSONAL e CSIDL_LOCAL_APPDATA. A prática recomendada para selecionar a constante CSIDL a ser usada para gravar um arquivo é usar CSIDL_PERSONAL se espera-se que o usuário interaja com o arquivo, como clicar duas vezes nele para abri-lo em uma ferramenta ou aplicativo e usar CSIDL_LOCAL_APPDATA para outros arquivos. Ambas as pastas podem ser aproveitadas pelo seu aplicativo para armazenar e organizar arquivos de dados específicos do usuário, pois não há diferença no escopo de acesso ou no nível de privilégio. Deve-se tomar cuidado para criar nomes de caminho exclusivos o suficiente para não colidir com outros aplicativos, mas curto o suficiente para manter o número de caracteres no caminho completo menos do que o valor de MAX_PATH, 260.

O código a seguir fornece um exemplo de como gravar um arquivo em uma pasta conhecida:

#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);
        }
        }

Acesso ao Registro como um usuário padrão

O acesso ao Registro por um usuário padrão é restrito de maneira semelhante ao sistema de arquivos. Um usuário padrão tem permissão para acesso de leitura a todas as chaves no Registro; no entanto, o acesso de gravação só é concedido à subárvore HKEY_CURRENT_USER (HKCU), que é mapeada internamente para a subchave específica do usuário HKEY_USERS\Security ID (SID) do usuário atual. Um aplicativo que precisa gravar em qualquer local do Registro que não seja HKEY_CURRENT_USER requer privilégios administrativos.

Se o aplicativo de 32 bits não contiver um nível de execução solicitado em seu manifesto, todas as gravações em HKEY_LOCAL_MACHINE\Software serão virtualizadas, enquanto as gravações em outros locais fora de HKEY_CURRENT_USER falharão.

Não é recomendável armazenar dados persistentes no registro, como a configuração de um usuário. O método preferencial de armazenar dados persistentes do jogo é gravar os dados no sistema de arquivos chamando SHGetFolderPath e obter o valor de uma constante CSIDL, descrito na seção anterior.

Elevação de privilégio

No Windows Vista, qualquer aplicativo que exija privilégios administrativos deve declarar uma solicitação para um nível de execução administrativa em seu manifesto (descrito na próxima seção, Definindo o nível de execução no manifesto do aplicativo).

Elevação, como é conhecido, é o procedimento orientado pelo UAC para promover um processo a um processo administrativo. Os privilégios de um processo só podem ser elevados no momento da criação. Depois de criado, um processo nunca será promovido a um nível de privilégio mais alto. Por esse motivo. as operações que exigem credenciais administrativas devem ser isoladas para separar instaladores e outros programas auxiliares.

Após a execução de um programa, o UAC inspeciona o nível de execução solicitado no manifesto e, se forem necessários privilégios elevados, solicita ao usuário atual uma das duas caixas de diálogo padrão: uma para um usuário padrão e outra para um administrador.

Se o usuário atual for um usuário padrão, o UAC solicitará ao usuário as credenciais de um administrador antes de permitir que o programa seja executado.

Figura 1. Solicitar que um usuário padrão insira credenciais para uma conta administrativa

Se o usuário atual for um administrador, o UAC solicitará permissão ao usuário antes de permitir que o programa seja executado.

Figura 2. Solicitar que um administrador autorize alterações no computador

O aplicativo só receberá privilégios administrativos se um usuário padrão fornecer as credenciais administrativas adequadas ou um usuário administrativo fornecer confirmação; qualquer outra coisa fará com que o aplicativo seja encerrado.

É importante observar que um processo com privilégios elevados é executado como o usuário administrativo que inseriu credenciais no prompt do UAC em vez de como o usuário padrão que está conectado no momento. Isso é semelhante a RunAs no Windows XP, o processo com privilégios elevados obtém a pasta do administrador e as chaves do Registro ao acessar dados por usuário, e todos os programas iniciados pelo processo elevado também herdam os direitos administrativos e os locais da conta de usuário. Para administradores que receberem uma solicitação de confirmação (Continuar ou Cancelar), esses locais corresponderão aos locais do usuário atualmente. Em geral, no entanto, os processos que exigem elevação não devem operar em dados por usuário. Observe que isso pode afetar substancialmente como o instalador deve operar! Se o instalador, em execução como administrador, gravar no HKCU ou no perfil de um usuário, ele poderá muito bem estar gravando no local errado. Considere criar esses valores por usuário na primeira execução do jogo.

Implicações do UAC com CreateProcess()

O mecanismo de elevação do UAC não será invocado de uma chamada para a função CreateProcess() do Win32 para iniciar um executável configurado para exigir um nível de execução mais alto do que o processo atual. Como resultado, a chamada para CreateProcess() falhará com GetLastError() retornando ERROR_ELEVATION_REQUIRED. CreateProcess() só terá êxito quando o nível de execução do receptor for igual ou menor que o do chamador. Um processo não elevado que deve gerar processos elevados deve fazer isso usando a função ShellExecute(), o que fará com que o mecanismo de elevação do UAC seja disparado por meio do shell.

Definindo o nível de execução no manifesto do aplicativo

Você declara o nível de execução solicitado do jogo adicionando uma extensão ao manifesto do aplicativo. O código XML a seguir mostra a configuração mínima necessária para definir o nível de execução de um aplicativo:

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

No código anterior, o sistema operacional é informado de que o jogo requer apenas privilégios de usuário padrão pela seguinte marca:

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

Ao definir explicitamente requestedExecutionLevel como "asInvoker", este exemplo declara ao sistema operacional que o jogo se comportará corretamente sem privilégios administrativos. Como resultado, o UAC desabilita a virtualização e executa o jogo com os mesmos privilégios que o invocador, que normalmente são privilégios de usuário padrão, já que o Windows Explorer é executado como usuário padrão.

O sistema operacional pode ser informado de que um jogo requer elevação para privilégios administrativos substituindo "asInvoker" por "requireAdministrator", para criar a seguinte marca:

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

Com essa configuração, o sistema operacional solicita ao usuário atual uma das caixas de diálogo de elevação padrão do UAC sempre que o jogo é executado. É altamente recomendável que nenhum jogo exija privilégios de administrador para execução, pois não só essa caixa de diálogo se tornará rapidamente irritante, mas também tornará o jogo incompatível com os controles dos pais. Pense com muito cuidado antes de adicionar esse requisito a qualquer executável.

Um equívoco comum é que adicionar um manifesto que define requestedExecutionLevel para "requireAdministrator" ignora a necessidade de um prompt de elevação. Isso não é verdade. Isso simplesmente impede que o sistema operacional adivinhe se o aplicativo de instalação ou atualização precisa de privilégios administrativos. O usuário ainda é solicitado a autorizar a elevação.

O Windows verifica a assinatura de qualquer aplicativo marcado para elevação antes de exibir o prompt do UAC. Um executável grande marcado para elevação leva mais tempo para marcar do que um executável pequeno e mais longo do que um executável marcado como "asInvoker". Os executáveis de instalação que são de extração automática devem, portanto, ser marcados como "asInvoker" e qualquer parte que precise ser marcada como "requireAdministrator" deve ser colocada em um executável auxiliar separado.

O atributo uiAccess, mostrado nos exemplos anteriores, sempre deve ser FALSE para jogos. Esse atributo especifica se os clientes de automação da interface do usuário têm acesso à interface do usuário do sistema protegido e tem implicações especiais de segurança se definido como TRUE.

Inserindo um manifesto no Visual Studio

O suporte ao manifesto foi adicionado pela primeira vez ao Visual Studio a partir do VS2005. Por padrão, um executável criado no Visual Studio 2005 (ou mais recente) terá um manifesto gerado automaticamente inserido nele como parte do processo de build. O conteúdo do manifesto gerado automaticamente depende de determinadas configurações de projeto especificadas na caixa de diálogo de propriedades do projeto.

O manifesto gerado automaticamente pelo Visual Studio 2005 não conterá um <bloco trustInfo> , pois não há como configurar o nível de execução do UAC nas propriedades do projeto. A maneira preferencial de adicionar essas informações é permitir que o VS2005 mescle um manifesto definido pelo usuário que contém o <bloco trustInfo> com o manifesto gerado automaticamente. Isso é tão simples quanto adicionar um arquivo *.manifest à solução que contém o XML listado na seção anterior. Quando o Visual Studio encontrar um arquivo .manifest em sua solução, ele invocará automaticamente a Ferramenta de Manifesto (mt.exe) para mesclar os arquivos .manifest com o gerado automaticamente.

Observação

Há um bug na Ferramenta de Manifesto (mt.exe) fornecido pelo Visual Studio 2005 que resulta em um manifesto mesclado e inserido que pode causar problemas quando o executável é executado no Windows XP antes do SP3. O bug é resultado de como a ferramenta redefine o namespace padrão após a declaração do <bloco trustInfo> . Felizmente, é fácil ignorar totalmente o problema declarando explicitamente um namespace diferente no <bloco trustInfo> e fazendo o escopo dos nós filho para o novo namespace. O XML fornecido na seção anterior demonstra essa correção.

Uma limitação ao usar a ferramenta mt.exe incluída no Visual Studio 2005 é que ela gerará um aviso ao processar o <bloco trustInfo> , pois a ferramenta não contém um esquema atualizado para validar o XML. Para corrigir esse aviso, é recomendável substituir todos os arquivos mt.exe no diretório de instalação do Visual Studio 2005 (há várias instâncias) pelo mt.exe fornecido no SDK do Windows mais recente.

A partir do Visual Studio 2008, agora você pode especificar o nível de execução de um aplicativo de dentro da caixa de diálogo de propriedades do projeto (Figura 3) ou usando o sinalizador do vinculador /MANIFESTUAC. Definir essas opções fará com que o Visual Studio 2008 gere automaticamente e insira um manifesto com o bloco trustInfo> apropriado <no executável.

Figura 3. Definindo o nível de execução no Visual Studio 2008

A inserção de um manifesto em versões mais antigas do Visual Studio sem suporte de manifesto ainda é possível, mas requer mais trabalho do desenvolvedor. Para obter um exemplo de como fazer isso, examine o projeto do Visual Studio 2003 incluído em qualquer exemplo no SDK do DirectX antes da versão de março de 2008.

Compatibilidade do UAC com jogos mais antigos

Se o jogo parece estar salvando e carregando um arquivo com êxito no diretório Arquivos de Programas, mas nenhuma evidência do arquivo iOn Windows Vista, qualquer aplicativo de 32 bits que não contenha um nível de execução solicitado em seu manifesto será considerado um aplicativo herdado. Antes do Windows Vista, a maioria dos aplicativos normalmente era executada por usuários com privilégios administrativos. Como resultado, esses aplicativos poderiam ler e gravar livremente arquivos do sistema e chaves do Registro, e muitos desenvolvedores não fizeram as alterações necessárias para funcionar corretamente em Contas de Usuário Limitadas no Windows XP. No entanto, no Windows Vista, esses mesmos aplicativos agora falhariam devido a privilégios de acesso insuficientes no novo modelo de segurança, o que impõe a execução padrão do usuário para aplicativos herdados. Para atenuar o impacto disso, a virtualização também foi adicionada ao Windows Vista. A virtualização manterá milhares de aplicativos herdados funcionando bem no Windows Vista sem exigir que esses aplicativos tenham privilégios elevados o tempo todo simplesmente para ter êxito em algumas operações secundárias. s encontrado, as chances são de que seu jogo está em execução no modo herdado e foi submetido à virtualização.

A virtualização afeta o sistema de arquivos e o registro redirecionando gravações sensíveis ao sistema (e operações subsequentes de arquivo ou registro) para um local por usuário dentro do perfil do usuário atual. Por exemplo, se um aplicativo tentar gravar no seguinte arquivo:

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

a gravação é redirecionada automaticamente para:

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

Da mesma forma, se um aplicativo tentar gravar um valor do Registro como o seguinte:

HKEY\_LOCAL\_MACHINE\\Software\\Nome da Empresa\\Título

em vez disso, ele será redirecionado para:

HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Nome da Empresa\\Título

Arquivos e chaves do Registro afetados pela virtualização só são acessados por operações de arquivo e registro de aplicativos virtualizados que estão em execução como o usuário atual.

No entanto, há muitas restrições à virtualização. Uma delas é que aplicativos de 64 bits nunca são executados no modo herdado para operações de compatibilidade sujeitas à virtualização em aplicativos de 32 bits falharão apenas em 64 bits. Além disso, se um aplicativo herdado em execução como um usuário padrão tentar gravar qualquer tipo de arquivo executável em um local que exija credenciais administrativas, a virtualização não ocorrerá e a gravação falhará.

Figura 4. Processo de virtualização

Quando um aplicativo herdado tenta uma operação de leitura em locais sensíveis ao sistema no sistema de arquivos ou registro, os locais virtuais são pesquisados primeiro. Se o arquivo ou a chave do Registro não for encontrado, o sistema operacional acessará os locais padrão do sistema.

A virtualização será removida das versões subsequentes do Windows, portanto, é importante não confiar nesse recurso. Em vez disso, você deve configurar explicitamente o manifesto do aplicativo para privilégios administrativos ou de usuário padrão, pois isso desabilitará a virtualização. A virtualização também não é óbvia para os usuários finais, portanto, embora a virtualização possa permitir que seu aplicativo seja executado, ela pode gerar chamadas de suporte e dificultar a geração de problemas para esses clientes.

Observe que, se o UAC estiver desabilitado, a virtualização também será desabilitada. Se a virtualização estiver desabilitada, as contas de usuário padrão se comportarão exatamente como contas de usuário limitadas no Windows XP e os aplicativos herdados poderão não funcionar corretamente para usuários padrão que, de outra forma, teriam êxito devido à virtualização.

Cenários e manifestos herdados

Para a maioria dos cenários de uso, simplesmente marcar o .exe com os elementos de manifesto UAC corretos e garantir que o aplicativo funcione corretamente como um Usuário Padrão é suficiente para excelente compatibilidade do UAC. A maioria dos jogadores está executando o Windows Vista ou o Windows 7 com o Controle de Conta de Usuário habilitado. Para Windows XP e usuários no Windows Vista ou Windows7 com o recurso Controle de Conta de Usuário desabilitado, eles normalmente são executados usando contas de administrador. Embora esse seja um modo de operação menos seguro, geralmente não haverá problemas de compatibilidade adicionais, embora conforme observado acima, desabilitar o UAC também desabilita a virtualização.

Há um caso especial que vale a pena observar quando o programa é marcado como "requireAdministrator" no manifesto do UAC. No Windows XP e no Windows Vista ou no Windows 7 com o Controle de Conta de Usuário desabilitado, os elementos de manifesto UAC são ignorados pelo sistema. Nessa situação, os usuários com contas de administrador sempre executarão todos os programas com direitos de administrador completos e, portanto, esses programas funcionarão conforme o esperado. Os Usuários Restritos do Windows XP e os Usuários Padrão em execução no Windows Vista ou no Windows 7, no entanto, sempre executarão esses programas com direitos restritos e todas as operações no nível do administrador falharão. Portanto, é recomendável que os programas marcados como "requiretAdministrator" chamem IsUserAnAdmin na inicialização e exibam uma mensagem de erro fatal se ela retornar FALSE. Para o cenário majoritário acima, isso sempre terá êxito, mas fornece uma melhor experiência do usuário e uma mensagem de erro clara para essa situação rara.

Conclusão

Como um desenvolvedor de jogos direcionado ao ambiente multiusuário do Windows, é imperativo que você projete seu jogo para operar de forma eficaz e responsável. O arquivo executável main do jogo não deve depender de privilégios administrativos. Isso não apenas impede a aparência de solicitações de elevação toda vez que seu jogo é executado, o que pode afetar negativamente a experiência geral do usuário, mas também permite que seu jogo aproveite outros recursos que exigem execução com privilégios de usuário padrão, como Controles dos Pais.

Os aplicativos projetados corretamente para operar como com as credenciais de um usuário padrão (ou usuário limitado) em versões anteriores do Windows não serão afetados pelo UAC que serão executados sem elevação. No entanto, eles devem incluir um manifesto com o nível de execução solicitado definido como "asInvoker" para estar em conformidade com os padrões de aplicativo do Vista.

Leitura Adicional

Para obter assistência com a criação de aplicativos para Windows Vista compatíveis com o Controle de Conta de Usuário, baixe o seguinte white paper: Requisitos de desenvolvimento de aplicativos do Windows Vista para compatibilidade de controle de conta de usuário.

Este white paper fornece etapas detalhadas sobre o processo de design, juntamente com exemplos de código, requisitos e práticas recomendadas. Este artigo também detalha as atualizações técnicas e as alterações na experiência do usuário no Windows Vista.

Para obter mais informações sobre o Controle de Conta de Usuário, visite Windows Vista: Controle de Conta de Usuário no Microsoft TechNet.

Outro recurso útil é o artigo Teach Your Apps To Play Nicely with Windows Vista User Account Control, da MSDN Magazine, janeiro de 2007. Este artigo aborda problemas gerais de compatibilidade de aplicativos, bem como as vantagens e problemas de uso de pacotes do Windows Installer no Windows Vista.

Para obter mais informações sobre o bug e a correção para mt.exe, a ferramenta usada pelo Visual Studio 2005 para mesclar e inserir automaticamente um manifesto em um executável, consulte Explorando manifestos parte 2: namespaces padrão e manifestos UAC no Windows Vista no blog de Chris Jackson no MSDN.