Condividi tramite

Controllo dell'account utente per sviluppatori di giochi

  • Articolo

Questo articolo descrive le linee guida e le procedure consigliate per gli sviluppatori di giochi per lavorare in modo efficace con la funzionalità di sicurezza Controllo account utente introdotta in Windows Vista.

Panoramica del controllo dell'account utente

Controllo dell'account utente (UAC), introdotto in Windows Vista, è una funzionalità di sicurezza progettata per impedire a utenti malintenzionati di usare punti deboli o bug rilevati in applicazioni ampiamente usate per modificare il sistema operativo o altri programmi installati. Questa operazione viene eseguita eseguendo la maggior parte dei programmi e dei processi come utente standard (noto anche come utente limitato, utente con restrizioni o utente con privilegi minimi) anche se l'account dell'utente corrente dispone di credenziali amministrative. Un processo con privilegi utente standard presenta molte restrizioni intrinseche che impediscono di apportare modifiche a livello di sistema.

Controllo dell'account utente è inoltre responsabile dell'elevazione dei privilegi di un processo tramite un schema di autenticazione basato su dialoghi avviato all'esecuzione di determinati processi designati come privilegi amministrativi. L'elevazione dei privilegi consente agli amministratori di eseguire la maggior parte delle applicazioni a livello di privilegio sicuro (uguale a qualsiasi altro utente standard), ma consente anche processi e operazioni che richiedono privilegi amministrativi. Controllo dell'account utente supporta l'autenticazione over-the-shoulder in modo che un amministratore possa concedere privilegi elevati a un programma mentre un utente standard è attualmente connesso al sistema.

La funzionalità controllo dell'account utente è abilitata per impostazione predefinita. Anche se è possibile che un amministratore disabiliti il controllo dell'account utente a livello di sistema, in questo modo ha una serie di ramificazioni negative. In primo luogo, ciò indeboli la sicurezza di tutti gli account amministrativi, in quanto tutti i processi vengono eseguiti con credenziali amministrative, anche quando la maggior parte delle applicazioni non li richiede effettivamente. Con controllo dell'account utente disabilitato, un'applicazione utente standard che espone una vulnerabilità sfruttabile nella sicurezza può potenzialmente essere usata per rubare informazioni private, installare rootkit o spyware, distruggere l'integrità del sistema o ospitare attacchi zombie su altri sistemi. Mentre con controllo dell'account utente abilitato, l'esecuzione della maggior parte del software come utente standard limita notevolmente il potenziale danno da tale bug. In secondo luogo, la disattivazione dell'interfaccia utente disabilita molte delle soluzioni alternative per la compatibilità delle applicazioni che consentono agli utenti standard reali di eseguire correttamente un'ampia gamma di applicazioni. La disabilitazione dell'interfaccia utente non deve mai essere consigliata come soluzione alternativa per la compatibilità.

È importante notare che le applicazioni devono cercare di usare solo i diritti utente standard, se possibile. Anche se gli amministratori possono elevare facilmente i privilegi di un processo, l'elevazione dei privilegi richiede comunque l'interazione dell'utente e l'acknowledgement ogni volta che un'applicazione viene eseguita che richiede credenziali amministrative. Questa elevazione deve essere eseguita anche al momento dell'avvio del programma, quindi la richiesta di credenziali amministrative anche per una singola operazione richiede l'esposizione del sistema a un rischio maggiore per l'intero tempo di esecuzione dell'applicazione. Gli utenti standard senza alcuna possibilità di elevare i propri privilegi sono comuni anche nelle impostazioni di famiglia e business. "RunAs Amministrazione istrator" non è una soluzione alternativa valida per la compatibilità, espone l'utente e il sistema a un rischio di sicurezza maggiore e crea frustrazione per gli utenti in molte situazioni.

Nota

La funzionalità Controllo account utente introdotta in Windows Vista è presente anche in Windows 7. Anche se l'esperienza utente che lavora con le varie funzionalità di sistema è stata migliorata rispetto al controllo dell'account utente, l'impatto sulle applicazioni è fondamentalmente lo stesso. Tutte le raccomandazioni di Windows Vista in questo articolo si applicano anche a Windows 7. Per informazioni dettagliate sulle modifiche apportate all'interfaccia utente per Windows 7, vedere Interfaccia utente - Finestra di dialogo controllo dell'account utente Aggiornamenti.

Account utente in Windows Vista

Windows Vista classifica ogni utente in due tipi di account utente: amministratori e utenti standard.

Un account utente standard è simile a un account utente limitato in Windows XP. Come in Windows XP, un utente standard non può scrivere nella cartella Programmi, non può scrivere nella parte HKEY_LOCAL_MACHINE del Registro di sistema e non può eseguire attività che modificano il sistema, ad esempio l'installazione di un driver in modalità kernel o l'accesso agli spazi di processo a livello di sistema.

L'account Amministrazione istrator è cambiato significativamente dopo il rilascio di Windows XP. In precedenza, a tutti i processi avviati da un membro del gruppo Amministrazione istrators venivano assegnati privilegi amministrativi. Con controllo dell'account utente abilitato, tutti i processi vengono eseguiti con privilegi utente standard, a meno che non venga specificatamente elevato da un amministratore. Questa differenza rende più sicuri gli account nel gruppo Amministrazione istrators riducendo il rischio di sicurezza rappresentato da potenziali bug nella maggior parte dei programmi.

È importante che tutte le applicazioni, in particolare i giochi, funzionino in modo efficace e responsabile quando vengono eseguite come processo utente standard. Tutte le operazioni che richiedono privilegi amministrativi devono essere eseguite in fase di installazione o da programmi ausiliari che richiedono in modo esplicito credenziali amministrative. Anche se l'elevazione dei privilegi è piuttosto semplice per un membro del gruppo Amministrazione istrators, gli utenti standard devono rinviare a un utente con credenziali amministrative per immettere fisicamente la password per elevare i privilegi. Poiché gli account protetti dai controlli genitori devono essere utenti standard, questa sarà una situazione molto comune per i giocatori che usano Windows Vista.

Se il gioco sta già lavorando su Windows XP con account utente limitati, il passaggio a Controllo account utente in Windows Vista dovrebbe essere molto semplice. La maggior parte di queste applicazioni funzionerà così come è, anche se l'aggiunta di un manifesto dell'applicazione è altamente consigliata. I manifesti sono descritti più avanti in questo argomento in Impostazione del livello di esecuzione nel manifesto dell'applicazione.

Accesso ai file come utente standard

L'aspetto del gioco più interessato dalle restrizioni utente standard è l'organizzazione e l'accessibilità del file system. Non dovresti mai presupporre che il tuo gioco possa scrivere file nella cartella in cui è installato il gioco. In Windows Vista, ad esempio, i privilegi di un utente devono essere elevati dal sistema operativo prima che un'applicazione possa scrivere nella cartella Programmi. Per evitare questo problema, è necessario classificare i file di dati del gioco in base all'ambito e all'accessibilità e usare la funzione SHGetFolderPath , insieme alle costanti CSIDL fornite dalla shell di Windows, per generare i percorsi di file appropriati. Le costanti CSIDL corrispondono alle cartelle note nel file system usato dal sistema operativo e promuove la partizione di file globali e specifici dell'utente.

Il tentativo di creare o scrivere un file o una directory in una cartella che non concede l'autorizzazione di scrittura al processo avrà esito negativo in Windows Vista se l'applicazione non dispone di privilegi amministrativi. Se il file eseguibile del gioco a 32 bit è in esecuzione in modalità legacy, perché non ha dichiarato un livello di esecuzione richiesto, le operazioni di scrittura avranno esito positivo, ma saranno sottoposte alla virtualizzazione come descritto nella sezione "Compatibilità UAC con giochi meno recenti" più avanti in questo articolo.

Tabella 1. Cartelle note

Nome CSIDL Percorso tipico (Windows Vista) Diritti utente standard Diritti di Amministrazione istrator Ambito di accesso Descrizione Esempi
CSIDL_PERSONAL C:\Users\nome utente\Documenti Leggi/Scrivi Lettura/Scrittura Per utente File di gioco specifici dell'utente che vengono letti e modificati e possono essere modificati all'esterno del contesto del gioco. Schermate. File di gioco salvati con un'associazione di estensioni di file.
CSIDL_LOCAL_APPDATA C:\Users\user name\AppData\Local Leggi/Scrivi Lettura/Scrittura Per utente File di gioco specifici dell'utente che vengono letti e modificati e sono di uso solo all'interno del contesto del gioco. File della cache dei giochi. Configurazioni del lettore.
CSIDL_COMMON_APPDATA C:\ProgramData Proprietà di lettura/scrittura se proprietario Lettura/Scrittura Tutti gli utenti File di gioco che possono essere creati da un utente e letti da tutti gli utenti. L'accesso in scrittura viene concesso solo all'autore del file (proprietario). Profili utente
CSIDL_PROGRAM_FILES C:\Programmi
o
C:\Programmi (x86)
Sola lettura Leggi/Scrivi Tutti gli utenti File di gioco statici scritti dal programma di installazione del gioco che vengono letti da tutti gli utenti. Asset di gioco, ad esempio materiali e mesh.

Il gioco verrà in genere installato in una cartella nella cartella rappresentata dalla costante CSIDL_PROGRAM_FILES. Tuttavia, questo non è sempre il caso. È invece consigliabile usare un percorso relativo dal file eseguibile durante la generazione di stringhe di percorso in file o directory che si trovano nella cartella di installazione.

È anche consigliabile evitare presupposti hardcoded sui percorsi delle cartelle note. Ad esempio, in Windows XP Professional 64 bit Edition e Windows Vista x64, il percorso dei file di programma è C:\Programmi (x86) per programmi a 32 bit e C:\Programmi per programmi a 64 bit. Questi percorsi noti vengono modificati da Windows XP e gli utenti possono riconfigurare il percorso di molte di queste cartelle e persino individuarli in unità diverse. Quindi, usare sempre le costanti CSIDL per evitare confusione e potenziali problemi. Il programma di installazione di Windows comprende questi percorsi di cartelle noti e sposta i dati durante l'aggiornamento del sistema operativo da Windows XP; Al contrario, l'uso di percorsi non standard o percorsi hardcoded potrebbe non riuscire dopo un aggiornamento del sistema operativo.

È necessario prestare attenzione alle sottili differenze di usabilità tra le cartelle specifiche dell'utente specificate da CSIDL_PERSONAL e CSIDL_LOCAL_APPDATA. La procedura consigliata per la selezione della costante CSIDL da usare per la scrittura di un file consiste nell'usare CSIDL_PERSONAL se l'utente deve interagire con il file, ad esempio facendo doppio clic su di esso per aprirlo in uno strumento o in un'applicazione e per usare CSIDL_LOCAL_APPDATA per altri file. Entrambe le cartelle possono essere sfruttate dall'applicazione per archiviare e organizzare file di dati specifici dell'utente, in quanto non esiste alcuna differenza nell'ambito di accesso o nel livello di privilegio. Prestare attenzione a creare nomi di percorso univoci sufficienti per non trovarsi in conflitto con altre applicazioni, ma abbastanza breve per mantenere il numero di caratteri nel percorso completo meno del valore di MAX_PATH, 260.

Il codice seguente fornisce un esempio di come scrivere un file in una cartella nota:

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

Accesso al Registro di sistema come utente standard

L'accesso al Registro di sistema da parte di un utente standard è limitato in modo analogo al file system. Un utente standard è autorizzato ad accedere in lettura a tutte le chiavi nel Registro di sistema; Tuttavia, l'accesso in scrittura viene concesso solo al sottoalbero HKEY_CURRENT_Uedizione Standard R (HKCU), mappato internamente alla sottochiave specifica dell'utente HKEY_Uedizione Standard RS\Security ID (SID) dell'utente corrente. Un'applicazione che deve scrivere in qualsiasi posizione del Registro di sistema diversa da HKEY_CURRENT_Uedizione Standard R richiede privilegi amministrativi.

Se l'applicazione a 32 bit non contiene un livello di esecuzione richiesto nel relativo manifesto, tutte le scritture in HKEY_LOCAL_MACHINE\Software verranno virtualizzate, mentre le scritture in altre posizioni esterne a HKEY_CURRENT_Uedizione Standard R avranno esito negativo.

Non è consigliabile archiviare dati persistenti nel Registro di sistema, ad esempio la configurazione di un utente. Il metodo preferito per archiviare dati persistenti dal gioco consiste nel scrivere i dati nel file system chiamando SHGetFolderPath e per ottenere il valore di una costante CSIDL, descritta nella sezione precedente.

Elevazione dei privilegi

In Windows Vista, qualsiasi applicazione che richiede privilegi amministrativi deve dichiarare una richiesta per un livello di esecuzione amministrativa nel relativo manifesto (descritta nella sezione successiva, Impostazione del livello di esecuzione nel manifesto dell'applicazione).

L'elevazione dei privilegi, come noto, è la procedura guidata dal controllo dell'account utente per promuovere un processo a un processo amministrativo. I privilegi di un processo possono essere elevati solo in fase di creazione. Una volta creato, un processo non verrà mai promosso a un livello di privilegi più elevato. Per questo motivo. le operazioni che richiedono credenziali amministrative devono essere isolate per separare i programmi di installazione e altri programmi ausiliari.

Al momento dell'esecuzione di un programma, Controllo dell'account utente controlla il livello di esecuzione richiesto nel manifesto e, se sono necessari privilegi elevati, richiede all'utente corrente una delle due finestre di dialogo standard: una per un utente standard e una per un amministratore.

Se l'utente corrente è un utente standard, controllo dell'account utente richiede all'utente le credenziali di un amministratore prima di consentire l'esecuzione del programma.

Figura 1. Richiedere a un utente standard di immettere le credenziali per un account amministrativo

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

Se l'utente corrente è un amministratore, controllo dell'account utente richiede all'utente l'autorizzazione prima di consentire l'esecuzione del programma.

Figura 2. Richiedere a un Amministrazione istrator di autorizzare le modifiche al computer

prompt for an administrator to authorize changes to the computer

All'applicazione verranno concessi privilegi amministrativi solo se un utente standard fornisce le credenziali amministrative appropriate o un utente amministratore fornisce l'acknowledgement; qualsiasi altro elemento causerà l'interruzione dell'applicazione.

È importante notare che un processo con privilegi elevati viene eseguito come utente amministratore che ha immesso le credenziali nel prompt dell'account utente anziché come utente standard attualmente connesso. Questo è simile a RunAs in Windows XP il processo con privilegi elevati ottiene la cartella e le chiavi del Registro di sistema dell'amministratore quando accedono ai dati per utente e tutti i programmi che il processo con privilegi elevati avvia ereditano anche i diritti amministrativi e i percorsi dell'account utente. Per gli amministratori a cui viene richiesto di confermare (Continua o Annulla), queste posizioni corrispondono alle posizioni dell'utente corrente. In generale, tuttavia, i processi che richiedono l'elevazione dei privilegi non devono funzionare sui dati per utente. Si noti che questo può influire notevolmente sul funzionamento del programma di installazione. Se il programma di installazione, in esecuzione come amministratore, scrive in HKCU o nel profilo di un utente, potrebbe essere molto utile scrivere nella posizione errata. Prendere in considerazione la creazione di questi valori per utente alla prima esecuzione del gioco.

Implicazioni dell'interfaccia utente con CreateProcess()

Il meccanismo di elevazione dell'account utente non verrà richiamato da una chiamata alla funzione Win32 CreateProcess() per avviare un eseguibile configurato per richiedere un livello di esecuzione superiore rispetto al processo corrente. Di conseguenza, la chiamata a CreateProcess() avrà esito negativo con GetLastError() che restituisce ERROR_ELEVATION_REQUIRED. CreateProcess() avrà esito positivo solo quando il livello di esecuzione del chiamato è uguale o minore di quello del chiamante. Un processo non con privilegi elevati che deve generare processi con privilegi elevati deve farlo usando la funzione ShellExecute(), che causerà l'attivazione del meccanismo di elevazione del controllo dell'account utente tramite la shell.

Impostazione del livello di esecuzione nel manifesto dell'applicazione

Dichiari il livello di esecuzione richiesto del gioco aggiungendo un'estensione al manifesto dell'applicazione. Il codice XML seguente illustra la configurazione minima necessaria per impostare il livello di esecuzione per un'applicazione:

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

Nel codice precedente, il sistema operativo viene informato che il gioco richiede solo privilegi utente standard con il tag seguente:

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

Impostando in modo esplicito requestedExecutionLevel su "asInvoker", questo esempio afferma al sistema operativo che il gioco si comporta correttamente senza privilegi amministrativi. Di conseguenza, Controllo dell'account utente disabilita la virtualizzazione ed esegue il gioco con gli stessi privilegi dell'invoker, che in genere è i privilegi utente standard, poiché Esplora risorse viene eseguito come utente standard.

Il sistema operativo può essere informato che un gioco richiede l'elevazione dei privilegi amministrativi sostituendo "asInvoker" con "require Amministrazione istrator", per creare il tag seguente:

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

Con questa configurazione, il sistema operativo richiede all'utente corrente una delle finestre di dialogo di elevazione dell'account utente standard ogni volta che viene eseguito il gioco. Si consiglia vivamente che nessun gioco richieda privilegi di amministratore per l'esecuzione, perché non solo questo dialogo diventa rapidamente fastidioso, ma rende anche il gioco incompatibile con i controlli genitori. Considerare attentamente prima di aggiungere questo requisito a qualsiasi eseguibile.

Un errore comune è che l'aggiunta di un manifesto che imposta requestedExecutionLevel su "require Amministrazione istrator" ignora la necessità di una richiesta di elevazione dei privilegi. Risposta errata. Impedisce semplicemente al sistema operativo di indovinare se l'installazione o l'aggiornamento dell'applicazione richiede privilegi amministrativi. All'utente viene comunque richiesto di autorizzare l'elevazione dei privilegi.

Windows controlla la firma di qualsiasi applicazione contrassegnata per l'elevazione dei privilegi prima di visualizzare il prompt del controllo dell'account utente. Un file eseguibile di grandi dimensioni contrassegnato per l'elevazione richiede più tempo per il controllo rispetto a un file eseguibile di piccole dimensioni e più lungo di un eseguibile contrassegnato come "asInvoker". I file eseguibili di installazione autoestrati devono pertanto essere contrassegnati come "asInvoker" e qualsiasi parte che deve essere contrassegnata come "require Amministrazione istrator" deve essere inserita in un eseguibile helper separato.

L'attributo uiAccess, illustrato negli esempi precedenti, deve essere sempre FAL edizione Standard per i giochi. Questo attributo specifica se i client di automazione interfaccia utente hanno accesso all'interfaccia utente di sistema protetta e hanno implicazioni speciali sulla sicurezza se impostate su TRUE.

Incorporamento di un manifesto in Visual Studio

Il supporto del manifesto è stato aggiunto per la prima volta a Visual Studio a partire da VS2005. Per impostazione predefinita, un eseguibile compilato in Visual Studio 2005 (o versione successiva) avrà un manifesto generato automaticamente incorporato nel file come parte del processo di compilazione. Il contenuto del manifesto generato automaticamente dipende da determinate configurazioni di progetto specificate nella finestra di dialogo delle proprietà del progetto.

Il manifesto generato automaticamente da Visual Studio 2005 non conterrà un <blocco trustInfo> perché non è possibile configurare il livello di esecuzione dell'interfaccia utente nelle proprietà del progetto. Il modo migliore per aggiungere queste informazioni consiste nel consentire a VS2005 di unire un manifesto definito dall'utente contenente il <blocco trustInfo> con il manifesto generato automaticamente. Questo è semplice come aggiungere un file *.manifest alla soluzione che contiene il codice XML elencato nella sezione precedente. Quando Visual Studio rileva un file con estensione manifest nella soluzione, richiama automaticamente lo strumento manifesto (mt.exe) per unire i file con estensione manifest con quello generato automaticamente.

Nota

È presente un bug nello strumento manifesto (mt.exe) fornito da Visual Studio 2005 che genera un manifesto unito e incorporato che può causare problemi quando l'eseguibile viene eseguito in Windows XP prima di SP3. Il bug è il risultato della ridefinizione dello spazio dei nomi predefinito al momento della dichiarazione del <blocco trustInfo> . Fortunatamente, è facile ignorare completamente il problema dichiarando in modo esplicito uno spazio dei nomi diverso nel <blocco trustInfo> e definendo l'ambito dei nodi figlio al nuovo spazio dei nomi. Il codice XML fornito nella sezione precedente illustra questa correzione.

Un'avvertenza nell'uso dello strumento mt.exe incluso in Visual Studio 2005 è che genererà un avviso durante l'elaborazione del <blocco trustInfo> perché lo strumento non contiene uno schema aggiornato per convalidare il codice XML. Per risolvere questo avviso, è consigliabile sostituire tutti i file mt.exe nella directory di installazione di Visual Studio 2005 (ci sono più istanze) con il file mt.exe fornito nella versione più recente di Windows SDK.

A partire da Visual Studio 2008, è ora possibile specificare il livello di esecuzione di un'applicazione dalla finestra di dialogo delle proprietà del progetto (figura 3) o usando il flag del linker /MANIFESTUAC. Se si impostano queste opzioni, Visual Studio 2008 genera automaticamente e incorpora un manifesto con il blocco trustInfo> appropriato <nel file eseguibile.

Figura 3. Impostazione del livello di esecuzione in Visual Studio 2008

setting the execution level in visual studio 2008

L'incorporamento di un manifesto nelle versioni precedenti di Visual Studio senza supporto del manifesto è ancora possibile, ma richiede più lavoro da parte dello sviluppatore. Per un esempio su come eseguire questa operazione, esaminare il progetto di Visual Studio 2003 incluso in qualsiasi esempio in DirectX SDK prima della versione di marzo 2008.

Compatibilità di Controllo dell'account utente con giochi meno recenti

Se il gioco sembra salvare e caricare correttamente un file nella directory Programmi, ma nessuna prova del file iOn Windows Vista, qualsiasi applicazione a 32 bit che non contiene un livello di esecuzione richiesto nel manifesto viene considerata un'applicazione legacy. Prima di Windows Vista, la maggior parte delle applicazioni veniva in genere eseguita dagli utenti con privilegi amministrativi. Di conseguenza, queste applicazioni potevano leggere e scrivere liberamente file di sistema e chiavi del Registro di sistema e molti sviluppatori non apportavano le modifiche necessarie per funzionare correttamente in account utente limitati in Windows XP. Tuttavia, in Windows Vista, queste stesse applicazioni ora non riuscirebbero a causa di privilegi di accesso insufficienti nel nuovo modello di sicurezza, che impone l'esecuzione standard dell'utente per le applicazioni legacy. Per ridurre l'impatto di questo problema, la virtualizzazione è stata aggiunta anche a Windows Vista. La virtualizzazione continuerà a funzionare bene migliaia di applicazioni legacy in Windows Vista senza richiedere che tali applicazioni abbiano privilegi elevati in qualsiasi momento semplicemente per avere esito positivo in alcune operazioni secondarie. s trovato, le probabilità che il tuo gioco sia in esecuzione in modalità legacy ed è stato sottoposto alla virtualizzazione.

La virtualizzazione influisce sul file system e sul Registro di sistema reindirizzando le scritture sensibili al sistema (e le successive operazioni di file o registro) a una posizione per utente all'interno del profilo dell'utente corrente. Ad esempio, se un'applicazione tenta di scrivere nel file seguente:

C:\\Programmi\\Nome società\\Titolo\\config.ini

la scrittura viene reindirizzata automaticamente a:

C:\\Users\\nome utente\\AppData\\Local\\VirtualStore\\Programmi\\Nome società\\Titolo\\config.ini

Analogamente, se un'applicazione tenta di scrivere un valore del Registro di sistema simile al seguente:

HKEY\_LOCAL\_MACHINE\\Software\\Nome società\\Titolo

verrà invece reindirizzato a:

HKEY\_CURRENT\_Uedizione Standard R\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Company Name\\Title

I file e le chiavi del Registro di sistema interessati dalla virtualizzazione sono accessibili solo dalle operazioni di file e registro da applicazioni virtualizzate in esecuzione come utente corrente.

Tuttavia, esistono molte restrizioni per la virtualizzazione. Una è che le applicazioni a 64 bit non vengono mai eseguite in modalità legacy per le operazioni di compatibilità sottoposte alla virtualizzazione nelle applicazioni a 32 bit avranno solo esito negativo a 64 bit. Inoltre, se un'applicazione legacy in esecuzione come utente standard tenta di scrivere qualsiasi tipo di file eseguibile in un percorso che richiede credenziali amministrative, la virtualizzazione non verrà eseguita e la scrittura avrà esito negativo.

Figura 4. Processo di virtualizzazione

virtualization process

Quando un'applicazione legacy tenta un'operazione di lettura su percorsi sensibili al sistema nel file system o nel Registro di sistema, le posizioni virtuali vengono eseguite prima di tutto. Se il file o la chiave del Registro di sistema non viene trovato, il sistema operativo accede ai percorsi di sistema predefiniti.

La virtualizzazione verrà rimossa dalle versioni successive di Windows, quindi è importante non basarsi su questa funzionalità. È invece consigliabile configurare in modo esplicito il manifesto dell'applicazione per privilegi di amministratore o utente standard, in quanto la virtualizzazione verrà disabilitata. La virtualizzazione non è ovvia anche agli utenti finali, quindi anche se la virtualizzazione può consentire l'esecuzione dell'applicazione, può generare chiamate di supporto e rendere difficile la risoluzione dei problemi per questi clienti.

Si noti che se controllo dell'account utente è disabilitato, anche la virtualizzazione è disabilitata. Se la virtualizzazione è disabilitata, gli account utente standard si comportano esattamente come account utente limitati in Windows XP e le applicazioni legacy potrebbero non funzionare correttamente per gli utenti standard che altrimenti sarebbero riusciti a causa della virtualizzazione.

Scenari e manifesti legacy

Per la maggior parte degli scenari di utilizzo, è sufficiente contrassegnare il file exe con gli elementi del manifesto del controllo dell'account utente corretti e garantire che l'applicazione funzioni correttamente come utente standard è sufficiente per garantire un'eccellente compatibilità con controllo dell'account utente. La maggior parte dei giocatori esegue Windows Vista o Windows 7 con il controllo dell'account utente abilitato. Per gli utenti e Windows XP in Windows Vista o Windows7 con la funzionalità Controllo account utente disabilitata, vengono in genere eseguiti usando account amministratore. Anche se si tratta di una modalità di funzionamento meno sicura, in genere non si verificano problemi di compatibilità aggiuntivi, anche se come indicato in precedenza, la disabilitazione dell'interfaccia utente disabilita anche la virtualizzazione.

C'è un caso speciale che vale la pena notare quando il programma è contrassegnato come "require Amministrazione istrator" nel manifesto del controllo dell'account utente. In Windows XP e in Windows Vista o Windows 7 con Controllo account utente disabilitato, gli elementi manifesto dell'account utente vengono ignorati dal sistema. In questo caso, gli utenti con account amministratore eseguiranno sempre tutti i programmi con diritti di amministratore completi e pertanto questi programmi funzioneranno come previsto. Gli utenti con restrizioni di Windows XP e gli utenti standard in esecuzione in Windows Vista o Windows 7, tuttavia, eseguiranno sempre questi programmi con diritti limitati e tutte le operazioni a livello di amministratore avranno esito negativo. È pertanto consigliabile che i programmi contrassegnati come "requiret Amministrazione istrator" chiami IsUserAn Amministrazione all'avvio e visualizzino un messaggio di errore irreversibile se restituisce FAL edizione Standard. Per lo scenario di maggioranza precedente, questa operazione avrà sempre esito positivo, ma offre un'esperienza utente migliore e un messaggio di errore chiaro per questa rara situazione.

Conclusione

Come sviluppatore di giochi destinato all'ambiente multiutente di Windows, è fondamentale progettare il gioco per operare in modo efficace e responsabile. Il file eseguibile principale del gioco non deve dipendere dai privilegi amministrativi. Ciò non solo impedisce l'aspetto di richieste di elevazione ogni volta che il gioco viene eseguito che può influire negativamente sull'esperienza utente complessiva, ma consente anche al gioco di sfruttare altre funzionalità che richiedono l'esecuzione con privilegi utente standard, ad esempio Parental Controls.

Le applicazioni progettate correttamente per funzionare come con le credenziali di un utente standard (o utente limitato) nelle versioni precedenti di Windows non saranno interessate dal controllo dell'account utente che verranno eseguite senza elevazione dei privilegi. Tuttavia, devono includere un manifesto con il livello di esecuzione richiesto impostato su "asInvoker" per conformarsi agli standard dell'applicazione per Vista.

Altre informazioni

Per assistenza nella progettazione di applicazioni per Windows Vista conformi al controllo dell'account utente, scaricare il white paper seguente: Requisiti di sviluppo delle applicazioni di Windows Vista per compatibilità del controllo dell'account utente.

Questo white paper fornisce procedure dettagliate sul processo di progettazione, insieme a esempi di codice, requisiti e procedure consigliate. Questo documento illustra anche gli aggiornamenti tecnici e le modifiche apportate all'esperienza utente in Windows Vista.

Per altre informazioni sul controllo dell'account utente, visitare Windows Vista: Controllo dell'account utente in Microsoft TechNet.

Un'altra risorsa utile è l'articolo Insegnare alle app a giocare con il controllo dell'account utente di Windows Vista, da MSDN Magazine, gennaio 2007. Questo articolo illustra i problemi generali di compatibilità delle applicazioni, nonché i vantaggi e i problemi relativi all'uso dei pacchetti di Windows Installer in Windows Vista.

Per altre informazioni sul bug e sulla correzione per mt.exe, lo strumento usato da Visual Studio 2005 per unire e incorporare automaticamente un manifesto in un eseguibile, vedere Esplorazione dei manifesti parte 2: Spazi dei nomi predefiniti e manifesti di controllo dell'account utente in Windows Vista sul blog di Chris Jackson su MSDN.