Contrôle de compte d’utilisateur pour les développeurs de jeux

Cet article décrit les instructions et les meilleures pratiques pour que les développeurs de jeux fonctionnent efficacement avec la fonctionnalité de sécurité UAC (User Account Control) introduite dans Windows Vista.

• Vue d’ensemble du contrôle de compte d’utilisateur
• comptes d’utilisateur dans Windows Vista
• l’accès aux fichiers en tant qu' utilisateur standard
• 'accès au Registre en tant qu' utilisateur standard
• d’élévation de privilèges
• implications UAC avec CreateProcess()
• définition du niveau d’exécution dans le manifeste de l’application
• incorporer un manifeste dans Visual Studio
• compatibilité UAC avec les jeux plus anciens
• scénarios et manifestes hérités
• Conclusion
• autres de lecture

Vue d’ensemble du contrôle de compte d’utilisateur

Le contrôle de compte d’utilisateur (UAC), introduit dans Windows Vista, est une fonctionnalité de sécurité conçue pour empêcher les attaquants malveillants d’utiliser des faiblesses ou des bogues trouvés dans des applications largement utilisées pour modifier le système d’exploitation ou d’autres programmes installés. Pour ce faire, exécutez la grande majorité des programmes et processus en tant qu’utilisateur standard (également appelé utilisateur limité, utilisateur restreint ou utilisateur Least-Privileged) même si le compte de l’utilisateur actuel possède des informations d’identification administratives. Un processus avec des privilèges utilisateur standard a de nombreuses restrictions inhérentes qui l’empêchent d’apporter des modifications à l’échelle du système.

L’UAC est également responsable de l’élévation de privilèges d’un processus à l’aide d’un schéma d’authentification basé sur un dialogue lancé lors de l’exécution de certains processus désignés comme nécessitant des privilèges administratifs. L’élévation de privilèges permet aux administrateurs d’exécuter la majorité de leurs applications au niveau de privilège sécurisé (identique à tout autre utilisateur standard), mais également d’autoriser les processus et les opérations qui nécessitent des privilèges d’administration. L’UAC prend en charge l’authentification sur l’épaule afin qu’un administrateur puisse accorder des privilèges élevés à un programme alors qu’un utilisateur standard est actuellement connecté au système.

La fonctionnalité UAC est activée par défaut. Bien qu’il soit possible pour un administrateur de désactiver l’UAC à l’échelle du système, cela a plusieurs conséquences négatives. Tout d’abord, cela affaiblit la sécurité de tous les comptes administratifs, car tous les processus seraient exécutés avec des informations d’identification administratives, même si la plupart des applications ne les nécessitent pas réellement. Avec l’UAC désactivé, une application utilisateur standard qui expose une vulnérabilité exploitable dans la sécurité peut potentiellement être utilisée pour voler des informations privées, installer des rootkits ou des logiciels espions, détruire l’intégrité du système ou héberger des attaques zombies sur d’autres systèmes. Alors que l’UAC est activée, l’exécution de la majorité des logiciels en tant qu’utilisateur standard limite considérablement les dommages potentiels causés par un tel bogue. Deuxièmement, la désactivation de l’UAC désactive la plupart des solutions de contournement pour la compatibilité des applications qui permettent aux utilisateurs standard d’exécuter correctement un large éventail d’applications. La désactivation de l’UAC ne doit jamais être recommandée comme solution de contournement de compatibilité.

Il est important de noter que les applications doivent s’efforcer d’utiliser uniquement les droits d’utilisateur standard si possible. Bien que les administrateurs puissent facilement élever les privilèges d’un processus, l’élévation nécessite toujours une interaction utilisateur et un accusé de réception chaque fois qu’une application est exécutée qui nécessite des informations d’identification administratives. Cette élévation doit également être effectuée au moment où le programme démarre, de sorte que l’exigence d’informations d’identification administratives même pour une seule opération nécessite l’exposition du système à un risque accru pour l’exécution entière de l’application. Les utilisateurs standard sans possibilité d’élever leurs privilèges sont également courants dans les paramètres familiaux et professionnels. « Exécuter en tant qu’administrateur » n’est pas une bonne solution de contournement pour la compatibilité, expose l’utilisateur et le système à un risque de sécurité accru et crée une frustration pour les utilisateurs dans de nombreuses situations.

Note

La fonctionnalité contrôle de compte d’utilisateur introduite dans Windows Vista est également présente dans Windows 7. Bien que l’expérience utilisateur travaillant avec les différentes fonctionnalités système ait été améliorée par rapport au contrôle de compte d’utilisateur, l’impact sur les applications est essentiellement le même. Toutes les recommandations de Windows Vista de cet article s’appliquent également à Windows 7. Pour plus d’informations sur les modifications apportées à l’interface utilisateur UAC pour Windows 7, consultez Interface utilisateur - Mises à jour de la boîte de dialogue Contrôle de compte d’utilisateur.

Comptes d’utilisateur dans Windows Vista

Windows Vista classe chaque utilisateur en deux types de comptes d’utilisateur : les administrateurs et les utilisateurs standard.

Un compte d’utilisateur standard est similaire à un compte d’utilisateur limité dans Windows XP. Comme dans Windows XP, un utilisateur standard ne peut pas écrire dans le dossier Program Files, ne peut pas écrire dans la partie HKEY_LOCAL_MACHINE du Registre et ne peut pas effectuer de tâches qui modifient le système, telles que l’installation d’un pilote en mode noyau ou l’accès aux espaces de processus au niveau du système.

Le compte Administrateur a considérablement changé depuis la publication de Windows XP. Auparavant, tous les processus lancés par un membre du groupe Administrateurs recevaient des privilèges d’administration. Avec L’UAC activé, tous les processus s’exécutent avec des privilèges utilisateur standard, sauf si spécifiquement élevés par un administrateur. Cette différence rend les comptes du groupe Administrateurs plus sécurisés en réduisant le risque de sécurité posé par les bogues potentiels dans la plupart des programmes.

Il est important que toutes les applications, en particulier les jeux, fonctionnent efficacement et de manière responsable lorsqu’elles s’exécutent en tant que processus utilisateur standard. Toutes les opérations qui nécessitent des privilèges d’administration doivent être effectuées au moment de l’installation ou par des programmes auxiliaires qui demandent explicitement des informations d’identification administratives. Bien que l’élévation de privilèges soit assez triviale pour un membre du groupe Administrateurs, les utilisateurs standard doivent différer à une personne disposant d’informations d’identification administratives pour entrer physiquement son mot de passe pour élever les privilèges. Étant donné que les comptes protégés par les contrôles parental doivent être des utilisateurs standard, il s’agit d’une situation très courante pour les joueurs qui utilisent Windows Vista.

Si votre jeu fonctionne déjà sur Windows XP avec des comptes d’utilisateur limités, le passage au contrôle de compte d’utilisateur sur Windows Vista doit être très facile. La majorité de ces applications fonctionnent as-is, bien que l’ajout d’un manifeste d’application soit fortement recommandé. (Les manifestes sont décrits plus loin dans cette rubrique dans Définition du niveau d’exécution dans le manifeste d’application.)

Accès aux fichiers en tant qu’utilisateur standard

L’aspect de votre jeu le plus affecté par les restrictions utilisateur standard est l’organisation du système de fichiers et l’accessibilité. Vous ne devez jamais supposer que votre jeu peut écrire des fichiers dans le dossier où votre jeu est installé. Dans Windows Vista, par exemple, les privilèges d’un utilisateur doivent être élevés par le système d’exploitation avant qu’une application puisse écrire dans le dossier Program Files. Pour éviter cela, vous devez classer vos fichiers de données de jeu par étendue et accessibilité, et utiliser la fonction SHGetFolderPath, ainsi que les constantes CSIDL fournies par l’interpréteur de commandes Windows, pour générer les chemins d’accès de fichiers appropriés. Les constantes CSIDL correspondent aux dossiers connus dans le système de fichiers que le système d’exploitation utilise et promeut pour partitionner des fichiers globaux et spécifiques à l’utilisateur.

La tentative de création ou d’écriture d’un fichier ou d’un répertoire sous un dossier qui n’accorde pas l’autorisation d’écriture au processus échoue sous Windows Vista si l’application ne dispose pas de privilèges d’administration. Si votre exécutable de jeu 32 bits s’exécute en mode hérité, car il n’a pas déclaré de niveau d’exécution demandé, ses opérations d’écriture réussissent, mais elles seront soumises à la virtualisation, comme décrit dans la section « Compatibilité UAC avec les jeux plus anciens » plus loin dans cet article.

Tableau 1. Dossiers connus

Nom CSIDL	Chemin d’accès classique (Windows Vista)	Droits d’utilisateur standard	Droits d’administrateur	Étendue d’accès	Description	Exemples
CSIDL_PERSONAL	C :\Users\user name\Documents	Lecture/écriture	Lecture/écriture	Per-User	Les fichiers de jeu spécifiques à l’utilisateur qui sont lus et modifiés et peuvent être manipulés en dehors du contexte de jeu.	Captures d’écran. Fichiers de jeu enregistrés avec une association d’extension de fichier.
CSIDL_LOCAL_APPDATA	C :\Users\user name\AppData\Local	Lecture/écriture	Lecture/écriture	Per-User	Les fichiers de jeu spécifiques à l’utilisateur qui sont lus et modifiés et qui sont utilisés uniquement dans le contexte du jeu.	Fichiers de cache de jeu. Configurations du lecteur.
CSIDL_COMMON_APPDATA	C :\ProgramData	Lecture/écriture si le propriétaire	Lecture/écriture	Tous les utilisateurs	Fichiers de jeu qui peuvent être créés par un utilisateur et lus par tous les utilisateurs. L’accès en écriture est accordé uniquement au créateur du fichier (propriétaire).	Profils utilisateur
CSIDL_PROGRAM_FILES	C :\Program Files ou C :\Program Files (x86)	Lecture seule	Lecture/écriture	Tous les utilisateurs	Fichiers de jeu statiques écrits par le programme d’installation du jeu lus par tous les utilisateurs.	Ressources de jeu, telles que des matériaux et des maillages.

Votre jeu est généralement installé dans un dossier sous le dossier représenté par la constante CSIDL_PROGRAM_FILES. Toutefois, ce n’est pas toujours le cas. Vous devez plutôt utiliser un chemin relatif à partir de votre fichier exécutable lors de la génération de chaînes de chemin d’accès vers des fichiers ou répertoires situés sous votre dossier d’installation.

Vous devez également vous abstenir d’hypothèses codées en dur sur les chemins d’accès de dossiers connus. Par exemple, sur Windows XP Professional Édition 64 bits et Windows Vista x64, le chemin des fichiers de programme est C :\Program Files (x86) pour les programmes 32 bits et C :\Program Files pour les programmes 64 bits. Ces chemins connus sont modifiés à partir de Windows XP, et les utilisateurs peuvent reconfigurer l’emplacement de plusieurs de ces dossiers et même les localiser sur différents lecteurs. Utilisez donc toujours les constantes CSIDL pour éviter la confusion et les problèmes potentiels. Le programme d’installation de Windows comprend ces emplacements de dossiers connus et déplace les données lors de la mise à niveau du système d’exploitation à partir de Windows XP ; En revanche, l’utilisation d’emplacements non standard ou de chemins codés en dur peut échouer après une mise à niveau du système d’exploitation.

L’attention doit être accordée aux différences subtiles entre les dossiers spécifiques à l’utilisateur spécifiés par CSIDL_PERSONAL et CSIDL_LOCAL_APPDATA. La pratique recommandée pour sélectionner la constante CSIDL à utiliser pour écrire un fichier consiste à utiliser CSIDL_PERSONAL si l’utilisateur est censé interagir avec le fichier, par exemple double-cliquer dessus pour l’ouvrir dans un outil ou une application, et utiliser CSIDL_LOCAL_APPDATA pour d’autres fichiers. Les deux dossiers peuvent être exploités par votre application pour stocker et organiser des fichiers de données spécifiques à l’utilisateur, car il n’existe aucune différence dans leur étendue d’accès ou leur niveau de privilège. Veillez à créer des noms de chemins qui sont suffisamment uniques pour ne pas entrer en collision avec d’autres applications, mais suffisamment courts pour conserver le nombre de caractères dans le chemin d’accès complet inférieur à la valeur de MAX_PATH, 260.

Le code suivant fournit un exemple d’écriture d’un fichier dans un dossier connu :

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

Accès au Registre en tant qu’utilisateur standard

L’accès au Registre par un utilisateur standard est limité de la même manière que le système de fichiers. Un utilisateur standard est autorisé à accéder en lecture à toutes les clés du Registre ; Toutefois, l’accès en écriture est accordé uniquement à la sous-arborescence HKEY_CURRENT_USER (HKCU), qui est mappée en interne à la sous-clé spécifique à l’utilisateur HKEY_USERS\Security ID (SID) de l’utilisateur actuel. Une application qui doit écrire dans n’importe quel emplacement de Registre autre que HKEY_CURRENT_USER nécessite des privilèges d’administration.

Si l’application 32 bits ne contient pas de niveau d’exécution demandé dans son manifeste, toutes les écritures dans HKEY_LOCAL_MACHINE\Software sont virtualisées, tandis que les écritures dans d’autres emplacements en dehors de HKEY_CURRENT_USER échouent.

Le stockage de données persistantes dans le Registre, comme la configuration d’un utilisateur, n’est pas recommandé. La méthode préférée de stockage des données persistantes à partir de votre jeu consiste à écrire les données dans le système de fichiers en appelant SHGetFolderPath et pour obtenir la valeur d’une constante CSIDL, décrite dans la section précédente.

Élévation de privilèges

Dans Windows Vista, toute application qui requiert des privilèges d’administration doit déclarer une demande de niveau d’exécution administratif dans son manifeste (décrite dans la section suivante, Définition du niveau d’exécution dans le manifeste de l’application).

L’élévation, telle qu’elle est connue, est la procédure pilotée par l’UAC pour promouvoir un processus vers un processus administratif. Les privilèges d’un processus ne peuvent être élevés qu’au moment de la création. Une fois créé, un processus ne sera jamais promu à un niveau de privilège supérieur. Pour cette raison. les opérations qui nécessitent des informations d’identification administratives doivent être isolées pour séparer les programmes d’installation et d’autres programmes auxiliaires.

Lors de l’exécution d’un programme, UAC inspecte le niveau d’exécution demandé dans le manifeste et, si des privilèges élevés sont requis, invite l’utilisateur actuel avec l’une des deux boîtes de dialogue standard : une pour un utilisateur standard et une pour un administrateur.

Si l’utilisateur actuel est un utilisateur standard, L’UAC invite l’utilisateur à entrer les informations d’identification d’un administrateur avant d’autoriser l’exécution du programme.

Figure 1. Demander à un utilisateur standard d’entrer des informations d’identification pour un compte d’administration

Si l’utilisateur actuel est administrateur, L’UAC invite l’utilisateur à demander l’autorisation avant d’autoriser l’exécution du programme.

Figure 2. Demander à un administrateur d’autoriser les modifications apportées à l’ordinateur

L’application reçoit uniquement des privilèges d’administration si un utilisateur standard fournit les informations d’identification administratives appropriées ou qu’un utilisateur administratif fournit un accusé de réception ; Toute autre chose entraîne l’arrêt de l’application.

Il est important de noter qu’un processus avec des privilèges élevés s’exécute en tant qu’utilisateur administratif qui a entré des informations d’identification dans l’invite UAC plutôt que comme utilisateur standard actuellement connecté. Ceci est similaire à RunAs dans Windows XP, le processus avec élévation de privilèges obtient le dossier et les clés de Registre de l’administrateur lors de l’accès aux données par utilisateur, et tous les programmes lancés par le processus avec élévation de privilèges héritent également des droits d’administration et des emplacements de compte d’utilisateur. Pour les administrateurs qui sont invités à confirmer l’accusé de réception (Continuer ou Annuler), ces emplacements correspondent aux emplacements de l’utilisateur. En général, toutefois, les processus qui nécessitent une élévation ne doivent pas fonctionner sur les données par utilisateur. Notez que cela peut affecter considérablement le fonctionnement de votre programme d’installation ! Si le programme d’installation, exécuté en tant qu’administrateur, écrit dans HKCU ou dans le profil d’un utilisateur, il peut très bien écrire à l’emplacement incorrect. Envisagez de créer ces valeurs par utilisateur lors de la première exécution du jeu.

Implications UAC avec CreateProcess()

Le mécanisme d’élévation UAC ne sera pas appelé à partir d’un appel à la fonction Win32 CreateProcess() pour démarrer un exécutable configuré pour exiger un niveau d’exécution supérieur au processus actuel. Par conséquent, l’appel à CreateProcess() échoue avec GetLastError() retournant ERROR_ELEVATION_REQUIRED. CreateProcess() réussit uniquement lorsque le niveau d’exécution de l’appelé est égal ou inférieur à celui de l’appelant. Un processus non élevé qui doit générer des processus élevés doit le faire à l’aide de la fonction ShellExecute(), ce qui entraîne le déclenchement du mécanisme d’élévation UAC par le biais de l’interpréteur de commandes.

Définition du niveau d’exécution dans le manifeste de l’application

Vous déclarez le niveau d’exécution demandé de votre jeu en ajoutant une extension au manifeste de l’application. Le code XML suivant montre la configuration minimale requise pour définir le niveau d’exécution d’une application :

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

Dans le code précédent, le système d’exploitation est informé que le jeu nécessite uniquement des privilèges utilisateur standard par la balise suivante :

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

En définissant explicitement requestedExecutionLevel sur « asInvoker », cet exemple affirme au système d’exploitation que le jeu se comporte correctement sans privilèges administratifs. Par conséquent, L’UAC désactive la virtualisation et exécute le jeu avec les mêmes privilèges que l’appelant, qui est généralement des privilèges utilisateur standard, car l’Explorateur Windows s’exécute en tant qu’utilisateur standard.

Le système d’exploitation peut être informé d’un jeu nécessite une élévation des privilèges d’administration en remplaçant « asInvoker » par « requireAdministrator », pour créer la balise suivante :

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

Avec cette configuration, le système d’exploitation invite l’utilisateur actuel à utiliser l’une des boîtes de dialogue d’élévation UAC standard chaque fois que le jeu est exécuté. Il est fortement recommandé qu’aucun jeu ne nécessite des privilèges d’administrateur à exécuter, car non seulement ce dialogue devient rapidement ennuyeux, mais il rend également le jeu incompatible avec les contrôles parental. Réfléchissez très attentivement avant d’ajouter cette exigence à n’importe quel exécutable.

Une idée fausse courante est que l’ajout d’un manifeste qui définit requestedExecutionLevel à « requireAdministrator » contourne la nécessité d’une invite d’élévation. Ce n’est pas vrai. Il empêche simplement le système d’exploitation de deviner si votre application d’installation ou de mise à jour a besoin de privilèges d’administration. L’utilisateur est toujours invité à autoriser l’élévation.

Windows vérifie la signature d’une application marquée pour élévation avant d’afficher l’invite UAC. Un fichier exécutable volumineux marqué pour l’élévation prend plus de temps à vérifier qu’un petit exécutable et plus long qu’un exécutable marqué comme « asInvoker ». Les exécutables d’installation qui sont auto-extraits doivent donc être marqués comme « asInvoker », et toute partie qui doit être marquée comme « requireAdministrator » doit être placée dans un exécutable d’assistance distinct.

L’attribut uiAccess, illustré dans les exemples précédents, doit toujours être FALSE pour les jeux. Cet attribut spécifie si les clients UI Automation ont accès à l’interface utilisateur système protégée et qu’ils ont des implications de sécurité particulières si la valeur TRUE est définie.

Incorporation d’un manifeste dans Visual Studio

La prise en charge du manifeste a été ajoutée pour la première fois à Visual Studio à partir de VS2005. Par défaut, un exécutable intégré à Visual Studio 2005 (ou version ultérieure) aura un manifeste généré automatiquement dans celui-ci dans le cadre du processus de génération. Le contenu du manifeste généré automatiquement dépend de certaines configurations de projet que vous spécifiez dans la boîte de dialogue propriétés du projet.

Le manifeste généré automatiquement par Visual Studio 2005 ne contient pas de bloc <trustInfo>, car il n’existe aucun moyen de configurer le niveau d’exécution UAC dans les propriétés du projet. La méthode recommandée pour ajouter ces informations consiste à laisser VS2005 fusionner un manifeste défini par l’utilisateur contenant le bloc <trustInfo> avec le manifeste généré automatiquement. C’est aussi simple que d’ajouter un fichier *.manifest à votre solution qui contient le code XML répertorié dans la section précédente. Lorsque Visual Studio rencontre un fichier .manifest dans votre solution, il appelle automatiquement l’outil manifeste (mt.exe) pour fusionner les fichiers .manifest avec le fichier généré automatiquement.

Note

Il existe un bogue dans l’outil manifeste (mt.exe) fourni par Visual Studio 2005 qui entraîne un manifeste fusionné et incorporé qui peut entraîner des problèmes lorsque l’exécutable est exécuté sur Windows XP avant SP3. Le bogue est le résultat de la façon dont l’outil redéfinit l’espace de noms par défaut lors de la déclaration du bloc <trustInfo>. Heureusement, il est facile de contourner entièrement le problème en déclarant explicitement un espace de noms différent dans le bloc <trustInfo> et en définissant les nœuds enfants dans le nouvel espace de noms. Le code XML fourni dans la section précédente illustre ce correctif.

Une mise en garde lors de l’utilisation de l’outil mt.exe inclus dans Visual Studio 2005 est qu’il génère un avertissement lors du traitement du bloc <trustInfo>, car l’outil ne contient pas de schéma mis à jour pour valider le code XML. Pour remédier à cet avertissement, il est recommandé de remplacer tous les fichiers mt.exe sous le répertoire d’installation de Visual Studio 2005 (il existe plusieurs instances) par l'mt.exe fournie dans le dernier Kit de développement logiciel (SDK) Windows.

À compter de Visual Studio 2008, vous pouvez désormais spécifier le niveau d’exécution d’une application à partir de la boîte de dialogue propriétés du projet (Figure 3) ou à l’aide de l’indicateur de l’éditeur de liens /MANIFESTUAC. Si vous définissez ces options, Visual Studio 2008 génère et incorpore automatiquement un manifeste avec le bloc <trustInfo approprié> dans l’exécutable.

Figure 3. Définition du niveau d’exécution dans Visual Studio 2008

L’incorporation d’un manifeste dans des versions antérieures de Visual Studio sans prise en charge de manifeste est toujours possible, mais nécessite davantage de travail auprès du développeur. Pour obtenir un exemple sur la façon de procéder, examinez le projet Visual Studio 2003 inclus dans n’importe quel exemple du Kit de développement logiciel (SDK) DirectX avant la version de mars 2008.

Compatibilité UAC avec les jeux plus anciens

Si votre jeu semble enregistrer et charger un fichier correctement dans le répertoire Program Files, mais aucune preuve du fichier iOn Windows Vista, toute application 32 bits qui ne contient pas de niveau d’exécution demandé dans son manifeste est considérée comme une application héritée. Avant Windows Vista, la plupart des applications étaient généralement exécutées par des utilisateurs disposant de privilèges d’administration. Par conséquent, ces applications pouvaient lire et écrire librement des fichiers système et des clés de Registre, et de nombreux développeurs n’ont pas apporté les modifications nécessaires pour fonctionner correctement sur des comptes d’utilisateur limités sur Windows XP. Toutefois, sur Windows Vista, ces mêmes applications échouent désormais en raison de privilèges d’accès insuffisants sous le nouveau modèle de sécurité, qui applique l’exécution d’utilisateurs standard pour les applications héritées. Pour atténuer l’impact de cette opération, la virtualisation a également été ajoutée à Windows Vista. La virtualisation maintient des milliers d’applications héritées qui fonctionnent bien sur Windows Vista sans exiger que ces applications aient des privilèges élevés à tout moment simplement pour réussir à quelques opérations mineures. est trouvé, les chances que votre jeu s’exécute en mode hérité et a été soumis à la virtualisation.

La virtualisation affecte le système de fichiers et le Registre en redirigeant les écritures sensibles au système (et les opérations de registre suivantes) vers un emplacement par utilisateur au sein du profil de l’utilisateur actuel. Par exemple, si une application tente d’écrire dans le fichier suivant :

C :\\Program Files\\Nom de la société\\Title\\config.ini

l’écriture est automatiquement redirigée vers :

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

De même, si une application tente d’écrire une valeur de Registre comme suit :

HKEY\_LOCAL\_MACHINE\\Software\\Nom de la société\\Title

elle sera redirigée vers :

HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Nom de la société\\Title

Les fichiers et les clés de Registre affectés par la virtualisation sont accessibles uniquement par les opérations de fichier et de Registre à partir d’applications virtualisées qui s’exécutent en tant qu’utilisateur actuel.

Toutefois, il existe de nombreuses restrictions à la virtualisation. L’une est que les applications 64 bits ne sont jamais exécutées en mode hérité pour les opérations de compatibilité soumises à la virtualisation dans les applications 32 bits échouent simplement en 64 bits. En outre, si une application héritée s’exécutant en tant qu’utilisateur standard tente d’écrire n’importe quel type de fichier exécutable dans un emplacement nécessitant des informations d’identification administratives, la virtualisation ne se produit pas et l’écriture échoue.

Figure 4. Processus de virtualisation

Lorsqu’une application héritée tente d’effectuer une opération de lecture sur des emplacements sensibles au système de fichiers ou au Registre, les emplacements virtuels sont d’abord recherchés. Si la clé de fichier ou de Registre est introuvable, le système d’exploitation accède aux emplacements système par défaut.

La virtualisation sera supprimée des versions ultérieures de Windows afin qu’il soit important de ne pas compter sur cette fonctionnalité. Au lieu de cela, vous devez configurer explicitement votre manifeste d’application pour les privilèges d’utilisateur ou d’administration standard, car cela désactive la virtualisation. La virtualisation n’est pas non plus évidente pour les utilisateurs finaux. Même si la virtualisation peut permettre à votre application de s’exécuter, elle peut générer des appels de support et rendre difficile la prise en charge de ces clients.

Notez que si L’UAC est désactivé, la virtualisation est également désactivée. Si la virtualisation est désactivée, les comptes d’utilisateur standard se comportent exactement comme des comptes d’utilisateur limités dans Windows XP, et les applications héritées peuvent ne pas fonctionner correctement pour les utilisateurs standard qui auraient autrement réussi en raison de la virtualisation.

Scénarios et manifestes hérités

Pour la majorité des scénarios d’utilisation, il suffit de marquer l'.exe avec les éléments de manifeste UAC corrects et de s’assurer que l’application fonctionne correctement en tant qu’utilisateur standard pour une excellente compatibilité UAC. La plupart des joueurs exécutent Windows Vista ou Windows 7 avec le contrôle de compte d’utilisateur activé. Pour Windows XP et les utilisateurs sur Windows Vista ou Windows7 avec la fonctionnalité Contrôle de compte d’utilisateur désactivée, ils s’exécutent généralement à l’aide de comptes d’administrateur. Bien qu’il s’agit d’un mode d’opération moins sécurisé, il ne rencontrera généralement aucun problème de compatibilité supplémentaire, bien que comme indiqué ci-dessus, la désactivation de l’UAC désactive également la virtualisation.

Il existe un cas particulier à noter lorsque le programme est marqué comme « requireAdministrator » dans le manifeste UAC. Sur Windows XP et sur Windows Vista ou Windows 7 avec contrôle de compte d’utilisateur désactivé, les éléments manifeste UAC sont ignorés par le système. Dans ce cas, les utilisateurs disposant de comptes d’administrateur exécutent toujours tous les programmes avec des droits d’administrateur complets, et ces programmes fonctionnent donc comme prévu. Les utilisateurs restreints windows XP et les utilisateurs standard s’exécutant sur Windows Vista ou Windows 7, toutefois, exécutent toujours ces programmes avec des droits restreints et toutes les opérations au niveau de l’administrateur échouent. Il est donc recommandé que les programmes marqués comme « requiretAdministrator » appellent IsUserAnAdmin au démarrage et affichent un message d’erreur irrécupérable s’il retourne FALSE. Pour le scénario majoritaire ci-dessus, cela réussit toujours, mais fournit une meilleure expérience utilisateur et un message d’erreur clair pour cette situation rare.

Conclusion

En tant que développeur de jeux ciblant l’environnement multi-utilisateur Windows, il est impératif de concevoir votre jeu pour fonctionner efficacement et de manière responsable. Le fichier exécutable principal de votre jeu ne doit pas dépendre des privilèges d’administration. Cela empêche non seulement l’apparence des invites d’élévation chaque fois que votre jeu est exécuté, ce qui peut avoir un impact négatif sur l’expérience utilisateur globale, mais il permet également à votre jeu de tirer parti d’autres fonctionnalités qui nécessitent l’exécution avec des privilèges utilisateur standard, tels que les contrôles parental.

Les applications qui sont correctement conçues pour fonctionner comme avec les informations d’identification d’un utilisateur standard (ou utilisateur limité) sous les versions précédentes de Windows ne seront pas affectées par l’UAC qu’elles s’exécuteront sans élévation. Toutefois, ils doivent inclure un manifeste avec leur niveau d’exécution demandé défini sur « asInvoker » pour se conformer aux normes d’application pour Vista.

Lecture plus poussée

Pour obtenir de l’aide sur la conception d’applications pour Windows Vista conformes au contrôle de compte d’utilisateur, téléchargez le livre blanc suivant : Exigences de développement d’applications Windows Vista pour la compatibilité du contrôle de compte d’utilisateur.

Ce livre blanc fournit des étapes détaillées sur le processus de conception, ainsi que des exemples de code, des exigences et des meilleures pratiques. Ce document détaille également les mises à jour techniques et les modifications apportées à l’expérience utilisateur dans Windows Vista.

Pour plus d’informations sur le contrôle de compte d’utilisateur, visitez Windows Vista : Contrôle de compte d’utilisateur sur Microsoft TechNet.

Une autre ressource utile est l’article Teach Your Apps To Play Nicely with Windows Vista User Account Control, from MSDN Magazine, janvier 2007. Cet article traite des problèmes généraux de compatibilité des applications, ainsi que des avantages et des problèmes liés à l’utilisation de packages Windows Installer sur Windows Vista.

Pour plus d’informations sur le bogue et le correctif pour mt.exe, l’outil utilisé par Visual Studio 2005 pour fusionner et incorporer automatiquement un manifeste dans un exécutable, consultez Exploration des manifestes partie 2 : Espaces de noms par défaut et manifestes UAC dans Windows Vista sur le blog de Chris Jackson sur MSDN.