Benutzerkontensteuerung für Spieleentwickler

In diesem Artikel werden die Richtlinien und bewährten Methoden für Spieleentwickler beschrieben, um effektiv mit der in Windows Vista eingeführten Sicherheitsfunktion für die Benutzerkontensteuerung (User Account Control, UAC) zu arbeiten.

• Übersicht über die Benutzerkontensteuerung
• Benutzerkonten in Windows Vista
• Dateizugriff als Standardbenutzer
• Registrierungszugriff als Standardbenutzer
• Rechteerweiterungen
• UAC-Auswirkungen mit CreateProcess()
• Festlegen der Ausführungsebene im Anwendungsmanifest
• Einbetten eines Manifests in Visual Studio
• UAC-Kompatibilität mit älteren Spielen
• Legacyszenarien und Manifeste
• Zusammenfassung
• Weitere Lektüre

Übersicht über die Benutzerkontensteuerung

Die in Windows Vista eingeführte Benutzerkontensteuerung (User Account Control, UAC) ist ein Sicherheitsfeature, das dazu beitragen soll, böswillige Angreifer daran zu hindern, Schwachstellen oder Fehler in weit verbreiteten Anwendungen zu verwenden, um das Betriebssystem oder andere installierte Programme zu ändern. Dies wird erreicht, indem die überwiegende Mehrheit der Programme und Prozesse als Standardbenutzer (auch als eingeschränkter Benutzer, eingeschränkter Benutzer oder Least-Privileged Benutzer bezeichnet) ausgeführt wird, selbst wenn das Konto des aktuellen Benutzers über Administratoranmeldeinformationen verfügt. Ein Prozess mit Standardbenutzerberechtigungen weist viele inhärente Einschränkungen auf, die verhindern, dass er systemweite Änderungen vornimmt.

UAC ist auch für die Rechteerweiterung eines Prozesses durch Verwendung eines dialogbasierten Authentifizierungsschemas verantwortlich, das bei der Ausführung bestimmter Prozesse initiiert wird, die als erforderlich für Administratorrechte festgelegt sind. Die Rechteerweiterung ermöglicht Es Administratoren, den Großteil ihrer Anwendungen auf einer sicheren Berechtigungsstufe auszuführen (die gleiche wie jeder andere Standardbenutzer), aber auch Prozesse und Vorgänge zuzulassen, die Administratorrechte erfordern. UAC unterstützt die over-the-shoulder-Authentifizierung, sodass ein Administrator einem Programm erhöhte Berechtigungen gewähren kann, während ein Standardbenutzer derzeit am System angemeldet ist.

Das UAC-Feature ist standardmäßig aktiviert. Zwar ist es für einen Administrator möglich, die UAC systemweit zu deaktivieren, dies hat jedoch eine Reihe negativer Auswirkungen. Erstens schwächt dies die Sicherheit aller Administratorkonten, da alle Prozesse mit Administratoranmeldeinformationen ausgeführt würden, auch wenn die meisten Anwendungen diese nicht benötigen. Wenn UAC deaktiviert ist, kann eine Standardbenutzeranwendung, die ein ausnutzbares Sicherheitsrisiko verfügbar macht, möglicherweise verwendet werden, um private Informationen zu stehlen, Rootkits oder Spyware zu installieren, die Systemintegrität zu zerstören oder Zombieangriffe auf andere Systeme zu hosten. Während bei aktivierter UAC die Ausführung eines Großteils der Software als Standardbenutzer die potenziellen Schäden durch einen solchen Fehler erheblich einschränkt. Zweitens deaktiviert das Deaktivieren der UAC viele der Problemumgehungen für die Anwendungskompatibilität, die es echten Standardbenutzern ermöglichen, eine vielzahl von Anwendungen erfolgreich auszuführen. Das Deaktivieren der UAC sollte niemals als Kompatibilitätsumgehung empfohlen werden.

Es ist wichtig zu beachten, dass Anwendungen versuchen sollten, nur Standardbenutzerrechte zu verwenden, wenn dies möglich ist. Während Administratoren die Berechtigungen eines Prozesses problemlos erhöhen können, erfordert die Rechteerweiterung weiterhin eine Benutzerinteraktion und eine Bestätigung jedes Mal, wenn eine Anwendung ausgeführt wird, die Administratoranmeldeinformationen erfordert. Diese Erhöhung muss auch beim Start des Programms erfolgen, sodass das Anfordern von Administratoranmeldeinformationen auch für einen einzelnen Vorgang ein höheres Risiko für das System für die gesamte Laufzeit der Anwendung erfordert. Standardbenutzer ohne die Möglichkeit, ihre Berechtigungen zu erhöhen, sind auch in Familien- und Unternehmenseinstellungen üblich. "Als Administrator ausführen" ist keine gute Problemumgehung für die Kompatibilität, setzt den Benutzer und das System einem höheren Sicherheitsrisiko aus und sorgt in vielen Situationen für Frustration bei Benutzern.

Hinweis

Die in Windows Vista eingeführte Funktion "Benutzerkontensteuerung" ist auch in Windows 7 vorhanden. Während die Benutzererfahrung bei der Arbeit mit den verschiedenen Systemfeatures in Bezug auf die Benutzerkontensteuerung verbessert wurde, sind die Auswirkungen auf Anwendungen im Grunde die gleichen. Alle Windows Vista-Empfehlungen in diesem Artikel gelten auch für Windows 7. Ausführliche Informationen zu den Änderungen der UAC-Benutzeroberfläche für Windows 7 finden Sie unter Benutzeroberfläche – Dialogfeld "Benutzerkontensteuerung" Updates.

Benutzerkonten in Windows Vista

Windows Vista kategorisiert jeden Benutzer in zwei Benutzerkontotypen: Administratoren und Standardbenutzer.

Ein Standardbenutzerkonto ähnelt einem eingeschränkten Benutzerkonto in Windows XP. Wie in Windows XP kann ein Standardbenutzer nicht in den Ordner Programme schreiben, kann nicht in den HKEY_LOCAL_MACHINE Teil der Registrierung schreiben und keine Aufgaben ausführen, die das System ändern, z. B. das Installieren eines Kernelmodustreibers oder den Zugriff auf Prozessbereiche auf Systemebene.

Das Administratorkonto hat sich seit der Veröffentlichung von Windows XP erheblich geändert. Bisher erhielten alle Prozesse, die von einem Mitglied der Gruppe Administratoren gestartet wurden, Administratorrechte. Wenn UAC aktiviert ist, werden alle Prozesse mit Standardbenutzerberechtigungen ausgeführt, es sei denn, sie werden von einem Administrator ausdrücklich erhöht. Dieser Unterschied macht Konten in der Gruppe Administratoren sicherer, indem das Sicherheitsrisiko reduziert wird, das durch potenzielle Fehler in den meisten Programmen verursacht wird.

Es ist wichtig, dass alle Anwendungen, insbesondere Spiele, effektiv und verantwortungsbewusst arbeiten, wenn sie als Standardbenutzerprozess ausgeführt werden. Alle Vorgänge, die Administratorrechte erfordern, sollten entweder zur Installationszeit oder durch Hilfsprogramme ausgeführt werden, die explizit Administratoranmeldeinformationen anfordern. Während die Rechteerweiterung für ein Mitglied der Gruppe "Administratoren" ziemlich trivial ist, müssen Standardbenutzer personen mit Administratoranmeldeinformationen zur physischen Eingabe ihres Kennworts zurückstellen, um Berechtigungen zu erhöhen. Da Konten, die durch Die Kindersicherung geschützt sind, Standardbenutzer sein müssen, ist dies eine sehr häufige Situation für Spieler, die Windows Vista verwenden.

Wenn Ihr Spiel bereits unter Windows XP mit eingeschränkten Benutzerkonten funktioniert, sollte der Wechsel zur Benutzerkontensteuerung unter Windows Vista sehr einfach sein. Die Meisten dieser Anwendungen funktionieren unverändert, obwohl das Hinzufügen eines Anwendungsmanifests dringend empfohlen wird. (Manifeste werden weiter unten in diesem Thema unter Festlegen der Ausführungsebene im Anwendungsmanifest beschrieben.)

Dateizugriff als Standardbenutzer

Der Aspekt Ihres Spiels, der am meisten von standard-Benutzereinschränkungen betroffen ist, ist dateisystem organization und Barrierefreiheit. Sie sollten niemals davon ausgehen, dass Ihr Spiel Dateien in den Ordner schreiben kann, in dem Ihr Spiel installiert ist. In Windows Vista für instance müssen die Berechtigungen eines Benutzers vom Betriebssystem erhöht werden, bevor eine Anwendung in den Ordner "Programme" schreiben kann. Um dies zu vermeiden, sollten Sie Ihre Spieldatendateien nach Bereich und Barrierefreiheit kategorisieren und die SHGetFolderPath-Funktion zusammen mit den von der Windows-Shell bereitgestellten CSIDL-Konstanten verwenden, um die entsprechenden Dateipfade zu generieren. Die CSIDL-Konstanten entsprechen bekannten Ordnern im Dateisystem, die das Betriebssystem verwendet und herstuft, um globale und benutzerspezifische Dateien zu partitionieren.

Der Versuch, eine Datei oder ein Verzeichnis unter einem Ordner zu erstellen oder zu schreiben, der dem Prozess keine Schreibberechtigung erteilt, schlägt unter Windows Vista fehl, wenn die Anwendung über keine Administratorrechte verfügt. Wenn ihre ausführbare 32-Bit-Spieldatei im Legacymodus ausgeführt wird, da sie keine angeforderte Ausführungsebene deklariert hat, werden die Schreibvorgänge erfolgreich ausgeführt, aber sie unterliegen der Virtualisierung, wie im Abschnitt "UAC-Kompatibilität mit älteren Spielen" weiter unten in diesem Artikel beschrieben.

Tabelle 1. Bekannte Ordner

CSIDL-Name	Typischer Pfad (Windows Vista)	Standardbenutzerrechte	Administratorrechte	Zugriffsbereich	BESCHREIBUNG	Beispiele
CSIDL_PERSONAL	C:\Benutzer\Benutzername\Dokumente	Lesen/Schreiben	Lesen/Schreiben	Benutzerspezifisch	Benutzerspezifische Spieldateien, die gelesen und geändert werden und außerhalb des Spielkontexts bearbeitet werden können.	Screenshots. Gespeicherte Spieldateien mit einer Dateierweiterungszuordnung.
CSIDL_LOCAL_APPDATA	C:\Benutzer\Benutzername\AppData\Local	Lesen/Schreiben	Lesen/Schreiben	Benutzerspezifisch	Benutzerspezifische Spieldateien, die gelesen und geändert werden und nur im Spielkontext verwendet werden können.	Spielecachedateien. Playerkonfigurationen.
CSIDL_COMMON_APPDATA	C:\ProgramData	Lese-/Schreibzugriff, wenn Besitzer	Lesen/Schreiben	Allen Benutzern	Spieldateien, die von einem Benutzer erstellt und von allen Benutzern gelesen werden können. Schreibzugriff wird nur dem Ersteller der Datei (Besitzer) gewährt.	Benutzerprofile
CSIDL_PROGRAM_FILES	C:\Programme oder C:\Programme (x86)	Schreibgeschützt	Lesen/Schreiben	Allen Benutzern	Statische Spieldateien, die vom Installationsprogramm des Spiels geschrieben wurden und von allen Benutzern gelesen werden.	Spielressourcen, z. B. Materialien und Gitter.

Ihr Spiel wird in der Regel in einem Ordner unter dem Ordner installiert, der durch die CSIDL_PROGRAM_FILES-Konstante dargestellt wird. Dies ist jedoch nicht immer der Fall. Sie sollten stattdessen einen relativen Pfad aus Ihrer ausführbaren Datei verwenden, wenn Sie Pfadzeichenfolgen zu Dateien oder Verzeichnissen generieren, die sich unter Ihrem Installationsordner befinden.

Sie sollten auch hartcodierte Annahmen zu den bekannten Ordnerpfaden unterlassen. Unter Windows XP Professional 64-Bit Edition und Windows Vista x64 lautet der Programmdateipfad beispielsweise C:\Programme (x86) für 32-Bit-Programme und C:\Programme für 64-Bit-Programme. Diese bekannten Pfade werden von Windows XP geändert, und Benutzer können den Speicherort vieler dieser Ordner neu konfigurieren und sogar auf verschiedenen Laufwerken suchen. Verwenden Sie daher immer die CSIDL-Konstanten, um Verwirrung und potenzielle Probleme zu vermeiden. Windows Setup kennt diese bekannten Ordnerspeicherorte und verschenkt die Daten beim Upgrade des Betriebssystems von Windows XP. Im Gegensatz dazu kann die Verwendung von nicht standardmäßigen Speicherorten oder hartcodierten Pfaden nach einem Betriebssystemupgrade möglicherweise fehlschlagen.

Es sollte auf die subtilen Benutzerfreundlichkeitsunterschiede zwischen den von CSIDL_PERSONAL und CSIDL_LOCAL_APPDATA angegebenen benutzerspezifischen Ordnern geachtet werden. Die empfohlene Vorgehensweise für die Auswahl der CSIDL-Konstante, die zum Schreiben einer Datei verwendet werden soll, besteht darin, CSIDL_PERSONAL zu verwenden, wenn der Benutzer mit der Datei interagieren soll, z. B. doppelklicken, um sie in einem Tool oder einer Anwendung zu öffnen, und CSIDL_LOCAL_APPDATA für andere Dateien zu verwenden. Beide Ordner können von Ihrer Anwendung genutzt werden, um benutzerspezifische Datendateien zu speichern und zu organisieren, da es keinen Unterschied im Zugriffsbereich oder der Berechtigungsstufe gibt. Es sollte darauf geachtet werden, Pfadnamen zu erstellen, die eindeutig genug sind, um nicht mit anderen Anwendungen zu kollidieren, aber kurz genug, um die Anzahl der Zeichen im vollständigen Pfad kleiner zu halten als der Wert von MAX_PATH, 260.

Der folgende Code enthält ein Beispiel für das Schreiben einer Datei in einen bekannten Ordner:

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

Registrierungszugriff als Standardbenutzer

Der Registrierungszugriff durch einen Standardbenutzer ist auf ähnliche Weise wie das Dateisystem eingeschränkt. Einem Standardbenutzer wird lesezugriff auf alle Schlüssel in der Registrierung gestattet; Schreibzugriff wird jedoch nur für die unterstrukturierte HKEY_CURRENT_USER (HKCU) gewährt, die intern dem benutzerspezifischen Unterschlüssel HKEY_USERS\Security ID (SID) des aktuellen Benutzers zugeordnet wird. Eine Anwendung, die in einen anderen Registrierungsspeicherort als HKEY_CURRENT_USER schreiben muss, erfordert Administratorrechte.

Wenn die 32-Bit-Anwendung keine angeforderte Ausführungsebene in ihrem Manifest enthält, werden alle Schreibvorgänge in HKEY_LOCAL_MACHINE\Software virtualisiert, während Schreibvorgänge an anderen Speicherorten außerhalb von HKEY_CURRENT_USER fehlschlagen.

Das Speichern persistenter Daten in der Registrierung, z. B. die Konfiguration eines Benutzers, wird nicht empfohlen. Die bevorzugte Methode zum Speichern persistenter Daten aus Ihrem Spiel besteht darin, die Daten durch Aufrufen von SHGetFolderPath in das Dateisystem zu schreiben und den Wert einer CSIDL-Konstante abzurufen, die im vorherigen Abschnitt beschrieben wurde.

Rechteerweiterungen

In Windows Vista muss jede Anwendung, die Administratorrechte erfordert, eine Anforderung für eine administrative Ausführungsebene in ihrem Manifest deklarieren (dies wird im nächsten Abschnitt , Festlegen der Ausführungsebene im Anwendungsmanifest beschrieben).

Die sogenannte Rechteerweiterung ist die Prozedur, die von der UAC gesteuert wird, um einen Prozess zu einem Verwaltungsprozess heraufzustufen. Die Berechtigungen eines Prozesses können nur zum Zeitpunkt der Erstellung erhöht werden. Nach der Erstellung wird ein Prozess niemals auf eine höhere Berechtigungsstufe heraufgestuft. Aus diesem Grund. Vorgänge, die Administratoranmeldeinformationen erfordern, sollten in separate Installationsprogramme und andere Hilfsprogramme isoliert werden.

Bei der Ausführung eines Programms überprüft die UAC die angeforderte Ausführungsebene im Manifest, und wenn erhöhte Berechtigungen erforderlich sind, fordert der aktuelle Benutzer mit einem von zwei Standarddialogfeldern auf: eines für einen Standardbenutzer und eines für einen Administrator.

Wenn der aktuelle Benutzer ein Standardbenutzer ist, fordert UAC den Benutzer zur Eingabe der Anmeldeinformationen eines Administrators auf, bevor das Programm ausgeführt werden kann.

Abbildung 1. Aufforderung zur Eingabe von Anmeldeinformationen für ein Administratorkonto durch einen Standardbenutzer

Wenn der aktuelle Benutzer ein Administrator ist, fordert UAC den Benutzer zur Berechtigung auf, bevor das Programm ausgeführt werden kann.

Abbildung 2. Aufforderung zum Autorisieren von Änderungen am Computer durch einen Administrator

Der Anwendung werden nur Administratorrechte gewährt, wenn ein Standardbenutzer die richtigen Administratoranmeldeinformationen bereitstellt oder ein Administrator eine Bestätigung bereitstellt. Alles andere führt dazu, dass die Anwendung beendet wird.

Es ist wichtig zu beachten, dass ein Prozess mit erhöhten Berechtigungen als Administrator, der Anmeldeinformationen in der UAC-Eingabeaufforderung eingegeben hat, und nicht als Standardbenutzer ausgeführt wird, der derzeit angemeldet ist. Dies ähnelt RunAs in Windows XP. Der Prozess mit erhöhten Rechten ruft beim Zugriff auf Benutzerdaten den Ordner und Registrierungsschlüssel des Administrators ab, und alle Programme, die der Prozess mit erhöhten Rechten startet, erben auch die Administratorrechte und die Speicherorte des Benutzerkontos. Für Administratoren, die zur Bestätigung aufgefordert werden (Weiter oder Abbrechen), stimmen diese Speicherorte mit den Aktuellen Standorten des Benutzers überein. Im Allgemeinen sollten Prozesse, die eine Rechteerweiterung erfordern, jedoch nicht für Benutzerdaten ausgeführt werden. Beachten Sie, dass sich dies erheblich auf die Funktionsweise Ihres Installationsprogramms auswirken kann! Wenn das Installationsprogramm, das als Administrator ausgeführt wird, in HKCU oder in das Profil eines Benutzers schreibt, kann es sehr gut sein, dass es an den falschen Speicherort schreibt. Erwägen Sie, diese Werte pro Benutzer bei der ersten Ausführung des Spiels zu erstellen.

UAC-Auswirkungen mit CreateProcess()

Der UAC-Erhöhungsmechanismus wird nicht über einen Aufruf der Win32 CreateProcess()-Funktion aufgerufen, um eine ausführbare Datei zu starten, die so konfiguriert ist, dass eine höhere Ausführungsebene als der aktuelle Prozess erforderlich ist. Daher schlägt der Aufruf von CreateProcess() fehl, und GetLastError() gibt ERROR_ELEVATION_REQUIRED zurück. CreateProcess() ist nur erfolgreich, wenn die Ausführungsebene des Aufgerufenen gleich oder kleiner als die des Aufrufers ist. Ein Prozess ohne erhöhte Rechte, der Prozesse mit erhöhten Rechten erzeugen muss, sollte dies mithilfe der ShellExecute()-Funktion tun, die dazu führt, dass der UAC-Erhöhungsmechanismus über die Shell ausgelöst wird.

Festlegen der Ausführungsebene im Anwendungsmanifest

Sie deklarieren die angeforderte Ausführungsebene Ihres Spiels, indem Sie dem Manifest der Anwendung eine Erweiterung hinzufügen. Der folgende XML-Code zeigt die minimale Konfiguration, die zum Festlegen der Ausführungsebene für eine Anwendung erforderlich ist:

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

Im obigen Code wird das Betriebssystem darüber informiert, dass das Spiel nur Standardbenutzerberechtigungen durch das folgende Tag erfordert:

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

Durch explizites Festlegen von requestedExecutionLevel auf "asInvoker" bestätigt dieses Beispiel dem Betriebssystem, dass sich das Spiel ohne Administratorrechte ordnungsgemäß verhält. Daher deaktiviert UAC die Virtualisierung und führt das Spiel mit den gleichen Berechtigungen wie der Aufrufer aus, was in der Regel Standardbenutzerberechtigungen ist, da Windows Explorer als Standardbenutzer ausgeführt wird.

Das Betriebssystem kann informiert werden, dass ein Spiel eine Erhöhung von Administratorrechten erfordert, indem "asInvoker" durch "requireAdministrator" ersetzt wird, um das folgende Tag zu erstellen:

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

Bei dieser Konfiguration fordert das Betriebssystem den aktuellen Benutzer bei jeder Ausführung des Spiels mit einem der Standardmäßigen UAC-Rechteerweiterungsdialoge auf. Es wird dringend empfohlen, dass kein Spiel Administratorrechte erfordert, da dieser Dialog nicht nur schnell nervig wird, sondern auch das Spiel nicht mit der Kindersicherung kompatibel macht. Überlegen Sie sehr sorgfältig, bevor Sie diese Anforderung zu einer ausführbaren Datei hinzufügen.

Ein häufiges Missverständnis besteht darin, dass das Hinzufügen eines Manifests, das requestedExecutionLevel auf "requireAdministrator" festlegt, die Notwendigkeit einer Aufforderung zur Erhöhung umgeht. Das ist falsch. Es verhindert einfach, dass das Betriebssystem erraten kann, ob Ihre Setup- oder Updateanwendung Administratorrechte benötigt. Der Benutzer wird weiterhin aufgefordert, die Rechteerweiterung zu autorisieren.

Windows überprüft die Signatur einer Anwendung, die auf Erhöhte Rechte gekennzeichnet ist, bevor die UAC-Eingabeaufforderung angezeigt wird. Eine große ausführbare Datei, die zur Erhöhung gekennzeichnet ist, dauert die Überprüfung länger als eine kleine ausführbare Datei und länger als eine ausführbare Datei, die als "asInvoker" gekennzeichnet ist. Setup-ausführbare Dateien, die selbstextrahieren, sollten daher als "asInvoker" gekennzeichnet werden, und alle Teile, die als "requireAdministrator" gekennzeichnet werden müssen, sollten in einer separaten ausführbaren Hilfsprogrammdatei platziert werden.

Das uiAccess-Attribut, das in den vorherigen Beispielen gezeigt wurde, sollte für Spiele immer FALSE sein. Dieses Attribut gibt an, ob Benutzeroberflächenautomatisierungsclients Zugriff auf die geschützte Systemoberfläche haben, und es hat besondere Auswirkungen auf die Sicherheit, wenn es auf TRUE festgelegt ist.

Einbetten eines Manifests in Visual Studio

Die Manifestunterstützung wurde visual Studio ab VS2005 hinzugefügt. Standardmäßig wird für eine ausführbare Datei, die in Visual Studio 2005 (oder höher) erstellt wurde, ein automatisch generiertes Manifest als Teil des Buildprozesses eingebettet. Der Inhalt des automatisch generierten Manifests ist von bestimmten Projektkonfigurationen abhängig, die Sie im Dialogfeld "Projekteigenschaften" angeben.

Das manifest, das automatisch von Visual Studio 2005 generiert wird, enthält <keinen trustInfo-Block> , da es keine Möglichkeit gibt, die UAC-Ausführungsebene in den Projekteigenschaften zu konfigurieren. Die bevorzugte Methode zum Hinzufügen dieser Informationen besteht darin, VS2005 ein benutzerdefiniertes Manifest zusammenführen zu lassen, das den <trustInfo-Block> mit dem automatisch generierten Manifest enthält. Dies ist so einfach wie das Hinzufügen einer *.manifest-Datei zu Ihrer Projektmappe, die die im vorherigen Abschnitt aufgeführte XML-Datei enthält. Wenn Visual Studio in Ihrer Projektmappe auf eine MANIFEST-Datei trifft, ruft es automatisch das Manifesttool (mt.exe) auf, um die MANIFEST-Dateien mit der automatisch generierten zusammenzuführen.

Hinweis

Es gibt einen Fehler im Manifesttool (mt.exe), das von Visual Studio 2005 bereitgestellt wird und zu einem zusammengeführten und eingebetteten Manifest führt, das Probleme verursachen kann, wenn die ausführbare Datei unter Windows XP vor SP3 ausgeführt wird. Der Fehler ist ein Ergebnis davon, wie das Tool den Standardnamespace bei der Deklaration des <trustInfo-Blocks> neu definiert. Glücklicherweise ist es einfach, das Problem vollständig zu umgehen, indem sie explizit einen anderen Namespace im <trustInfo-Block> deklarieren und die untergeordneten Knoten in den neuen Namespace eingrenzen. Die im vorherigen Abschnitt bereitgestellte XML-Datei veranschaulicht diese Korrektur.

Eine Einschränkung bei der Verwendung des in Visual Studio 2005 enthaltenen mt.exe-Tools besteht darin, dass beim Verarbeiten des <trustInfo-Blocks> eine Warnung generiert wird, da das Tool kein aktualisiertes Schema zum Überprüfen der XML enthält. Um diese Warnung zu beheben, wird empfohlen, alle mt.exe Dateien im Visual Studio 2005-Installationsverzeichnis (es gibt mehrere Instanzen) durch die im neuesten Windows SDK bereitgestellten mt.exe zu ersetzen.

Ab Visual Studio 2008 können Sie jetzt die Ausführungsebene einer Anwendung im Dialogfeld mit den Projekteigenschaften (Abbildung 3) oder mithilfe des Linkerflags /MANIFESTUAC angeben. Das Festlegen dieser Optionen führt dazu, dass Visual Studio 2008 automatisch ein Manifest mit dem entsprechenden <trustInfo-Block> generiert und in die ausführbare Datei einbettet.

Abbildung 3. Festlegen der Ausführungsebene in Visual Studio 2008

Das Einbetten eines Manifests in ältere Versionen von Visual Studio ohne Manifestunterstützung ist weiterhin möglich, erfordert jedoch mehr Arbeit vom Entwickler. Ein Beispiel hierzu finden Sie im Visual Studio 2003-Projekt, das vor dem Release vom März 2008 in einem beliebigen Beispiel im DirectX SDK enthalten ist.

UAC-Kompatibilität mit älteren Spielen

Wenn Ihr Spiel scheinbar eine Datei erfolgreich im Verzeichnis Programme speichert und lädt, aber keine Beweise für die Datei iIn Windows Vista, wird jede 32-Bit-Anwendung, die keine angeforderte Ausführungsebene in ihrem Manifest enthält, als Legacyanwendung betrachtet. Vor Windows Vista wurden die meisten Anwendungen in der Regel von Benutzern mit Administratorrechten ausgeführt. Daher konnten diese Anwendungen Systemdateien und Registrierungsschlüssel frei lesen und schreiben, und viele Entwickler haben nicht die Änderungen vorgenommen, die für die ordnungsgemäße Arbeit mit eingeschränkten Benutzerkonten unter Windows XP erforderlich sind. Unter Windows Vista würden diese Anwendungen jedoch aufgrund unzureichender Zugriffsberechtigungen unter dem neuen Sicherheitsmodell fehlschlagen, das die Standardbenutzerausführung für Legacyanwendungen erzwingt. Um dies zu minimieren, wurde die Virtualisierung auch zu Windows Vista hinzugefügt. Mit der Virtualisierung können Tausende von Legacyanwendungen unter Windows Vista gut funktionieren, ohne dass diese Anwendungen jederzeit über erhöhte Berechtigungen verfügen müssen, nur um bei einigen kleineren Vorgängen erfolgreich zu sein. gefunden, besteht die Wahrscheinlichkeit, dass Ihr Spiel im Legacymodus ausgeführt wird und einer Virtualisierung unterzogen wurde.

Die Virtualisierung wirkt sich auf das Dateisystem und die Registrierung aus, indem systemrelevante Schreibvorgänge (und nachfolgende Datei- oder Registrierungsvorgänge) an einen Benutzerspeicherort im Profil des aktuellen Benutzers umgeleitet werden. Beispielsweise, wenn eine Anwendung versucht, in die folgende Datei zu schreiben:

C:\\Programme\\Unternehmens-Name\\Title\\config.ini

Der Schreibvorgang wird automatisch an Folgendes umgeleitet:

C:\\Benutzer\\Benutzername\\AppData\\Local\\VirtualStore\\Programme\\Unternehmen Name\\Title\\config.ini

Ebenso, wenn eine Anwendung versucht, einen Registrierungswert wie den folgenden zu schreiben:

HKEY\_LOCAL\_MACHINE\\Software\\Firmenname\\Titel

Sie wird stattdessen an Folgendes umgeleitet:

HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Firmenname\\Titel

Auf Dateien und Registrierungsschlüssel, die von der Virtualisierung betroffen sind, kann nur über Datei- und Registrierungsvorgänge von virtualisierten Anwendungen zugegriffen werden, die als aktueller Benutzer ausgeführt werden.

Es gibt jedoch viele Einschränkungen bei der Virtualisierung. Eine davon ist, dass 64-Bit-Anwendungen niemals im Legacymodus ausgeführt werden, um Kompatibilitätsvorgänge durchzuführen, die der Virtualisierung unterliegen, in 32-Bit-Anwendungen wird nur in 64-Bit fehlschlagen. Wenn eine legacy-Anwendung, die als Standardbenutzer ausgeführt wird, versucht, einen beliebigen Typ von ausführbarer Datei an einen Speicherort zu schreiben, der Administratoranmeldeinformationen erfordert, erfolgt keine Virtualisierung, und der Schreibvorgang schlägt fehl.

Abbildung 4. Virtualisierungsprozess

Wenn eine Ältere Anwendung einen Lesevorgang an systemrelevanten Speicherorten im Dateisystem oder in der Registrierung versucht, werden zuerst die virtuellen Speicherorte durchsucht. Wenn die Datei oder der Registrierungsschlüssel nicht gefunden wird, greift das Betriebssystem auf die Standardspeicherorte des Systems zu.

Die Virtualisierung wird aus nachfolgenden Versionen von Windows entfernt, daher ist es wichtig, sich nicht auf dieses Feature zu verlassen. Stattdessen sollten Sie Ihr Anwendungsmanifest explizit für Standardbenutzer- oder Administratorrechte konfigurieren, da dadurch die Virtualisierung deaktiviert wird. Virtualisierung ist auch für Endbenutzer nicht offensichtlich. Obwohl die Virtualisierung die Ausführung Ihrer Anwendung ermöglicht, kann sie Supportaufrufe generieren und die Problembehandlung für diese Kunden erschweren.

Beachten Sie, dass die Virtualisierung auch deaktiviert ist, wenn UAC deaktiviert ist. Wenn die Virtualisierung deaktiviert ist, verhalten sich Standardbenutzerkonten genau wie eingeschränkte Benutzerkonten in Windows XP, und Ältere Anwendungen funktionieren möglicherweise nicht ordnungsgemäß für Standardbenutzer, die andernfalls aufgrund der Virtualisierung erfolgreich gewesen wären.

Legacyszenarien und Manifeste

In den meisten Verwendungsszenarien ist es ausreichend, die .exe mit den richtigen UAC-Manifestelementen zu markieren und sicherzustellen, dass die Anwendung ordnungsgemäß als Standardbenutzer funktioniert, um eine hervorragende UAC-Kompatibilität zu gewährleisten. Die meisten Gamer führen Windows Vista oder Windows 7 mit aktivierter Benutzerkontensteuerung aus. Für Windows XP und Benutzer unter Windows Vista oder Windows7 mit deaktiviertem Feature "Benutzerkontensteuerung" werden diese in der Regel mithilfe von Administratorkonten ausgeführt. Obwohl dies ein weniger sicherer Betriebsmodus ist, treten in der Regel keine zusätzlichen Kompatibilitätsprobleme auf, obwohl, wie oben erwähnt, die Deaktivierung der UAC auch die Virtualisierung deaktiviert.

Es gibt einen Sonderfall, der beachtet werden sollte, wenn das Programm im UAC-Manifest als "requireAdministrator" gekennzeichnet ist. Unter Windows XP und Windows Vista oder Windows 7 mit deaktivierter Benutzerkontensteuerung werden die UAC-Manifestelemente vom System ignoriert. In dieser Situation führen Benutzer mit Administratorkonten immer alle Programme mit vollständigen Administratorrechten aus, sodass diese Programme wie erwartet funktionieren. Eingeschränkte Windows XP-Benutzer und Standardbenutzer unter Windows Vista oder Windows 7 führen diese Programme jedoch immer mit eingeschränkten Rechten aus, und alle Vorgänge auf Administratorebene schlagen fehl. Es wird daher empfohlen, dass Programme, die als "requiretAdministrator" gekennzeichnet sind, beim Start IsUserAnAdmin aufrufen und eine schwerwiegende Fehlermeldung anzeigen, wenn FALSE zurückgegeben wird. Für das oben genannte Mehrheitsszenario wird dies immer erfolgreich sein, bietet jedoch eine bessere Benutzererfahrung und eine klare Fehlermeldung für diese seltene Situation.

Zusammenfassung

Als Spieleentwickler für die Windows-Umgebung mit mehreren Benutzern ist es unerlässlich, dass Sie Ihr Spiel so entwerfen, dass es effektiv und verantwortungsbewusst funktioniert. Die Standard ausführbare Datei Ihres Spiels sollte nicht von Administratorrechten abhängig sein. Dies verhindert nicht nur das Auftreten von Aufforderungen zur Erhöhung jedes Mal, wenn Ihr Spiel ausgeführt wird, was sich negativ auf die allgemeine Benutzererfahrung auswirken kann, sondern ermöglicht es Ihrem Spiel auch, andere Features zu nutzen, die die Ausführung mit Standardbenutzerrechten erfordern, z. B. Jugendschutz.

Anwendungen, die ordnungsgemäß für den Betrieb mit den Anmeldeinformationen eines Standardbenutzers (oder eines eingeschränkten Benutzers) unter früheren Versionen von Windows konzipiert sind, sind von der UAC nicht betroffen, sie werden ohne Rechteerweiterung ausgeführt. Sie sollten jedoch ein Manifest enthalten, dessen angeforderte Ausführungsebene auf "asInvoker" festgelegt ist, um den Anwendungsstandards für Vista zu entsprechen.

Weitere Informationen

Um Unterstützung beim Entwerfen von Anwendungen für Windows Vista zu erhalten, die mit der Benutzerkontensteuerung kompatibel sind, laden Sie das folgende Whitepaper herunter: Windows Vista Anwendungsentwicklungsanforderungen für die Kompatibilität der Benutzerkontensteuerung.

Dieses Whitepaper enthält detaillierte Schritte zum Entwurfsprozess sowie Codebeispiele, Anforderungen und bewährte Methoden. In diesem Dokument werden auch die technischen Updates und Änderungen an der Benutzeroberfläche in Windows Vista beschrieben.

Weitere Informationen zur Benutzerkontensteuerung finden Sie unter Windows Vista: Benutzerkontensteuerung in Microsoft TechNet.

Eine weitere nützliche Ressource ist der Artikel Teach Your Apps To Play Nicely with Windows Vista User Account Control aus dem MSDN Magazine, Januar 2007. In diesem Artikel werden allgemeine Probleme der Anwendungskompatibilität sowie die Vorteile und Probleme der Verwendung von Windows Installer-Paketen unter Windows Vista erläutert.

Weitere Informationen zum Fehler und zur Behebung von mt.exe, dem Tool, das von Visual Studio 2005 zum automatischen Zusammenführen und Einbetten eines Manifests in eine ausführbare Datei verwendet wird, finden Sie unter Erkunden von Manifesten, Teil 2: Standardnamespaces und UAC-Manifeste in Windows Vista im Blog von Chris Jackson auf MSDN.