Freigeben über

Benutzerkontensteuerung für Spieleentwickler

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

Übersicht über die Benutzerkontensteuerung

Die in Windows Vista eingeführte Benutzerkontensteuerung (User Account Control, UAC) ist ein Sicherheitsfeature, das dazu dient, böswillige Angreifer daran zu hindern, Schwachstellen oder Fehler in weitverwendeten Anwendungen zu verwenden, um das Betriebssystem oder andere installierte Programme zu ändern. Dies wird erreicht, indem die meisten Programme und Prozesse als Standardbenutzer (auch als eingeschränkter Benutzer, eingeschränkter Benutzer oder Least-Privileged Benutzer bezeichnet) ausgeführt werden, auch wenn das Konto des aktuellen Benutzers über Administratoranmeldeinformationen verfügt. Ein Prozess mit Standardbenutzerrechten hat viele inhärente Einschränkungen, die verhindern, dass ein systemweites Ändern vorgenommen wird.

UAC ist auch für die Rechteerweiterung eines Prozesses verantwortlich, indem ein dialogbasiertes Authentifizierungsschema verwendet wird, das bei der Ausführung bestimmter Prozesse initiiert wird, die als Administratorrechte festgelegt werden. Berechtigungserweiterungen ermöglichen Administratoren das Ausführen der meisten Anwendungen auf einer sicheren Berechtigungsstufe (identisch mit jedem anderen Standardbenutzer), aber auch Prozesse und Vorgänge, die Administratorrechte erfordern. Die UAC unterstützt die Über-Schulter-Authentifizierung, sodass ein Administrator einem Programm erhöhte Rechte gewähren kann, während ein Standardbenutzer derzeit am System angemeldet ist.

Das UAC-Feature ist standardmäßig aktiviert. Obwohl es für einen Administrator möglich ist, UAC systemweit zu deaktivieren, hat dies eine Reihe negativer Auswirkungen. Erstens schwächt dies die Sicherheit aller Administrativen Konten, da alle Prozesse mit Administratoranmeldeinformationen ausgeführt werden würden, auch wenn die meisten Anwendungen sie nicht tatsächlich benötigen. Mit deaktivierter UAC kann eine Standardbenutzeranwendung, die eine ausnutzbare Sicherheitsanfälligkeit verfügbar macht, möglicherweise verwendet werden, um private Informationen zu stehlen, Rootkits oder Spyware zu installieren, die Systemintegrität zu zerstören oder Zombie-Angriffe auf andere Systeme zu hosten. Während das Ausführen der meisten Software als Standardbenutzer bei aktivierter UAC die potenziellen Schäden durch einen solchen Fehler erheblich begrenzt. Zweitens deaktiviert das Deaktivieren der UAC viele der Problemumgehungen für die Anwendungskompatibilität, die es echten Standardbenutzern ermöglichen, eine breite Palette von Anwendungen erfolgreich auszuführen. Das Deaktivieren von UAC sollte niemals als Kompatibilitätsumgehung empfohlen werden.

Es ist wichtig zu beachten, dass Anwendungen versuchen sollten, standardbenutzerrechte nur zu verwenden, wenn möglich. Administratoren können zwar die Rechte eines Prozesses auf einfache Weise erhöhen, aber die Rechteerweiterung erfordert immer noch Benutzerinteraktionen und bestätigungen, wenn eine Anwendung ausgeführt wird, für die Administratoranmeldeinformationen erforderlich sind. Diese Erhöhung muss auch zum Zeitpunkt des Starts des Programms erfolgen, sodass für einen einzelnen Vorgang auch für einen einzelnen Vorgang administrative Anmeldeinformationen erforderlich sind, dass das System für die gesamte Laufzeit der Anwendung ein größeres Risiko darstellt. Standardbenutzer ohne Möglichkeit, ihre Berechtigungen zu erhöhen, sind auch in Familien- und Unternehmenseinstellungen üblich. "Als Administrator ausführen" ist keine gute Problemumgehung für Kompatibilität, macht den Benutzer und das System zu einem größeren Sicherheitsrisiko verfügbar und führt in vielen Situationen zu Frustration für Benutzer.

Anmerkung

Das in Windows Vista eingeführte Feature "Benutzerkontensteuerung" ist auch in Windows 7 enthalten. Während die Benutzererfahrung beim Arbeiten mit den verschiedenen Systemfeatures im Hinblick auf die Benutzerkontensteuerung verbessert wurde, sind die Auswirkungen auf Anwendungen im Wesentlichen identisch. Alle Windows Vista-Empfehlungen in diesem Artikel gelten auch für Windows 7. Ausführliche Informationen zu den UAC-UI-Änderungen für Windows 7 finden Sie unter Benutzeroberfläche – Dialogfeld "Benutzerkontensteuerung".

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, 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 Prozessplätze auf Systemebene.

Das Administratorkonto hat sich seit der Veröffentlichung von Windows XP erheblich geändert. Zuvor erhielten alle Prozesse, die von einem Mitglied der Gruppe "Administratoren" gestartet wurden, Administratorrechte. Bei aktivierter UAC 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 durch potenzielle Fehler in den meisten Programmen reduziert 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 von Hilfsprogrammen 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ückstellen, um ihr Kennwort physisch einzugeben, um Rechte zu erhöhen. Da Konten, die durch Jugendschutz 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 arbeitet, sollte der Wechsel zur Benutzerkontensteuerung unter Windows Vista sehr einfach sein. Die meisten dieser Anwendungen funktionieren as-is, obwohl das Hinzufügen eines Anwendungsmanifests dringend empfohlen wird. (Manifeste werden weiter unten in diesem Thema in Festlegen der Ausführungsebene im Anwendungsmanifestbeschrieben.)

Dateizugriff als Standardbenutzer

Der Aspekt Ihres Spiels, der am stärksten von den Standardmäßigen Benutzereinschränkungen betroffen ist, ist die Dateisystemorganisation 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 müssen beispielsweise die Rechte eines Benutzers vom Betriebssystem erhöht werden, bevor eine Anwendung in den Ordner "Programme" schreiben kann. Um dies zu vermeiden, sollten Sie die Datendateien ihres Spiels 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 fördert, um globale und benutzerspezifische Dateien zu partitionieren.

Beim Versuch, eine Datei oder ein Verzeichnis unter einem Ordner zu erstellen oder zu schreiben, der keine Schreibberechtigung für den Prozess gewährt, schlägt unter Windows Vista fehl, wenn die Anwendung keine Administratorrechte besitzt. Wenn ihre ausführbare 32-Bit-Spieldatei im Legacymodus ausgeführt wird, da sie keine angeforderte Ausführungsstufe 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 Lese-/Schreibzugriff Lese-/Schreibzugriff Per-User 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 Lese-/Schreibzugriff Lese-/Schreibzugriff Per-User Benutzerspezifische Spieldateien, die gelesen und geändert werden und nur im Spielkontext verwendet werden. Spielecachedateien. Spielerkonfigurationen.
CSIDL_COMMON_APPDATA C:\ProgramData Lese-/Schreibzugriff, wenn Besitzer Lese-/Schreibzugriff Alle Benutzer 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 Lese-/Schreibzugriff Alle Benutzer Statische Spieldateien, die vom Installationsprogramm des Spiels geschrieben wurden, die von allen Benutzern gelesen werden. Spielressourcen wie 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 der ausführbaren Datei verwenden, wenn Sie Pfadzeichenfolgen zu Dateien oder Verzeichnissen generieren, die sich unter Ihrem Installationsordner befinden.

Sie sollten auch von hartcodierten Annahmen über die bekannten Ordnerpfade ablassen. Beispielsweise ist unter Windows XP Professional 64-Bit Edition und Windows Vista x64 der Pfad der Programmdateien 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 versteht diese bekannten Ordnerspeicherorte und verschenkt die Daten beim Upgrade des Betriebssystems von Windows XP. Im Gegensatz dazu schlägt die Verwendung von nicht standardmäßigen Speicherorten oder hartcodierten Pfaden nach einem Betriebssystemupgrade möglicherweise fehl.

Achten Sie auf die subtilen Benutzerfreundlichkeitsunterschiede zwischen den von CSIDL_PERSONAL und CSIDL_LOCAL_APPDATA angegebenen benutzerspezifischen Ordnern. Die empfohlene Methode zum Auswählen der CSIDL-Konstante zum Schreiben einer Datei 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 verwendet werden, um benutzerspezifische Datendateien zu speichern und zu organisieren, da es keinen Unterschied in ihrem Zugriffsbereich oder ihrer Berechtigungsstufe gibt. Achten Sie darauf, 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 als der Wert von MAX_PATH, 260 zu halten.

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 ähnlich wie das Dateisystem eingeschränkt. Einem Standardbenutzer ist lesezugriff auf alle Schlüssel in der Registrierung gestattet; Schreibzugriff wird jedoch nur der HKEY_CURRENT_USER -Unterstruktur (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 im Manifest enthält, werden alle Schreibvorgänge in HKEY_LOCAL_MACHINE\Software virtualisiert, während Schreibvorgänge an andere Speicherorte außerhalb HKEY_CURRENT_USER fehlschlagen.

Das Speichern dauerhafter Daten in der Registrierung, z. B. die Konfiguration eines Benutzers, wird nicht empfohlen. Die bevorzugte Methode zum Speichern dauerhafter Daten aus Ihrem Spiel besteht darin, die Daten in das Dateisystem zu schreiben, indem sie SHGetFolderPath aufrufen und den Wert einer CSIDL-Konstante abrufen, die im vorherigen Abschnitt beschrieben wird.

Rechteerweiterung

In Windows Vista müssen alle Anwendungen, die Administratorrechte erfordern, eine Anforderung für eine administrative Ausführungsebene im Manifest deklarieren (im nächsten Abschnitt beschrieben, Festlegen der Ausführungsebene im Anwendungsmanifest).

Die Rechteerweiterung ist, wie es bekannt ist, das von der UAC gesteuerte Verfahren, um einen Prozess in einen Verwaltungsprozess zu fördern. Die Rechte eines Prozesses können nur zur Erstellungszeit erhöht werden. Nach der Erstellung wird ein Prozess nie auf eine höhere Berechtigungsstufe heraufgestuft. Aus diesem Grund. Vorgänge, die Administratoranmeldeinformationen erfordern, sollten isoliert werden, um Installationsprogramme und andere Hilfsprogramme zu trennen.

Bei der Ausführung eines Programms prüft die UAC die angeforderte Ausführungsebene im Manifest und fordert den aktuellen Benutzer mit einem von zwei Standarddialogfeldern auf: eines für einen Standardbenutzer und einen 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. Eingabeaufforderung für einen Standardbenutzer zum Eingeben von Anmeldeinformationen für ein Administratorkonto

zur Eingabe von Anmeldeinformationen für ein Administratorkonto auffordern

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

Abbildung 2. Auffordern eines Administrators, Änderungen am Computer zu autorisieren

aufgefordert, dass ein Administrator Änderungen am Computer autorisiert

Die Anwendung erhält nur Administratorrechte, wenn ein Standardbenutzer die richtigen Administratoranmeldeinformationen bereitstellt oder ein Administratorbenutzer eine Bestätigung bereitstellt; alles andere bewirkt, dass die Anwendung beendet wird.

Es ist wichtig zu beachten, dass ein Prozess mit erhöhten Berechtigungen als Administratorbenutzer ausgeführt wird, der Anmeldeinformationen in die UAC-Eingabeaufforderung eingegeben hat, anstatt als Standardbenutzer, der aktuell angemeldet ist. Dies ist ähnlich wie RunAs in Windows XP, der Prozess mit erhöhten Rechten den Ordner und registrierungsschlüssel des Administrators beim Zugriff auf Benutzerdaten abruft, und alle Programme, die der erhöhte Prozess startet, erben auch die Administratorrechte und Die Speicherorte des Benutzerkontos. Für Administratoren, die zur Bestätigung aufgefordert werden (Continue oder Cancel), entsprechen diese Speicherorte den Speicherorten des aktuellen Benutzers. Im Allgemeinen sollten Prozesse, die eine Erhöhung erfordern, jedoch nicht auf Benutzerdaten pro Benutzer ausgeführt werden. Beachten Sie, dass sich dies erheblich darauf auswirken kann, wie Ihr Installationsprogramm ausgeführt werden muss! Wenn das Installationsprogramm, das als Administrator ausgeführt wird, in HKCU oder in das Profil eines Benutzers schreibt, kann es sehr gut an den falschen Speicherort schreiben. Erwägen Sie die Erstellung dieser Werte pro Benutzer bei der ersten Ausführung des Spiels.

UAC-Auswirkungen mit CreateProcess()

Der UAC-Erweiterungsmechanismus wird nicht von einem 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, wobei GetLastError-() ERROR_ELEVATION_REQUIRED zurückgegeben wird. CreateProcess() wird nur erfolgreich ausgeführt, wenn die Ausführungsebene des Angerufenen gleich oder kleiner als der des Aufrufers ist. Ein Prozess mit nicht erhöhten Rechten, der erhöhte Prozesse erstellen muss, sollte dies mithilfe der ShellExecute()-Funktion tun, wodurch der UAC-Erweiterungsmechanismus mithilfe der Shell ausgelöst wird.

Festlegen der Ausführungsebene im Anwendungsmanifest

Sie deklarieren die angeforderte Ausführungsstufe Ihres Spiels, indem Sie dem Anwendungsmanifest 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 vorherigen Code wird das Betriebssystem informiert, dass das Spiel nur standardbenutzerrechte durch das folgende Tag erfordert:

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

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

Das Betriebssystem kann informiert werden, dass ein Spiel rechteerweiterungen erfordert, indem "asInvoker" durch "requireAdministrator" ersetzt wird, um das folgende Tag zu erstellen:

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

Mit 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 ausführen muss, da dieses Dialogfeld nicht nur schnell lästig wird, sondern auch das Spiel mit jugendschutzwidrigen Steuerelementen inkompatibel macht. Denken Sie sehr sorgfältig nach, bevor Sie diese Anforderung zu einer ausführbaren Datei hinzufügen.

Ein häufiges Fehlverständnis besteht darin, dass das Hinzufügen eines Manifests, das requestedExecutionLevel auf "requireAdministrator" festlegt, die Notwendigkeit einer Eingabeaufforderung zur Erhöhung umgeht. Das stimmt nicht. 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 jeder Anwendung, die für die Erhöhung gekennzeichnet ist, bevor die UAC-Eingabeaufforderung angezeigt wird. Eine große ausführbare Datei, die für die Erhöhung markiert ist, dauert 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 selbst extrahieren, sollten daher als "asInvoker" gekennzeichnet werden, und alle Teile, die als "requireAdministrator" gekennzeichnet werden müssen, sollten in einer separaten ausführbaren Hilfsdatei platziert werden.

Das uiAccess-Attribut, das in den vorherigen Beispielen gezeigt wird, sollte für Spiele immer FALSE sein. Dieses Attribut gibt an, ob Benutzeroberflächenautomatisierungs-Clients Zugriff auf die geschützte System-UI haben und besondere Sicherheitsauswirkungen haben, wenn sie auf TRUE festgelegt sind.

Einbetten eines Manifests in Visual Studio

Die Manifestunterstützung wurde zunächst ab VS2005 zu Visual Studio hinzugefügt. Standardmäßig verfügt eine in Visual Studio 2005 (oder höher) integrierte ausführbare Datei über ein automatisch generiertes Manifest, das als Teil des Buildprozesses darin eingebettet ist. Der Inhalt des automatisch generierten Manifests hängt von bestimmten Projektkonfigurationen ab, die Sie im Dialogfeld "Projekteigenschaften" angeben.

Das manifest, das von Visual Studio 2005 automatisch 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 das Zusammenführen eines benutzerdefinierten Manifests mit dem <trustInfo> Block mit dem automatisch generierten Manifest zu ermöglichen. Dies ist so einfach wie das Hinzufügen einer *.manifest-Datei zu Ihrer Lösung, die den im vorherigen Abschnitt aufgeführten XML-Code enthält. Wenn Visual Studio auf eine MANIFEST-Datei in Ihrer Lösung trifft, wird automatisch das Manifesttool (mt.exe) aufgerufen, um die MANIFESTdateien mit der automatisch generierten Datei zusammenzuführen.

Anmerkung

Es gibt einen Fehler im Manifesttool (mt.exe), das von Visual Studio 2005 bereitgestellt wird, das 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 das Ergebnis, 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 explizit ein anderer Namespace im <trustInfo-> Block deklariert und die untergeordneten Knoten für den neuen Namespace definiert werden. Der im vorherigen Abschnitt bereitgestellte XML-Code veranschaulicht diesen Fix.

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 des XML-Codes 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 bereitgestellte mt.exe zu ersetzen.

Ab Visual Studio 2008 können Sie nun die Ausführungsebene einer Anwendung im Dialogfeld "Projekteigenschaften" (Abbildung 3) oder mithilfe des /MANIFESTUAC-Linker-Flags angeben. Wenn Sie diese Optionen festlegen, wird Visual Studio 2008 dazu führen, dass ein Manifest automatisch generiert und eingebettet wird, das mit dem entsprechenden <trustInfo> Block in die ausführbare Datei integriert wird.

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

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 dazu finden Sie unter dem Visual Studio 2003-Projekt, das in jedem Beispiel im DirectX SDK vor der Version vom März 2008 enthalten ist.

UAC-Kompatibilität mit älteren Spielen

Wenn Ihr Spiel scheint, eine Datei erfolgreich im Verzeichnis "Programme" zu speichern und zu laden, wird jedoch kein Nachweis für die Datei iOn Windows Vista, eine 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 die erforderlichen Änderungen nicht vorgenommen, um auf eingeschränkten Benutzerkonten unter Windows XP ordnungsgemäß zu arbeiten. Unter Windows Vista würden diese Anwendungen jedoch aufgrund unzureichender Zugriffsberechtigungen unter dem neuen Sicherheitsmodell fehlschlagen, das die Standardmäßige Benutzerausführung für Ältere Anwendungen erzwingt. Um die Auswirkungen dieser Auswirkungen zu verringern, wurde die Virtualisierung auch windows Vista hinzugefügt. Durch die Virtualisierung funktionieren Tausende von Legacyanwendungen gut unter Windows Vista, ohne dass diese Anwendungen jederzeit über erhöhte Berechtigungen verfügen müssen, um nur bei einigen kleineren Vorgängen erfolgreich zu sein. gefunden, die Wahrscheinlichkeit, dass Ihr Spiel im Legacymodus ausgeführt wird und der Virtualisierung unterzogen wurde.

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

C:\\Programme\\Firmenname\\Titel\\config.ini

der Schreibvorgang wird automatisch an Folgendes umgeleitet:

C:\\Benutzer\\Benutzername\\AppData\\Local\\VirtualStore\\Programme\\Firmenname\\Titel\\config.ini

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

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

sie wird stattdessen zu:

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

Dateien und Registrierungsschlüssel, die von der Virtualisierung betroffen sind, werden nur von Datei- und Registrierungsvorgängen aus virtualisierten Anwendungen aufgerufen, die als aktueller Benutzer ausgeführt werden.

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

Abbildung 4. Virtualisierungsprozess

Virtualisierungsprozess

Wenn eine Ältere Anwendung versucht, einen Lesevorgang an systemsensitiven Speicherorten im Dateisystem oder in der Registrierung durchzuführen, werden die virtuellen Speicherorte zuerst 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, sodass es wichtig ist, 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. Die Virtualisierung ist auch für Endbenutzer nicht offensichtlich. Auch wenn die Virtualisierung die Ausführung Ihrer Anwendung ermöglichen kann, kann sie Supportanrufe generieren und es für diese Kunden schwierig machen, probleme zu schießen.

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

Legacyszenarien und Manifeste

Für die meisten Verwendungsszenarien reicht das einfache Markieren der .exe mit den richtigen UAC-Manifestelementen und sicherstellen, dass die Anwendung ordnungsgemäß funktioniert, da ein Standardbenutzer für eine hervorragende UAC-Kompatibilität ausreicht. Die meisten Spieler führen Windows Vista oder Windows 7 mit aktivierter Benutzerkontensteuerung aus. Für Windows XP und Benutzer unter Windows Vista oder Windows7 mit deaktivierter Benutzerkontensteuerung werden sie in der Regel mit Administratorkonten ausgeführt. Obwohl dies ein weniger sicherer Betriebsmodus ist, treten in der Regel keine zusätzlichen Kompatibilitätsprobleme auf, obwohl die Deaktivierung von 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 unter 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, und daher funktionieren diese Programme wie erwartet. Windows XP Restricted Users and Standard Users running on Windows Vista or Windows 7, will always run these programs with restricted rights and all administrator-level operations will fail. Daher wird empfohlen, dass Programme, die als "requiretAdministrator" gekennzeichnet sind, IsUserAnAdmin beim Start aufrufen und eine schwerwiegende Fehlermeldung anzeigen, wenn FALSCH zurückgegeben wird. Für das oben genannte Szenario wird dies immer erfolgreich sein, bietet jedoch eine bessere Benutzererfahrung und eine klare Fehlermeldung für diese seltene Situation.

Schlussfolgerung

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

Anwendungen, die ordnungsgemäß so konzipiert sind, dass sie mit den Anmeldeinformationen eines Standardbenutzers (oder eingeschränkter Benutzer) unter früheren Versionen von Windows arbeiten, werden nicht von der UAC beeinflusst, die ohne Erhöhung ausgeführt wird. Sie sollten jedoch ein Manifest enthalten, dessen angeforderte Ausführungsebene auf "asInvoker" festgelegt ist, um den Anwendungsstandards für Vista zu entsprechen.

Weitere Lektüre

Hilfe beim Entwerfen von Anwendungen für Windows Vista, die mit der Benutzerkontensteuerung kompatibel sind, laden Sie das folgende Whitepaper herunter: Windows Vista-Anwendungsentwicklungsanforderungen für die Kompatibilität von 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 Benutzererfahrung in Windows Vista beschrieben.

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

Eine weitere nützliche Ressource ist der Artikel Lehren Sie Ihre Apps mit der Windows Vista-Benutzerkontensteuerung, von 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 zum Fix für mt.exefinden Sie im Tool, das von Visual Studio 2005 zum automatischen Zusammenführen und Einbetten eines Manifests in eine ausführbare Datei verwendet wird, finden Sie unter Exploring Manifests Part 2: Default Namespaces and UAC Manifests in Windows Vista auf Chris Jacksons Blog auf MSDN.