Windows Vista für Entwickler: Kochbuch zur Anwendungskompatibilität

Veröffentlicht: 23. Okt 2006

Von Microsoft Corporation

Machen Sie sich damit vertraut, wie Sie die Kompatibilität Ihrer Anwendungen mit Windows Vista überprüfen können.

Windows Vista für Entwickler enthält Inhalte für Entwickler, sonstige Technologie-Experten und Manager, die an einer vertieften Untersuchung von einigen der neuen und erweiterten Eigenschaften von Windows Vista interessiert sind. Der Text wird vom Windows Vista-Entwicklungszentrum in der Form von Artikeln veröffentlicht, die im Abstand von etwa zwei Wochen erscheinen. Diese Artikel sind nur eine Zusammenfassung der Datei Windows-Hilfe, die hier heruntergeladen werden kann.

Hinweis   Dieser Artikel bildet eine Dokumentation zu einer Softwarevorabversion. Änderungen in zukünftigen Versionen sind vorbehalten.

Hinweis   Feedback zu den Artikeln können Sie gerne per E-Mail an Vistadev@microsoft.com senden.

Auf dieser Seite

 Einführung
 Dreißigminütige Kompatibilitäts-Prüfung
 Betriebssystem-Versioning
 Benutzerkontenkontrolle
 Benutzerkontenkontrolle - Richtlinien zur Anwendungsaktualisierung
 Windows Resource Protection (WRP)
 Internet Explorer - Geschützter Modus
 Windows Vista 64-bit
 Microsoft Graphical Identification and Authentication (GINA)
 Session 0 Isolierung
 Netzwerk: TCP/IP-Liste und die Windows-Filterplattform
 Netzwerk: Kernel-Modus IP-Hilfsprogramm-APIs
 Netzwerk: IPv6
 Kompatibilitätsrisiken
 Hilfe- und Supportzentrum
 Assistentenplattformclient
 Standardprogramme
 Programmkompatibilitätsassistent in Windows Vista - vorliegende Dokumentation
 Graphical Device Interface (GDI)
 Painting (WM_PAINT) Verhaltensunterschiede
 Wiedergabeleistung
 UIPI (GUI- Teil der Benutzerkontenkontrolle)
 Hohe Dpi-Skalierung
 PNG-Symbole
 Named Pipe-Härtung
 SPAP Deprecation (Pstore)
 WMI-Anbieter: Standardsicherheits-Hosting-Modell
 Volumenschattenkopie-Dienst
 Standard-Benutzeranalyzer
 Hilfemodul-Support
 Siehe auch

Einführung

Microsoft Windows Vista ist das Betriebssystem und die Softwareentwicklungsplattform der nächsten Generation ein, wie es von Anwendungsentwicklern und Unternehmen weltweit benutzt wird. Als Teil der Verstärkung der Sicherheit und der Benutzererfahrung von Windows Vista wurden viele neue Eigenschaften eingeführt und vorhandene Eigenschaften verbessert.

Obwohl Windows Vista mit den meisten für Microsoft Windows XP, Microsoft Windows Server 2003 und deren Service Packs geschriebenen Anwendungen problemlos kompatibel ist, ist ein gewisser Grad an Nichtkompatibilität auf Grund von Innovationen, Verschärfung der Sicherheitsmaßnahmen und erhöhter Zuverlässigkeit unvermeidlich. Insgesamt ist die Kompatibilitätsrate von Windows Vista hoch, und Microsoft bemüht sich beständig darum, bei Windows Vista die bestmöglichen Kompatibilitätslösungen für vorhandene Anwendungen zu erzielen.

Dieses Dokument repräsentiert einen ersten Schritt für Anwendungsentwickler, um sich mit der Methode zur Überprüfung der Kompatibilität ihrer Anwendungen vertraut zu machen. Es liefert auch einen Überblick über die wenigen bekannten Inkompatibilitätsprobleme bestimmter Anwendungen bei Windows Vista und Links zu detaillierten Weißbüchern und sonstigen Entwicklungsanweisungen.

Mehrere neue Eigenschaften ermöglichen es dem Entwickler, bei Anwendungen Fehler zu suchen und um sie herum zu manövrieren, die unter Windows Vista nicht richtig funktionieren, wie etwa folgende:

• Kompatibilitätsregister

  Benutzer können die Kombination oder die EXE-Datei rechtsklicken und den Windows XP SP2-Kompatibilitätsmodus anwenden, damit die Anwendung so funktioniert wie in Windows XP. Außerdem kann der Benutzer das Kommando Dieses Programm als Administrator ausführen wählen, wenn die Anwendung Administratorrechte braucht, und der Benutzer diese Rechte besitzt. Weitere Informationen erhalten Sie weiter unten unter dem Abschnitt „Benutzerkontenkontrolle“.

 

Dreißigminütige Kompatibilitäts-Prüfung

Dieser Abschnitt behandelt das erfolgreiche Testen und Beurteilen der Kompatibilität einer Anwendung mit Windows Vista. Es gibt zwei hauptsächliche Schrittfolgen, um die Kompatibilität mit Windows Vista testen:

Arbeit mit einer sauberen Installation von Windows Vista

• Installieren Sie Windows Vista auf einem Testcomputer.

• Installieren Sie die Anwendung in Windows Vista. Wird eine Aufforderung angezeigt, die die Erlaubnis anfordert, die Anwendung zu installieren, klicken Sie auf Erlauben und fahren Sie fort. Ist die Installation erfolgreich, gehen Sie zu Schritt 6 über.

• Versagt die Anwendungsinstallation und wurde keine Aufforderung angezeigt, die Installation zu erlauben, dann rechtsklicken Sie auf die Datei Installer EXE und wählen Sie Dieses Programm als Administrator ausführen und installieren Sie die Anwendung neu. Ist die Installation erfolgreich, gehen Sie zu Schritt 6 über.

Hinweis Dieser Schritt ist nicht erforderlich, wenn zur Installation eine MSI-Datei benutzt wird.

• Bei Erhalt von Fehlermeldungen wie OS-Version, CLSID-Registrierung oder Dateikopie rechtsklicken Sie auf die Datei Installer EXE, wählen Sie das Kompatibilitätsregister und danach den Windows XP SP2-Kompatibilitätsmodus.

• Gehen Sie zurück zu Schritt 2. Können Sie die Anwendung nicht installieren, gehen Sie zu Schritt 9 über.

• Die Anwendung sollte jetzt installiert sein.

• Starten Sie die Anwendung. Startet die Anwendung nicht richtig oder werden Fehler angezeigt, wenden Sie den Windows XP SP2-Kompatibilitätsmodus auf die EXE-Datei der Anwendung an und versuchen Sie es erneut.

• Startet die Anwendung erfolgreich, führen Sie die vollständige Testreihe aus, die normalerweise auch für das Testen von Anwendungen bei Windows XP benutzt werden. Überprüfen Sie die Funktionalität Ihrer Anwendung und bestätigen Sie, dass die Anwendung richtig läuft. Wenn alle Hauptfunktionalitätstests bestanden sind, gehen Sie zu Schritt 10 über.

• Kann die Anwendung nicht installiert oder erfolgreich gestartet werden bzw. stürzt sie ab, begegnet einem Fehler oder besteht wichtige Funktionalitätstests nicht, handelt es sich vermutlich um eine der wenigen Anwendungen, die von Änderungen bei Windows Vista betroffen sind. Benutzen Sie die Themen in diesem Dokument, um Ihre Anwendung zu überprüfen.

• Sie haben alle Schritte erfolgreich durchgeführt.

Arbeit mit einem Upgrade vom Windows XP Service Pack 2

1. Installieren Sie Windows XP SP2 auf einem Testcomputer und installieren Sie dann die Anwendung. Überprüfen Sie die gesamte Funktionalität der Anwendung, bevor Sie fortfahren.

2. Rüsten Sie den Testcomputer auf Windows Vista auf. Folgen Sie den Einrichtungs- und Aufrüstungsanweisungen von Windows Vista. Ist der Upgrade vollständig, melden Sie sich wie bei Windows XP an.

3. Starten Sie die Anwendung. Startet die Anwendung nicht richtig oder werden Fehler angezeigt, wenden Sie den Windows XP SP2-Kompatibilitätsmodus auf die EXE-Datei der Anwendung an und versuchen Sie es erneut.

4. Startet die Anwendung erfolgreich, führen Sie die vollständige Testreihe aus, die normalerweise auch für das Testen von Anwendungen bei Windows XP benutzt werden. Überprüfen Sie die Funktionalität Ihrer Anwendung und bestätigen Sie, dass die Anwendung richtig läuft. Wenn alle Hauptfunktionalitätstests bestanden sind, gehen Sie zu Schritt 6 über.

5. Kann die Anwendung nicht installiert oder erfolgreich gestartet werden bzw. stürzt sie ab, begegnet einem Fehler oder besteht wichtige Funktionalitätstests nicht, handelt es sich vermutlich um eine der wenigen Anwendungen, die von Änderungen bei Windows Vista betroffen sind. Benutzen Sie die Themen in diesem Dokument, um Ihre Anwendung zu überprüfen.

6. Sie haben alle Schritte erfolgreich durchgeführt.

Wenn beide Schrittfolgen erfolgreich beendet wurden und die Anwendung richtig gelaufen ist, dann funktionieren die Anwendungen unter Windows Vista. Informationen über den Erhalt einer Zertifizierung Ihrer Anwendung finden Sie auf der Windows Vista-Homepage.

Links

• Windows Internet Explorer 7: Beta 2 Vorschau IT Pro Checkliste

• Windows Vista-Homepage

 

Betriebssystem-Versioning

Auswirkung der Funktion

Hoch

Kurze Beschreibung

Die interne Versionsnummer von Windows Vista ist 6. Die Funktion GetVersion sendet bei Anfragen diese Versionsnummer an Anwendungen zurück.

Hinweis Es handelt sich um die nächste Hauptversionsnummer nach Windows XP (Version 5.x).

Erscheinungsform

Diese Versionsänderung manifestiert sich sehr anwendungsspezifisch, wie im Folgenden zu ersehen:

• Jegliche Anwendung, die spezifisch die OS-Nummer überprüft, erhält eine höhere Versionsnummer.

• Anwendungs-Installer können selbst die Installierung der Anwendung verhindern, und Anwendungen können selbst ihren Start verhindern.

• Anwendungen können Benutzer warnen und dennoch weiterhin richtig funktionieren.

• Einige Anwendungen können instabil werden oder abstürzen.

Minderung des Problems

Die meisten Anwendungen funktionieren richtig unter Windows Vista, weil die Anwendungskompatibilitätsrate von Windows Vista sehr hoch ist. Jedoch ist bei Windows Vista für Anwendungen und Installer, die die OS-Version überprüfen, ein Kompatibilitätsmodus vorgesehen.

Benutzer können die Kombination oder die EXE-Datei rechtsklicken und den Windows XP SP2-Kompatibilitätsmodus vom Kompatibilitätsregister anwenden. In den meisten Fällen sollte dies dazu führen, dass die Anwendung genauso funktioniert wie unter Windows XP, ohne dass Veränderungen an der Anwendung vorgenommen werden müssen.

Behelfsmaßnahmen

• Im Allgemeinen sollten Anwendungen keine Überprüfungen von OS-Versionen ausführen bzw. mindestens immer Version 6 (oder eine höhere Version) als OS akzeptieren. Dieses Verhalten sollte befolgt werden, es sei denn, es besteht ein sehr spezifischer rechtlicher, geschäftlicher oder Systemkomponentenbedarf einer Versionsüberprüfung.

• Anwendungs-Installer sollten keine 16-Bit-Installer benutzen, um die 64-Bit-Systemkompatibilität zu gewährleisten.

• Vergewissern Sie sich, dass alle von einer Anwendung benutzten Treiber möglichst Benutzermodus-Treiber sind, um die Multiplattform-Kompatibilität (32-Bit und 64-Bit) aufrechtzuerhalten.

 

Benutzerkontenkontrolle

Auswirkung der Funktion

Hoch

Kurze Beschreibung

Ein grundlegender Schritt zur Erhöhung der Sicherheit von Windows besteht darin, interaktiven Benutzern die Verwendung eines Standardbenutzerkontos zu ermöglichen, das ihnen lediglich einen begrenzten Satz an Berechtigungen und Rechten gewährt. In der Standardeinstellung wird jede Anwendung in Windows Vista mit den Rechten eines Standardbenutzers ausgeführt, auch wenn Sie sich als Mitglied der Administratorgruppe anmelden. Wenn hingegen Benutzer versuchen, eine Anwendung zu starten, für die Administratorberechtigungen erforderlich sind, werden sie explizit nach einer Bestätigung dafür gefragt. Systemeinstellungen, globale Einstellungen und Verhaltensweisen können nur durch Anwendungen geändert werden, die mit Administratorrechten ausgeführt werden. Dieses Feature von Windows Vista wird als Benutzerkontensteuerung (User Account Control, UAC) bezeichnet.

Erscheinungsform

• Speziell entwickelte Installer, Uninstaller und Updater werden eventuell nicht gefunden und müssen auf der Administratorebene ausgeführt werden.

• Standardbenutzeranwendungen, die die Rechte von Administratoren erfordern, um ihre Aufgaben zu erfüllen, können versagen bzw. die betreffende Aufgabe dem Standardbenutzer nicht zur Verfügung stellen.

• Anwendungen, die versuchen, Aufgaben durchzuführen, für die der aktuelle Benutzer nicht die notwendigen Genehmigungen besitzt, können versagen. Wie das Versagen sich manifestiert, hängt davon ab, wie die Anwendung geschrieben wurde.

• Systemsteuerungsanwendungen, die administrative Aufgaben ausführen und globale Veränderungen vornehmen, funktionieren eventuell nicht richtig und versagen.

• DLL-Anwendungen, den mithilfe der Datei RunDLL32.EXE laufen, funktionieren eventuell nicht richtig, wenn sie globale Aufgaben ausführen.

• Anwendungen für Standardbenutzer, die auf globale Adressen schreiben, werden durch Virtualisierung auf Pro-Benutzeradressen umgeleitet.

Behelfsmaßnahmen

Schnelle Lösung für benutzerdefinierte Installer:

• Ein Benutzer kann den Installer bzw. Updater starten, indem er rechtsklickt und Dieses Programm als Administrator ausführen wählt.

• Wenden Sie bezüglich der Anwendungskompatibilität eine Fehlerbehebung an, um anzuzeigen, dass bestimmte Installer der Erweiterung bedürfen. Dazu rechtsklicken Sie die Kombination oder die EXE-Datei und wenden den Windows XP SP2-Kompatibilitätsmodus vom Kompatibilitätsregister an.

Schnelle Lösung für Anwendungen, für die man administrative Rechte braucht, um Systemmodifizierungen durchzuführen bzw. auf privilegierte Zonen zu schreiben:

• Firmenbenutzer können eine Fehlerbehebung bei der Anwendungskompatibilität anwenden, um zu zeigen, dass die Legacy-Anwendung der Genehmigung seitens des Administrators bzw. der Rechte des Administrators bedarf, um richtig zu laufen.

• Die Reduzierung der Beschränkungen von Zugriffskontrolllisten (Access Control Lists, ACLs) auf bestimmte beschränkte Dateien kann Anwendungen helfen, die versuchen, auf diese Dateien zu schreiben.

• Sehen Sie in den virtualisierten Ordnern bzw. Registrierungsschlüsseln nach, um festzustellen, ob die Anwendungen auf etwas zugreifen, das Administratorrechte erfordert. Diese Informationen können dazu dienen, die Anforderungen des Zugriffs auf administratorgeschützte Orte aus zukünftigen Versionen der Anwendung zu entfernen. Weitere Informationen über virtualisierte Dateien, Ordner und Standorte bzw. Adressen finden Sie im Abschnitt „Links“.

• Binden Sie den DLL-Aufruf „DLL als Anwendung ausführen“ in eine eigene EXE-Datei ein und fügen Sie ein Manifest für diese EXE-Datei bei, dass sie erweiterter Rechte bedarf.

Kompatibilitätstest:

• Jegliche Schrittfolge zum Installieren, Uninstallieren und Hochrüsten sollte den Benutzer zur Zustimmung bzw. zur Abgabe von Anmeldeinformationen auffordern. Nach Erhalt der Genehmigung sollte die Aktion erfolgreich verlaufen.

• Versuchen Sie, die versagende Schrittfolge als eingebauter Administrator zu wiederholen. Funktioniert diese Schrittfolge, ist das Versagen wahrscheinlich eine Folge mangelnder Rechte.

• Benutzen Sie das Prädiktortool der Benutzerkontenkontrolle aus dem Kompatibilitätsadministrator des Anwendungskompatibilitäts-Toolkits, um diejenigen Zonen einer Anwendung kenntlich zu machen, die die Aufgaben von Administratoren erfüllen.

Setzen Sie die Windows Vista-Kapazitätslösung ein:

• Windows Vista-basierte Anwendungen müssen:

  • Folgen Sie den im Windows Vista LOGO-Programm und in der Benutzererfahrungsdokumentation vorgeschriebenen Anweisungen (siehe Abschnitt „Links“).

  • Benutzen Sie eingebettete Manifeste, um deren besonderen RequestedExecutionLevel (früher unter der Bezeichnung RunLevel bekannt) anzuzeigen.

  • Trennen Sie alle administrativen und nicht-administrativen Funktionen in getrennte EXE-Dateien. Alle höhere Rechte benötigenden Funktionen sollten in getrennten ausführbaren EXE-Dateien

• Bei Anwendungen, die nicht spezifisch administrativ angelegt sind, modifizieren Sie den Code, um die Notwendigkeit von Administrator-Genehmigungen bzw. Rechten zu beseitigen.

• Bei Anwendungen, die nur von Administratoren benutzt werden, markieren Sie die Anwendung, sodass sie mit Administrator-Genehmigungen bzw. Rechten läuft.

• Bei der Aktualisierung einer Anwendung benutzen Sie eine getrennte Updater EXE-Datei zur Aktualisierung der Zielanwendung.

• Systemsteuerungsanwendungen müssen von .cpl-Dateien auf .exe-Dateien umgeschrieben werden und ein Manifest für ihre EXE-basierten Systemsteuerungsanwendungen enthalten, dass die erforderliche Ausführungsebene angibt.

• DLL-Dateien, die unter RunDLL32.EXE laufen und der Elevation bedürfen, sollten zu ausführbaren EXE-Dateien umgewandelt werden, deren Elevationsebene im zugehörigen Manifest erkennbar ist.

• Öffnen Sie Dateien und Registrierungsschlüssel möglichst nur mit schreibgeschütztem Zugriff. Benutzen Sie den Lese- und Schreibzugriff nur bei Bedarf und fahren Sie die Genehmigungen auf schreibgeschützten Zugriff zurück, sobald die Ausführung beendet ist.

Links

• Windows Vista-Sicherheit

• Windows Vista-Benutzerkontenkontrolle - Hauptseite

• Einstieg in die Funktion „Benutzerkontenkontrolle“ (User Account Control, UAC)

• Beste Praktiken und Anweisungen für Entwickler in einem Umfeld der geringsten Rechte

• Windows Vista-Benutzererfahrung

• Datei- und Registrierungsvirtualisierungsdetails

• Dias von der Microsoft Professional Developers Conference (PDC) 2005; Suche nach FUN406

• UACBlog

• UAC-bezogene Frage in den Microsoft-Foren

• Aaron Margosis' Weblog; Suche nach „Nicht als Administrator ausführen“

 

Benutzerkontenkontrolle - Richtlinien zur Anwendungsaktualisierung

Auswirkung der Funktion

Träger

Kurze Beschreibung

Viele vorhandene Anwendungen tendieren zur Einbeziehung einer Update-Funktionalität in ihre Anwendung. Das Ziel der Einbettung einer Update-Funktionalität ist es, sicherzustellen, dass der Client mit dem neuesten Binary läuft, dass der ISV („Independent Software Vendor“) anbieten kann.

Es wurde festgestellt, dass eine Reihe von Anwendungen bei der Ausführung ihrer Update-Funktionen mehr Rechte brauchen als die eines Standardbenutzers. Häufig müssen die Pro-Computer-Dateien, die während der Installation abgelegt wurden, gepflegt werden. Gemäß dem UAC-Modell zur Ausführung und Installation von Anwendungen verfügt nur der Administrator mit erweiterten Rechten im Modus „Admin Approval Mode Admin“ über ausreichende Rechte zur Ausführung dieser Aktionen.

Die Windows Vista-Installererkennungsheuristik erkennt die Updater von vielen Anwendungen richtig und erweitert das Updater-Verfahren entsprechend, sodass der Update bei Elevation erfolgreich beendet wird. Jedoch gibt es immer noch einige Zonen, wo Updates nicht erfolgreich ausgeführt werden können. Beispiel:

• „Out of Process Updaters not Install Detected“ – der betreffende Updater wird über die Installierungserkennungsheuristik nicht erkannt.

• „Mehrzweck-EXE-Dateien / In-Process-Updates“ – Überladene ausführbare Dateien erfüllen mehr als eine Aufgabe. Zum Beispiel ist der Binary sowohl die Hauptanwendung als auch aktualisierende Anwendung ODER die ausführbaren Dateien mit mehreren Zwecken laufen als Thread innerhalb der Anwendung.

Erscheinungsform

Die Update-Funktionalität der Anwendung versagt

Behelfsmaßnahmen

Out of Process Updaters not Install Detected (Out of Process-Updater als nicht installiert erkannt)

• Dieses Problem kann innerhalb von Unternehmen auftreten und dazu führen, dass das Unternehmen fordert, eine Anwendung mit Administrator-Rechten laufen zu lassen. Aktualisiert eine Anwendung sich mithilfe eines getrennten Prozesses, bei dem kein Installer erkannt wurde, selbst, sollte dieser getrennte Prozess mithilfe der Anwendungsfehlerbehebung als nur für Benutzer mit Administrator-Rechten zugänglich markiert werden.

• Updater, die nicht als Benutzer fungieren, untersagen einem Unternehmen mit geringsten Rechten zu laufen.

• Der Updater sollte als getrennter Prozess mit der gewünschten Ausführungsebene „Administrator erforderlich“ geschrieben werden.

  • Dieser Prozess sollte nur dann ausgeführt werden, wenn dies zu Update-Zwecken notwendig ist. Die Prüfung, ob das Programm Updates benötigt, sollte als Benutzer durchgeführt werden.

„Mehrzweck-EXE-Dateien / In-Process-Updates“

In Vista gibt es keine vernünftige Methode, eine Mehrzweck-EXE-Datei zu erstellen, die Updates durchführt, weil man den Status, unter dem die EXE-Datei läuft, nicht umschalten kann. Dementsprechend muss die ausführbare Datei immer als Administrator ausgeführt werden. Stattdessen sollten Anwendungen bei der Durchführung von Updates nach einer der folgenden Methoden vorgehen.

1. Anwendung von Patching-Technologie in der MSI-Datei (die neueren Versionen von Windows Installer, InstallShield, Wise usw. unterstützen diese Methode).

   • Die MSI-Datei ist eine wichtige Installer-Technologie, weil sie die Fähigkeit besitzt, Updates für Sie zu managen.

   • Benutzen Sie die MSI-Datei zur Erstellung ihres Erstinstallers und betten Sie ein Zertifikat in die MsiPatchCertificate-Tabelle ein.

   • Erstellen Sie einen Update für Ihre Anwendung und signieren Sie es mit dem zuvor angegebenen Zertifikat.

   • MSI führt die Elevation für die Anwendung durch, wenn sie den Patch setzt.

     Hinweis   Der Hauptvorteil dieser Methode gegenüber anderen liegt darin, dass sie auf der Ebene Standardbenutzer funktioniert und die Sicherheit garantiert. Sie sorgt für eine schönere Benutzererfahrung, weil das Standardbenutzerkonto keinen Administrator bitten muss, den Patch zu installieren bzw. permanente Administrator-Rechte beantragen muss, um hier mitmachen zu können.

2. Benutzung anderer kundenspezifischer Installer-Mechanismen.

   • In Bezug auf Unternehmensumgebungen wird davon abgeraten, weil es dem Benutzer verbietet, die Ausführung als Nicht-Administrator vorzunehmen.

   • Der Updater sollte als getrennter Prozess mit der gewünschten Ausführungsebene „Administrator erforderlich“ geschrieben werden.

     Hinweis   Dieser Prozess sollte nur dann ausgeführt werden, wenn dies zu Update-Zwecken notwendig ist. Die Prüfung, ob das Programm Updates benötigt, sollte als Benutzer durchgeführt werden.

3. Aktualisierung („Updating“) bei der Ausführung von „Standardbenutzer“-Anwendungen.

   • Aktualisierungen können bei Benutzung der ClickOnce-Technologie auf der Ebene Standardbenutzer vorgenommen werden. Dabei handelt es sich um eine Plattform, mit deren Hilfe der Benutzer darin enthaltene Anwendungen einsetzen und die Aktualisierung für den Anwendungsschreiber handhaben kann.

Links

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/patching_and_upgrades.asp

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/least_privileged_user_account__lua__patching.asp

https://msdn.microsoft.com/msdnmag/issues/04/05/ClickOnce/

 

Windows Resource Protection (WRP)

Auswirkung der Funktion

Hoch (sperrt die Anwendung in Bezug auf Installierung und Ausführung)

Kurze Beschreibung

Als Initiative zur Verstärkung der Systemstabilität, Vorhersagbarkeit und Zuverlässigkeit soll Windows Resource Protection (WRP) das Windows-System im schreibgeschützten Zustand schützen. Dies betrifft bestimmte Dateien, Ordner und Registrierungsschlüssel. Updates von geschützen Ressourcen können nur durch in Bezug auf das Betriebssystem vertrauenswürdige Installer erfolgen, wie etwa Windows Servicing. Dadurch können Komponenten und Anwendungen, die mit dem OS mitgeliefert werden, besser vor Einflüssen von anderen Anwendungen und Administratoren geschützt werden.

Erscheinungsform

Anwendungen und Administratoren können geschützte OS-Ressourcen nicht ersetzen bzw. modifizieren, was sich folgendermaßen auswirkt:

• Anwendungsinstaller, die versuchen, von der WRP geschützte OS-Dateien bzw. Registrierungsschlüssel zu ersetzen, zu modifizieren oder zu löschen, können mit einer Fehlermeldung versagen, die anzeigt, dass die Ressource nicht aktualisiert werden konnte. Das liegt daran, dass der Zugriff auf diese Ressourcen verweigert wird.

• Anwendungen, die versuchen, auf geschützte Registrierungsschlüssel neue Registrierungsschlüssel bzw. -werte zu schreiben, können mit einer Fehlermeldung versagen, die anzeigt, dass die Änderung nicht zustande kam, weil der Zugriff verweigert wurde.

• Anwendungen, die versuchen, auf geschützte Ressourcen zu schreiben, können versagen, wenn sie sich auf Registrierungsschlüssel bzw. -werte verlassen.

Beispiele für die geschützten Systemzonen:

• Die Mehrheit der Windows-basierten ausführbaren Dateien sind von der WRP geschützt. Standardmäßig zeigen die folgenden Dateierweiterungen WRP-geschützte Dateien an:

  • .acm, .ade, .adp, .app, .asa, .asp, .aspx, .ax

  • .bas, .bat, .bin

  • .cer, .chm, .clb, .cmd, .cnt, .cnv, .com, .cpl, .cpx, .crt, .csh

  • .dll, .drv, .dtd

  • .exe, .fxp, .grp

  • .h1s, .hlp, .hta

  • .ime, .inf, .ins, .isp, .its

  • .js, .jse, .ksh, .lnk

  • .mad, .maf, .mag, .mam, .man, .maq, .mar, .mas, .mat, .mau, .mav, .maw, .mda, .mdb, .mde, .mdt, .mdw, .mdz, .msc, .msi, .msp, .mst, .mui

  • .nls, .ocx, .ops

  • .pal, .pcd, .pif, .prf, .prg, .pst

  • .reg, .scf, .scr, .sct, .shb, .shs, .sys

  • .tlb, .tsp, .url

  • .vb, .vbe, .vbs, .vsmacros, .vss, .vst, .vsw

  • .ws, .wsc, .wsf, .wsh

  • .xsd, .xsl

• Standardmäßig gehören die meisten COM OS-Registrierungsschlüssel zu den geschützten Registrierungsschlüsseln wie zum Beispiel:

  • HKEY_CLASSES_ROOT\Interface\{GUID}

  • HKEY_CLASSES_ROOT\Interface\{GUID}\NumMethods

  • HKEY_CLASSES_ROOT\Interface\{GUID}\ProxyStubClsid

  • HKEY_CLASSES_ROOT\Interface\{GUID}\ProxyStubClsid32

• Eine Mindestanzahl von Ordnern ist WRP-geschützt. Dazu gehören die Ordner, die ausschließlich von OS-Ressourcen benutzt werden, zum Beispiel einige der inetpub-Ordner, wie etwa:

  • $(runtime.bootDrive)\inetpub\uddi\webroot\details\

  • $(runtime.bootDrive)\inetpub\uddi\webroot\edit\

  • $(runtime.bootDrive)\inetpub\uddi\webroot\controls\

  • $(runtime.bootDrive)\inetpub\uddi\bootstrap\

Erleichterungen

Achtung! Die folgende Erleichterung wird nicht angewandt, wenn die Anwendung als Windows Vista-basierte Anwendung erkannt wird.

Bei gut bekannten Installern, werden „Zugriff verweigert“-Fehler unter folgenden Bedingungen unterdrückt:

• Bei Erkennung eines Anwendungsinstallers als Legacy-Installer (d. h. einen Installer, der kein Manifest besitzt).

• Bei einem „Zugriff verweigert“-Fehler, der darauf zurückzuführen ist, dass die Anwendung versucht, eine WRP-Ressource zu erstellen bzw. zu modifizieren.

• In einigen Fällen tritt die Erleichterung automatisch ein, wenn an WRP-geschützten Ressourcen Löschversuche vorgenommen werden.

• Versucht eine Anwendung einen neuen Unterschlüssel bzw. -wert unter einem WRP COM-Registrierungsschlüssel zu schaffen, kann ein „Zugriff verweigert“-Fehler auftreten.

Hinweis In diesem Fall wird Erfolg gemeldet, obwohl keine Änderungen an der WRP-Ressource erfolgen.

Behelfsmaßnahmen

• Installieren Sie bzw. aktualisieren Sie keine Systemkomponenten von Windows Vista, es sei denn, Sie benutzen von Microsoft gelieferte, weitervertreibbare, für Windows Vista konzipierte Pakete.

• Installieren Sie keine einzelnen Komponenten aus einem ganzen von Microsoft gelieferten, weitervertreibbaren, für Windows Vista konzipierten Paket.

• Erkennen Sie WRP-geschützte Dateien mithilfe von SfcIsFileProtected. Ist eine Datei unter WRP-Schutz, dann sollte die Anwendung die Datei weder installieren noch modifizieren.

• In Bezug auf von der WRP geschützte Registrierungsschlüssel sollten Anwendungen mit etwaigen auf die WRP zurückzuführende „Zugriff verweigert“-Meldungen elegant umgehen.

• Testen und prüfen Sie, ob Legacy-Anwendungen, die sich auf die WRP-Abwehr verlassen, richtig funktionieren, indem Sie die Anwendung installieren.

Links

• Windows Vista-Managementfunktionen

 

Internet Explorer - Geschützter Modus

Auswirkung der Funktion

Hoch

Kurze Beschreibung

In Windows Vista läuft der Microsoft Internet Explorer 7 im geschützten Modus, was durch die Ausführung des Internet Explorer-Verfahrens mit stark eingeschränkten Rechten dazu beitragen kann, dass der Benutzer vor Angriffen geschützt ist. Der geschützte Modus verringert die Fähigkeit eines Angriffs zum Schreiben, Ändern oder Vernichten von Daten bzw. zum Installieren von bösartigem Code im Computer eines Benutzers erheblich. Er kann dazu beitragen, den Benutzer vor bösartigem Code zu schützen, der sich ohne Genehmigung selbst installiert. Bei der Installierung von Windows Vista ist dieser Modus als Standard vorgegeben.

Erscheinungsform

• Anwendungen, die den Internet Explorer 7 benutzen, können nicht direkt auf die Diskette schreiben, während sie in der Internet- bzw. Intranet-Zone sind.

• Anwendungen wissen eventuell nicht, wie sie mit neuen Aufforderungen umgehen sollen.

Der geschützte Modus baut auf einem neuen Integritätsmechanismus auf, um bei sicherungsfähigen Objekten wie Prozessen, Dateien und Registrierungsschlüsseln auf höheren Integritätsebenen den Schreibzugriff zu beschränken. Bei der Ausführung in geschütztem Modus ist der Internet Explorer ein Prozess mit niedriger Integrität; er kann in einem Benutzerprofil bzw. an Systemstandorten keinen Schreibzugriff auf Dateien und Registrierungsschlüssel erhalten.

Prozesse mit niedriger Integrität können nur auf Ordner, Dateien und Registrierungsschlüssel schreiben, denen ein verbindliches Etikett mit niedriger Integrität zugewiesen wurde. Auf Grund dessen laufen der Internet Explorer und seine Erweiterungen im geschützten Modus, der auf Adressen mit niedriger Integrität schreiben kann, wie etwa die neuen Ordner „temporäre Internet-Dateien“, „Verlauf“, „Cookies“, „Favoriten“ und „Temporäre Windows-Dateien“.

Des Weiteren läuft der Prozess „Geschützter Modus“ auf einer niedrigen Desktop-Integritätsebene, wenn Windows Vista versandt wird, was ihn daran hindert, bestimmte Windows-Meldungen an Prozesse mit höherer Integrität zu senden.

Indem er den nicht genehmigten Zugriff auf empfindliche Zonen im System eines Benutzers verhindert, begrenzt der geschützte Modus die Höhe des Schadens, der durch die Kompromittierung des Internet Explorer-Prozesses oder durch Malware entstehen kann. Ein Angreifer kann zum Beispiel nicht geräuschlos ein Tastenanschlagsprotokollierungsprogramm im Start-Ordner des Benutzers installieren. Des Gleichen kann ein kompromittierter Prozess Anwendungen auf dem Desktop nicht durch Windows-Meldungen manipulieren.

Natürlich begrenzen diese Verteidigungseinrichtungen auch legitime Änderungen an Adressen höherer Integrität. Auf Grund dessen sieht der geschützte Modus eine Kompatibilitätsarchitektur, die den Einfluss auf vorhandene Erweiterungen verringert, wie in der folgenden Abbildung dargestellt.

Abbildung 1

Eine Kompatibilitätsschicht handhabt die Bedürfnisse der vielen vorhandenen Erweiterungen. Sie unterbricht Versuche, auf Ressourcen mit mittlerer Integrität zu schreiben, wie den Ordner Meine Dokumente im Benutzerprofil und der Registrierungsstruktur HKEY_CURRENT_USER. Die Kompatibilitätsschicht benutzt eine generische Windows-Kompatibilitätsbehebung, um diese Aktionen automatisch zu den folgenden Adressen mit niedriger Integrität umzuleiten:

• %userprofile%\LocalSettings\Temporary Internet Files\Virtualized

• HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\InternetRegistry

Zwei Broker-Verfahren mit höheren Rechten ermöglichen es dem Internet Explorer und seinen Erweiterungen, die Aktionen mit erhöhten Rechten auszuführen, wenn der Benutzer zustimmt. Zum Beispiel enthält das Benutzerrechtsbroker-Verfahren (IEUser.exe) einen Satz Funktionen, die den Benutzer Dateien in Zonen speichern lassen, die außerhalb der Zonen mit niedriger Integrität liegen. Darüber hinaus ermöglicht das Administratorrechts-Brokerverfahren (IEInstal.exe) es dem Internet Explorer, die ActiveX-Steuerung zu installieren.

Behelfsmaßnahmen

Schnelle Lösung:

• Tragen Sie die fragliche Site in Ihre Liste vertrauenswürdiger Sites ein.

• Schalten Sie den geschützten Modus aus (nicht empfohlen).

Kompatibilitätstest:

• Wenden Sie die schnelle Lösung an und vergewissern Sie sich, dass die Anwendung die abhängigen Funktionen genauso ausführen kann wie in Windows XP SP2.

Setzen Sie die Windows Vista-Kapazitätslösung ein:

• Ändern Sie die Anwendung, um mit dem geschützten Modus umzugehen, einschließlich etwaiger damit zusammenhängender Aufforderungen, die eventuell angezeigt werden.

Links

• Sicherheit und Kompatibilität im Internet Explorer 7

• Das Verstehen des geschützten Modus des Internet Explorer und das Arbeiten damit

• Internet Explorer-Entwicklungszentrum

• Informationsregister für die Internet Explorer 7 Beta 2-Vorschau

 

Windows Vista 64-bit

Auswirkung der Funktion

Hoch

Kurze Beschreibung

Windows Vista unterstützt zu 100 % die 64-Bit-Architektur-Prozessoren von AMD und Intel. Die 64-Bit-Version von Windows Vista kann mithilfe des WOW64-Emulators alle 32-Bit-Anwendungen ausführen. Jedoch werden 16-Bit-Anwendungen, 16-Bit-Installer und 32-Bit-Kernelmodus-Treiber vom Kernel nicht unterstützt.

Alle 64-Bit-Treiber müssen für die Windows Vista 64-Bit-Editionen digital signiert sein. Nicht signierte Treiber werden nicht unterstützt und können in 64-Bit Windows Vista nicht installiert werden. Die Prüfung der digitalen Signatur erfolgt sowohl während der Installation als auch in der Zeit, in der der Treiber geladen wird.

Erscheinungsform

• Anwendungen bzw. Komponenten, die 16-Bit-EXE-Dateien, 16-Bit-Installer oder 32-Bit-Kernel-Treiber benutzen, starten entweder gar nicht oder funktionieren in einer 64-Bit-Edition von Windows Vista nicht richtig. In diesem Fall wird folgende Fehlermeldung angezeigt:

  Das Programm bzw. die Funktion „[exepath]\[app16bit].exe“ kann auf Grund von Inkompatibilität mit 64-Bit-Versionen von Windows nicht starten bzw. laufen. Bitte kontaktieren Sie den Software-Lieferanten, um zu fragen, ob eine kompatible 64-Bit Windows-Version verfügbar ist.

• Werden 16-Bit-Installer bzw. Anwendungen gestartet, erscheint folgende Fehlermeldung:

  Die Version dieser Datei ist nicht kompatibel mit der von Ihnen ausgeführten Version von Windows. Prüfen Sie die Systeminformationen Ihres Computers, um festzustellen, ob Sie eine x86 (32-Bit) oder eine x64 (64-Bit) Version des Programmes brauchen, und kontaktieren Sie dann den Softwarehersteller.

• Jedwede Installation eines 32-Bit-Kernel-Treibers versagt im 64-Bit-System. Fügt ein Installer einen Treiber manuell hinzu, indem er die Registrierung bearbeitet, lädt das System diesen Treiber nicht. Obendrein kann diese Aktion dazu führen, dass das ganze System versagt.

• Jedwede Installation eines unsignierten 64-Bit-Treibers versagt im 64-Bit-System. Fügt ein Installer einen Treiber manuell hinzu, indem er die Registrierung bearbeitet, lädt das System den Treiber während der Ladezeit nicht, wenn er nicht signiert ist.

Behelfsmaßnahmen

Setzen Sie die Windows Vista-Kapazitätslösung ein:

• Alle 16-Bit-Komponenten sollten aus den Anwendungen entfernt und durch gleichwertige 32- bzw. 64-Bit-Komponenten ersetzt werden.

• Alle 16-Bit-Installer sollten zu 32-Bit- bzw. 64-Bit-Installern umgewandelt werden.

• Benutzt die Anwendung Kernel-Modus-Treiber muss eine 64-Bit-Version der Treiber programmiert werden. Die Anwendung sollte die Plattform des OS (32-Bit oder 64-Bit) erkennen und dann die geeignete Architektur des auf der OS-Plattform basierenden Treibers installieren.

• Vergewissern Sie sich, dass alle 64-Bit-Treiber digital signiert sind.

Kompatibilitätstest:

• Installieren und starten Sie die Anwendung auf einem 32-Bit und 64-Bit Windows Vista-Computer. Die Anwendung sollte auf beiden Architekturen richtig funktionieren.

Links

• Ausführung von 32-Bit-Anwendungen

• Video

• Digitale Signaturen für Kernel-Module auf x64-basierten Systemen, auf denen Windows Vista läuft.

 

Microsoft Graphical Identification and Authentication (GINA)

Auswirkung der Funktion

Hoch (Häufigkeit: niedrig)

Kurze Beschreibung

Vor Windows Vista erforderte die Anmeldung auf einem Drittserver bzw. einer Drittgerät die Ersetzung der dynamischen Link-Bibliothek „Graphical Identification and Authentication“ (GINA) in Windows XP seitens der ISV. Diese Anwendungen mussten auch die vorhandene UI ersetzen und Smart-Card sowie Desktop-Funktionen in Windows XP implementieren.

Hinweis Funktioniert eine Anwendung nicht auf diese Weise in Windows XP, dann sind diese Informationen nicht zutreffend.

Windows Vista führt eine neues Authentifizierungsmodell ein, das die direkte Kommunikation zwischen LogonUI und WinLogon einrichtet. Dieses Modell ist von einer Einfachheit, Skalierbarkeit und Flexibilität, die bei GINA nicht vorhanden war. Im Gegensatz zum GINA-Modul müssen die ISV nicht mehr die UI für den Logon-Bildschirm ersetzen, wodurch sie von der Last befreit sind, die Benutzerschnittstelle für den Benutzer neu schreiben zu müssen. Ein ISV kann einen Anmeldeinformationsanbieter programmieren, d. h. ein Modul, das an die LogonUI angeschlossen wird, um die UI zu beschreiben sowie die Anmeldeinformationen zu erhalten und diese dann an WinLogon weiterzugeben. Anmeldeinformationsanbieter sind für WinLogon vollständig transparent.

Anmeldeinformationsanbieter sind ferner additiv, d. h. die Benutzer können mehrere Anmeldeinformationsanbieter installieren und sich dann den aussuchen, den sie benutzen möchten. Anmeldeinformationsanbieter können vom Benutzer ausgewählt oder ereignisgetrieben sein. Mehrere Anmeldeinformationsanbieter können in Windows Vista koexistieren und sind nicht nur für Dritte. De facto liefert Windows zwei Anmeldeinformationsanbieter in der Schachtel: Benutzernamen- und Kennwort-Anmeldeinformationsanbieter und einen Smart Card-Anmeldeinformationsanbieter.

Zudem kann der Anmeldeinformationsanbieter innerhalb der CredUI immer wieder benutzt werden. Das heißt, das gleiche Objekt, das die Anmeldeinformationen auf LogonUI beschreibt und sammelt, kann dazu dienen, dieselben Anmeldeinformationen in CredUI-Szenarien zu sammeln.

Die GINA-Funktionalität von Windows XP und dem Windows Server 2003 wurde abgelehnt und ist nicht mehr Teil von Windows Vista. Die GINA-Anwendungsmodule funktionieren nicht mehr und müssen mithilfe des neuen Authentifizierungsmodells für Windows Vista neu geschrieben werden.

Erscheinungsform

• Der Benutzer kann keine benutzerdefinierten Logon-Anwendungen installieren.

• Der Benutzer kann sich in Windows Vista nicht mithilfe von benutzerspezifischen Logon-Anwendungen anmelden (mithilfe der Windows XP-Technologie). Dazu gehören eventuell:

  • Biometrische Geräte.

  • Benutzerspezifische UI zur Anmeldung.

  • Lösungen zum virtuellen privaten Netzwerk (VPN) für Remote-Benutzer mit benutzerspezifischer Anmeldungs-UI.

Behelfsmaßnahmen

Setzen Sie die Windows Vista-Kapazitätslösung ein:

• Die Anwendungen bzw. Komponenten, die die GINA-Technologie verwenden, müssen zur Benutzung des neuen Anmeldeauthentifizierungsmodells für Windows Vista neu geschrieben werden.

Links

Für alle Informationen und Fragen zum Anmeldeinformationsanbieter senden Sie eine E-Mail an den Shell Credential Provider alias: credprov@microsoft.com

 

Session 0 Isolierung

Auswirkung der Funktion

Hoch (Häufigkeit: niedrig)

Kurze Beschreibung

In Windows XP, Windows Server 2003 und früheren Versionen des Windows-Betriebssystems laufen alle Services in der gleichen Session wie der erste Benutzer der sich an der Konsole anmeldet. Diese Session wird Session 0 genannt. Die Ausführung von Services und Benutzeranwendungen zusammen in Session 0 bedeutet ein Sicherheitsrisiko, da die Dienste mit höheren Rechten laufen und daher das Ziel von bösartigen Programmen werden können, die nach Wegen suchen, ihre eigene Rechteebene zu erhöhen.

Das Microsoft Windows Vista-Betriebssystem verringert dieses Sicherheitsrisiko, indem es die Services in Session 0 isoliert und Session 0 nicht-interaktiv ausführt. In Windows Vista laufen nur Systemprozesse und Services in Session 0. Der erste Benutzer meldet sich in Session 1 an, und nachfolgende Benutzer melden sich in nachfolgenden Sessions an. Insofern laufen die Services niemals in der gleichen Session wie die Anwendungen der Benutzer und sind daher vor Angriffen geschützt, die vom Anwendungscode ausgehen.

Bestimmte Beispiele der betroffenen Treiberklassen sind unter anderem:

• Druckertreiber, die per Spooler-Service geladen werden.

• Alle im Rahmen des User Mode Driver Framework (UMDF) geschriebenen Treiber, weil diese Treiber einen Prozess in Session 0 als Host haben.

Von dieser Eigenschaft betroffene Anwendungsklassen:

• Services, die die UI erstellen.

• Ein Service, der versucht, die Windows-Meldefunktionen wie SendMessage und PostMessage zu benutzen, um mit einer Anwendung zu kommunzieren.

• Anwendungen, die globale benannte Objekte erstellen.

Erscheinungsform

Schaltet ein zu einer Anwendung gehöriger Service eine UI, wartet die Anwendung auf den Service, und die UI wird in der Benutzersession nicht angezeigt.

Behelfsmaßnahmen

Schnelle Lösung:

• Benutzt der Service der Anwendung eine UI, ermöglicht es eine in Windows Vista eingebaute Erleichterung dem Benutzer, mit dem Session 0-UI auf einem speziellen Desktop zu interagieren. Dadurch wird nur die der Anwendung zugehörige UI verfügbar statt des gesamten Session 0-Desktops.

• Erstellt die Anwendung global benannte Objekte, dann benutzen Sie den Kompatibilitätsmodus von Windows XP, um sicherzustellen, dass die Anwendung auch weiterhin mit den Session 0-Services zusammenarbeitet.

Kompatibilitätstest:

• Testen und prüfen Sie die Anwendung in Windows XP im Terminal Server-Modus oder dem Modus „Schnelle Benutzerumschaltung“. Funktioniert die Anwendung in diesen Szenarien in Windows XP richtig, dann wird sie mit großer Wahrscheinlichkeit auch unter Windows Vista funktionieren.

• Prüfen Sie, ob die Anwendung nach dem Einsatz des Kompatibilitätsmodus von Windows XP richtig funktioniert, der Erleichterungen für einige Session 0-Probleme enthält.

• Testen Sie den Treiber unter Windows Vista, um sich zu vergewissern, dass er richtig läuft. Ist dies nicht möglich, testen Sie den Treiber in Windows XP, wobei die Funktion „Schnelle Benutzerumschaltung“ aktiviert und mehrere Benutzer angemeldet sein müssen. Funktioniert der Treiber für den zweiten und die nachfolgend angemeldeten Benutzer richtig, wird er wahrscheinlich nicht durch die Session 0-Veränderungen in Windows Vista berührt. Die einzigen Probleme, die dieser Test nicht erkennt, sind diejenigen, die sich auf die Abwesenheit des Video-Treibers in Session 0 in Windows Vista beziehen.

Setzen Sie die Windows Vista-Kapazitätslösung ein:

• Benutzen Sie Client- bzw. Servermechanismen, wie etwa den Remote-Prozeduraufruf, oder Named Pipes, um zwischen den Services und den Anwendungen zu kommunizieren.

• Benutzen Sie die WTSSendMessage-Funktion, um eine einfache Message-Box auf dem Desktop des Benutzers zu erstellen. Dadurch kann der Service dem Benutzer eine Benachrichtigung zukommen lassen und eine einfache Antwort verlangen.

• Für kompliziertere UI benutzen Sie die CreateProcessAsUser-Funktion, um einen Prozess in der Session des Benutzers zu erstellen.

• Wählen Sie ausdrücklich entweder Lokal\ oder Global\ als Attribut des Namespace für benannte Objekte, wie etwa Ereignisse oder zugeordnete Speicher, die der Service bereit stellt.

Links

• Auswirkung der Session 0-Isolierung auf Services und Treiber in Windows Vista

• Services

• Synchronisierung

• Durchführung eines Remote-Prozeduranrufs

• Client/Server-Anwendungen

• CreateProcessAsUser

• Testen Sie Ihre Anwendung mit der Funktion „Schnelle Benutzerumschaltung“

 

Netzwerk: TCP/IP-Liste und die Windows-Filterplattform

Auswirkung der Funktion

Hoch

Kurze Beschreibung

Der Windows Vista-Netzwerkstapel wurde vollständig neu geschrieben. Statt des dualen Stapelmodells, das Windows XP bzw. den Windows Server 2003 auszeichnet (zur Unterstützung von IPv4 und IPv6), implementiert Windows Vista eine neue Architektur, in der eine einzige Transportschicht bzw. Framing-Layer mehrere IP-Ebenen unterstützt. Es gibt mehrere neue Funktionen und Protokollverbesserungen. Der neue Stapel ist sehr modular, flexibel und erweiterbar. Obwohl alles versucht wurde, um Anwendungskompatibilität mit vorhandenen, sich mit dem Stapel auf verschiedenen Ebenen überschneidenden Anwendungen zu erreichen, können einige Änderungen (zumeist Nebenwirkungen von Verbesserungen) nichtsdestoweniger potenzielle Anwendungskompatibilitätsprobleme aufwerfen. Entwickler müssen diese Änderungen sorgfältig evaluieren, um deren Auswirkung auf ihre Anwendungen zu verstehen.

Dank der Microsoft Windows-Filterplattform (WFP) API können Entwickler Code erstellen, der mit der Filterung interagiert, die auf mehreren Ebenen im Netzwerkstapel des Betriebssystems in Windows Vista und im Microsoft Windows Server mit dem Codenamen „Longhorn“ und im gesamten Betriebssystem stattfindet. WFP integriert auf der Grundlage der Benutzung des Sockets-API durch eine Anwendung auch Firewallfunktionen, wie etwa authentifizierte Kommunikation und dynamische Firewallkonfiguration.

Hinweis WFP ist nicht selbst ein Firewall. Es handelt sich um eine Reihe zusammengehöriger Systemservices und APIs, mit deren Hilfe man Firewalls implementieren kann.

Die folgenden Elemente des TCP/IP-Stapels werden in Windows Vista nicht unterstützt:

• Die Firewall-Hook-Treiberfunktionen und die Filter-Hook-Treiberfunktionen sind abgeschwächt worden.

• Die Tools der R-Serie, darunter rexec, rsh, finger usw. Diese Tools können bei Bedarf von den Services für Unix-Komponenten abgerufen werden.

• Das Internetwork Packet Exchange (IPX)-Protokoll. Das IPX wurde abgeschwächt und wird, wenn überhaupt, kaum benutzt. Diese Veränderung sollte sich nur geringfügig oder gar nicht auf die Anwendungskompatibilität auswirken.

Erscheinungsform

• Benutzt eine für Windows XP gebaute Anwendung nur öffentliche Funktionen für ihr Netzwerk, sollte kein Bruch in der Funktionalität entstehen. Diese sollte in Windows Vista getestet werden, um ihre Funktionalität zu überprüfen.

• Anwendungen, die jegliche Firewall-Hook-Treiberfunktionen bzw. Filter-Hook-Treiberfunktionen benutzen, funktionieren nicht.

• Anwendungen, die sich auf interne Strukturen und Funktionsanrufe verlassen, die niemals von Microsoft veröffentlicht wurden, versagen.

• Die im Kernelmodus geschriebenen Filtertreiber der Transporttreiberschnittstelle (Transport Driver Interface, TDI) funktionieren nach einer Hochrüstung des Betriebssystems eventuell nicht mehr richtig.

Hinweis Die TDI-Schnittstelle ist auf dem Weg, in einer zukünftigen Veröffentlichung abgeschwächt zu werden. Jedoch funktionieren diese Treiber immer noch unter Windows Vista.

Behelfsmaßnahmen

Setzen Sie die Windows Vista-Kapazitätslösung ein:

• Die WFP umfasst ein reichhaltiges Angebot von Funktionen und Services für Netzwerksicherheitsentwickler und liefert Anweisungen bzw. Dokumentationen zu dem verfügbaren Funktionsangebot.

Hinweis   Anwendungen und Skripts, die sich auf Services for Unix und die R-Serie verlassen, müssen jetzt erst diese Tools installieren.

Links

• WFP-Architektur, Einzelheiten und SDK (Vorveröffentlichung)

• Interoperabilität und Migrationszentrum

 

Netzwerk: Kernel-Modus IP-Hilfsprogramm-APIs

Auswirkung der Funktion

Hoch

Kurze Beschreibung

In früheren Veröffentlichungen von Windows hatten die Winsock-Clients keine API, die für den Zugriff auf den Kernel eingestellt war. Dies ändert sich in Windows Vista. Ferner unterstützt Windows Vista IPv6 jetzt standardmäßig. Statt getrennte API-Schnittstellen für IPv4 und IPv6 zu liefern, wurde ein neuer Helfer-API-Satz konzipiert, der eine gemeinsame Funktionalität über alle neuen Technologien hinweg liefert, und zwar folgendermaßen:

• Kernelmodus-Funktionen für Windows Sockets in Kernel (WSK) Clients.

• IPv6-Unterstützung.

• Alleiniger Satz von Funktionen für die IPv4- und IPv6-Adressierung.

• Ergibt ein in sich stimmiges, erweiterbares Objektmodell.

• Ergibt ein klar definiertes, auf der Netzwerkservice-Schnittstelle basierendes Sicherheitsmodell.

• Zeigt neue Stapelfunktionalität, wie Abteilungen und Unterschnittstellen.

Erscheinungsform

Anwendungen, die die älteren Helfer-API-Schnittstellen bzw. nicht dokumentierte Kernelfunktionsanrufe benutzen, funktionieren nicht mehr bzw. werden instabil.

Behelfsmaßnahmen

• Anwendungen müssen die neuen Kernelmodus IP-Helfer-API-Schnittstellen unterstützen und implementieren.

Links

• Zurzeit keine.

 

Netzwerk: IPv6

Auswirkung der Funktion

Hoch (Häufigkeit: mittelmäßig)

Kurze Beschreibung

Für den TCP/IP-Stapel in Windows Vista ist IPv6 standardmäßig aktiviert. IPv6-Konnektivität wird, falls verfügbar, vorgezogen. Dies hat folgende Implikationen für Anwendungen, die sich mit dem TCP/IP-Stapel überschneiden:

• Der IPv6-Verkehr wird vom Windows Vista-Stapel gesendet, unabhängig davon, ob das Netzwerk IPv6 unterstützt oder nicht. Daher werden zum Beispiel das Routerersuchen und die Nachbarkennungsmeldungen standardmäßig generiert.

• IPv6-Adressen sind standardmäßig präsent und an. Es können mehrere IPv6-Adressen mit link-lokal, global, temporär und mit Übergangstechnologien wie 6to4, 6over4, ISATAP und Teredo verbunden sein.

  • Hinweis Teredo ist standardmäßig aktiviert.

• Unter Windows Vista kann ein System in einem Nur-IPv6-Modus konfiguriert werden. In diesem Fall steht keine IPv4-Unterstützung zur Verfügung.

Der TCP/IP-Stapel in Windows Vista unterstützt ein solides Host-Routing-Modell. Das heißt, dass das Routing von Paketen von einem mehrfach vernetzten Computer nicht nur auf Grund der Zieladresse des jeweiligen Pakets, sondern auch auf Grund seiner Absenderadresse erfolgt. Diese Änderung ist erforderlich, weil in IPv6 jeder Computer mehrere IP-Adressen erhält und bei den Übergangstechnologien im Wesentlichen als mehrfach vernetzter Computer erscheint, soweit es das Routing betrifft. Um zu gewährleisten, dass in diesen Szenarien mit der korrekten Konnektivität gearbeitet wird, muss der Netzwerk-Stapel ein solides Host-Routing-Modell implementieren.

Erscheinungsform

Anwendungen, die den Windows XP TCP/IP-Stapel benutzen bzw. die die Verbindung zum IPv6-Protokoll nicht herstellen können, funktionieren nicht richtig und können abstürzen oder ein instabiles System schaffen.

Das solide Host-Routing-Modell für die Anwendungen impliziert Folgendes:

• Die Verbindung von einer Nicht-Loopbackadresse zu einer Loopbackadresse und umgekehrt kommt nicht zustande.

• Ein Windows Vista-Computer gestattet keine Versendung von Paketen mit einer Quellenadresse von 127.0.0.0/8 auf einem Netzwerk.

Behelfsmaßnahmen

Anwendungen müssen wie folgt neu geschrieben werden:

• Jegliche Anwendung, die eine Verbindung mit dem Stapel herstellt, muss IPv6-Verkehr handhaben können. Mindestens sollte sie nicht abstürzen, wenn sie IPv6-Verkehr empfängt.

• Jegliche Anwendung, die sich darauf verlässt, dass eine einzige IPv4-Adresse vorhanden ist, muss modifiziert werden, um mehrere IPv6-Adressen handhaben zu können. Des Weiteren muss jede Anwendung, die die erste Adresse aufnimmt, die zu benutzende IPv6-Adresse noch sorgfältiger identifizieren. Dies liegt daran, dass eine IPv6 link-lokal-Adresse nicht geroutet werden kann und dass daher die Anwendung eventuell nicht funktioniert. Stattdessen sollte die Anwendung Funktionen benutzen, die eine Verbindung nach Namen gestatten, und die geeignetste Adresse automatisch wählen.

• Anwendungen müssen Nur-IPv6-Szenarien handhaben und unterstützen können.

• Anwendungen müssen das solide Host-Routing-Modell unterstützen und implementieren.

Links

• IPv6-Anleitung für Windows Sockets-Anwendungen

 

Kompatibilitätsrisiken

Herausgenommene Komponenten

Die folgenden Komponenten von früheren Windows-Versionen sind in Windows Vista nicht mehr präsent:

• Kernelmodus-Druckertreiber-Support: Alle Druckertreiber müssen jetzt dem Treiberrahmen Benutzermodus folgen. Alle Kernelmodus-Druckertreiber werden für das Laden in Windows Vista gesperrt. Weitere Informationen erhalten Sie auf der Site User-Mode Driver Framework (UMDF).

• Windows-Hilfe (WinHelp.exe and WinHlp32.exe) wird für Windows Vista herausgenommen. Windows Help wird in der Beta 2 nicht unterstützt und ein Teil des Windows Help-Codes wurde für die Veröffentlichung entfernt. Um Hilfe-Dateien mit der Dateinamenerweiterung .HLP in Windows Vista anzuzeigen, müssen Sie die Windows-Hilfe vom Microsoft Download-Zentrum herunterladen und installieren. Dieser Download steht nicht für Beta 2 und RC1 zur Verfügung. Weitere Informationen erhalten Sie unter Support Hilfe Modul.

  Hinweis   HTML Hilfe und .CHM-Dateien werden von Windows Vista unterstützt.

• Microsoft FrontPage-Servererweiterungen. Windows SharePoint Services verfügt jetzt über ein verstärktes Funktionsset für die Entwicklergemeinschaft.

• Services for Macintosh.

• D3DRM. DirectX ist das einzige unterstützte Grafikpaket bei Windows Vista.

• Web-Veröffentlichungsassistent.

• NetDDE – Aus Sicherheitsgründen unterstützt Windows Vista NetDDE nicht. (NetDDE ist standardmäßig unter Windows XP SP 2 und Windows Server 2003 gesperrt.) Reguläres DDE wird immer noch unterstützt. NetDDE ist eine Technologie, die es Anwendungen, die DDE-Transport benutzen, ermöglicht, Daten transparent über ein Netzwerk auszutauschen. Das Ergebnis ist, dass die Anwendung keine Daten über das Netzwerk austauschen kann. Als Umleitung lassen sich andere Netzwerktechnologien wie DCOM und Windows Communication Foundation einsetzen. Weitere Informationen über NetDDE erhalten Sie unter https://support.microsoft.com/default.aspx?scid=kb;en-us;125703.

 

Hilfe- und Supportzentrum

Das Hilfe- und Support-Center (HelpCtr.exe) war eine für Windows XP und Windows Server 2003 entwickelte Hilfeanwendung. Das Hilfe- und Support-Center zeigte kompilierte Hilfedateien mit der .CHM-Dateierweiterung an.

Das Hilfe- und Support-Center ist nicht in Windows Vista enthalten und dessen Funktionen werden nicht unterstützt. Kompilierte Hilfedateien mit der .CHM-Dateierweiterung werden nur in der „HTML-Hilfe“ wie oben beschrieben angezeigt.

 

Assistentenplattformclient

Der „Assistance Platform“-Client (HelpPane.exe) ist eine neue Hilfe-Engine, die für Windows Vista entwickelt wurde. Diese Engine ist nicht mit früheren Windows-Versionen kompatibel. Der „Assistance Platform“-Client wird benötigt, um Hilfedateien mit der .H1S-Dateierweiterung anzuzeigen.

In Windows Vista kann der „Assistance Platform“-Client von OEMs, Systemherstellern und Unternehmenskunden im Rahmen einer Lizenzvereinbarung angepasst werden. Eine Nutzung durch Drittanbieter-Programme ist nicht möglich. Weitere Informationen zur Anpassung des „Assistance Platform“-Clients finden Sie im Windows SDK.

Windows Vista Anzeigetreibermodell

Das Windows Vista Anzeigetreibermodell (Display Driver Model, VDDM) ist ein vollständig neues Anzeigetreibermodell, dass die Stabilität der Anzeigetreiber in Windows verstärkt. Das VDDM verfügt über eine Reihe wichtiger Eigenschaften, darunter:

• Effizientes Management des Videospeichers für DX-Anwendungen und des neuen Desktop Window Manager (DWM). Mehrere 3-D-Anwendungen nutzen den Grafikprozessor (Graphics Processor Unit, GPU) in Windows Vista.

• Treiber-Upgrades ohne Neustart des Computers.

• Dynamische Erkennung des Einfrierens der GPU und Wiederherstellung ohne Neustart des Computers.

• Hot Plug-Erkennungssupport der Monitore.

• Mithilfe der von DX9L verlangten Hardware-Eigenschaften.

• Störungsfreies Video-Playback.

• Eine Gelegenheit zu einem sehr sicheren Konzept.

Obwohl die meisten Anwendungen aus früheren Versionen von Windows nicht vom VDDM beeinflusst werden sollten, bleiben einige Risiken:

• DX-Spielekompatibilität, die in DX-Runtime oder IHV-Treiber bzw. Kerngrafikstapelproblemen resultieren.

• Mobile Funktionalität wie Hotkeys, Cloneview, Helligkeit und Zoom auf Grund von strengeren ACPI-Anforderungen.

• Zugänglichkeit, insbesondere die unter Windows XP konzipierten Bildschirmvergrößerungsanwendungen funktionieren in Windows Vista nicht.

Links

• E-Mail an Graphics Feedback alias: lhgfxfb@microsoft.com

Sicheres Handling von Ausnahmen (Safe Exception Handling, SEH)

In früheren Windows-Versionen dienten die Funktionen IsBadReadPtr und IsBadWritePtr dazu, Parameter zu validieren. Diese Funktionen sind in Windows Vista jetzt verbannt. Ferner werden Anwendungen, die sich auf Windows-Komponenten verlassen, die diese Funktionen zur Validierung von Parametern, feststellen, dass Windows sie nicht mehr verwendet. Anwendungen sollten sich nicht auf Windows verlassen, dass das OS irgendwelche Parametervalidierungen durchführt (es erfolgt eine Prüfung für Null, und die Anwendung versagt, wenn dies ein schlechter Pointer ist).

Safe Exception Handling (SEH) geht auch Hand in Hand mit der Nichtausführungsanzeige. Ausnahmehandler werden dahingehend überprüft, dass sie „page_execute“ markiert sind, bevor die Ausnahme übermittelt wird, sowie dahingehend, dass der Handler aus gültigem Code besteht und dass er in der SEH-Tabelle enthalten ist.

DLLmain-Operationen

Der Ladebefehl für die DLLs während der Prozesserstellung ist nicht garantiert, und man sollte sich niemals auf ihn verlassen, dass er bestimmte Operationen durchführt. Komplizierte Verarbeitung in DllMain kann dazu führen, dass Anwendungen wegen der Abhängigkeiten der neuen OS-Komponenten einfrieren bzw. abstürzen. Einzelheiten dazu finden Sie auf folgenden Seiten auf MSDN:

• Dllmain

• „Calls to an OLE Object Should Not Be Done from DllMain“ (Aufrufe an ein OLE-Objekt sollten nicht von DllMain aus erfolgen)

• „PRB: Cannot Create an MFC Thread During DLL Startup“ (Kann keinen MFC-Thread während DLL-Start erstellen)

• „Your application may fail with an ‚Access Violation‛ error message when you use ODBC or DAO in the InitInstance or DllMain functions of a DLL“ (Ihre Anwendung kann mit der Fehlermeldung „Zugriffsverletzung“ versagen, wenn Sie ODBC oder DAO in den Funktionen InitInstance bzw. DllMain eines DLL benutzen)

• „COM application hangs when you call CoCreateInstance from DllMain“ (COM-Anwendung friert ein, wenn Sie CoCreateInstance von DllMain aus rufen)

Neuer Name für Outlook Express

Outlook Express wurde geändert und an eine andere Stelle versetzt; der Name ist jetzt Windows Mail. MAPI-Anwendungen müssen diese Änderung zur Kenntnis nehmen. Die meisten Anwendungen, die dynamisch Standardprogramm für MAPI benutzen, sollten keine Kompatibilitätsprobleme erleben.

Shell: Themen und Standort von Meine Dokumente

Die Windows Explorer Shell hat neue visuelle Themen für Windows Vista eingeführt. Bei Anwendungen, die in früheren Versionen von Windows mit Themen umgehen konnten, wirkt sich diese Änderung normalerweise nicht auf die Kompatibilität aus.

Ferner hat sich der Standort und die Struktur von Meine Dokumente in Windows Vista geändert, um eine bessere Benutzererfahrung zu erreichen. Die Benutzerdaten werden jetzt in der Ordnerstruktur \users\%username%\ gespeichert. Bilder, Musik, Dokumente, Desktop und Favoriten sind alles neue Ordner direkt unter dieser Struktur. Benutzt eine Anwendung die Funktion ShGetFolderPath und benutzt den Ordnerpfad dynamisch, wird sie automatisch auf den neuen Pfad und die neuen Speicherorte umgeleitet. In der Regel wirken sich diese Änderungen nicht auf die Kompatibilität von Anwendungen aus.

Schnelle Benutzerumschaltung (Fast User Switching, FUS)

Die Funktion Schnelle Benutzerumschaltung steht jetzt in Windows Vista für alle Versionen, einschließlich domänenverbundener Computer, zur Verfügung. Anwendungen und Installer müssen FUS kennen und mehrere angemeldete Benutzersessions und Terminal-Server-Szenarien auf einmal handhaben können. Weitere Informationen erhalten Sie in Microsoft Windows XP Fast User Switching: Design-Handbuch für den Aufbau von kaufmännischen Anwendungen (Design Guide for Building Business Applications).

Code-Änderungen für „CriticalSection“

Der Code für CriticalSection wurde geändert, um seine Sicherheit und Robustheit zu erhöhen. Anwendungen, die „Critical Section“-Sperren benutzen:

• Sollten „Critical Sections“ immer initialisieren.

• Sollten nicht in nicht dokumentierte Objekte hineinlesen. Anwendungen, die in nicht dokumentierte Strukturen hineinlesen, um den Status einer „Critical Section“ zu beurteilen, werden wahrscheinlich unterbrochen, wenn sie nach nicht initialisierten und freien „Critical Sections“ suchen.

• Sollten ein Verhungern verhindern. Anwendungen, die Sleep rufen, während sie die „Critical Section“-Sperre halten, können jetzt ein Verhungern anderer Threads verursachen, die die Sperre brauchen. Sleep-Anrufe sollten erst nach dem Anruf bei LeaveCriticalSection erfolgen.

Weitere Informationen erhalten Sie zum Thema Critical Section-Objekte in MSDN.

User Interface Privilege Isolation (UIPI)

In Windows Vista ist die User Interface Privilege Isolation (UIPI) standardmäßig freigegeben. Auf Grund dieses Sicherheitsmerkmals kann ein Prozess auf einer Ebene mit niedrigerer Integrität nicht mithilfe von Windows Messaging (SendMessage) mit einem Prozess auf einer Ebene höherer Integrität kommunzieren. Dies bedeutet, dass Anwendungen, die unter der Standardbenutzerberechtigung laufen, nicht mit Anwendungen kommunizieren können, die unter einer höheren administrativen Zugangsberechtigung laufen. Es bedeutet auch, dass Anwendungen, die Tastatur- bzw. Maus-Hooks installieren, jetzt dahingehend geändert werden müssen, dass sie Manifeste verwenden und Elevation anfordern. Darauf bezogene Informationen finden Sie auch im Abschnitt „Internet Explorer - Geschützter Modus“ in diesem Dokument.

 

Standardprogramme

Auswirkung der Funktion

Träger

Kurze Beschreibung

Standardprogramme ist eine neue Infrastruktur zum Management von Datei- und Protokollzuordnungen pro Benutzer, die im Hinblick auf konkurrierende Anwendungen konzipiert wurde. Anwendungen müssen sich registrieren, um die Funktionalität von Standardprogramme zu nutzen. Beachten Sie, dass Standardprogramme in Windows Vista und darüber hinaus stark hervorsticht und dass die Funktion Standardprogramme es den Anwendungen bedeutend erleichtert, bestimmte Aufgaben zu kodieren und zu pflegen.

Es ist im heutigen Ökosystem von Software schwierig, Ihre Standardverhalten zu managen, weil es so viele konkurrierende Anwendungen für allgemeine Aufgaben gibt. Viele Benutzer haben mehrere Software-Programme, die das gleiche tun: das Web durchsuchen, Fotos ansehen, Musik spielen, Filme sehen und E-Mail managen, um nur einige Aufgaben zu nennen. Viele Benutzer haben große Schwierigkeiten, weil eine Anwendung, selbst wenn sie sich entschieden haben, sie nur auszuprobieren, ihr System und Standardverhalten wie das Doppeltklicken für immer übernommen hat.

Das Problem verschlimmert sich, wenn an einem Computer mehrere Benutzer arbeiten. Wenn mehrere Benutzer beginnen, verschiedene Anwendungen zu benutzen, beginnen sie auch, sich gegenseitig auf ihre Standards zu treten. Die Wurzel dieses Problems bildet die Tatsache, dass sowohl Protokolle als auch Dateizuordnungen normalerweise pro Computer festgelegt bzw. gemanagt werden, indem die Anwendungen Schlüssel in die Registrierung auf HKLM (HKEY_Local_Machine) schreiben. Das Problem wird noch schwieriger dadurch, dass es mehrere Orte in der Registrierung gibt, worauf Anwendungen schreiben, um die Standards für sich zu vereinnahmen.

Dies führt häufig dazu, dass einige Anwendungen auf einen Ort in der Registrierung schreiben und andere Anwendungen auf einen anderen Ort. Das Problem verschlimmert sich, wenn diese Anwendungen sich als Standard für bestimmte Verhaltensweisen verstehen wollen, dies jedoch nicht können, weil sie nicht auf alle diejenigen Orte schreiben, auf die andere Anwendungen schreiben. Das Kernproblem besteht darin, dass es leicht sein muss, die Anwendungen auf dem System zu managen, die konkurrierende Interessen haben.

Behelfsmaßnahmen

Windows' erster Versuch zur Lösung dieses Problems war SPAD (Set Program Access and Defaults [Programmzugriff und Vorgaben einrichten]). Dadurch können die Benutzer einer Anwendung gestatten, ihr standardmäßiges Verhalten wiederherzustellen. SPAD ermöglicht es einfach den Anwendungen, einigen registrierten Code auszuführen, um auf einen bestimmten Status zurückzukommen. SPAD war ein großer Schalter und setzte die Standards für den gesamten Computer. SPAD steht auch in Windows Vista noch zur Verfügung, um dem Administrator die Konfiguration der Standards der Maschine und das Verstecken des Zugriffs zu ermöglichen, bildet jedoch nicht die primäre Standardserfahrung für Benutzer.

Windows Vista bietet Ihnen eine Reihe neuer nützlicher Funktionalitäten. Diese neuen Funktionalitäten werden als „Standardprogramme“ bezeichnet. Standardprogramme sollen den Benutzern bei der Festlegung des Standardverhaltens helfen. Der große Vorteil besteht darin, dass die Standardeinstellungen in Windows Vista und darüber hinaus auf Benutzerebene und nicht auf Computerebene gesteuert werden. Hierdurch wird für die Multi-User-Computer-Umgebung, die sich unserer Meinung nach zum Standard entwickeln wird, mehr Flexibilität gewährleistet. Dies geschieht teilweise durch die Hinzufügung einer neuen zentralisierten Benutzeroberfläche und teilweise durch die Bereitstellung von Tools, die ISVs benötigen, um benutzerdefinierte Entscheidungen zu unterstützen. Standardprogramme bieten eine Anwendung:

• Ein vereinfachter Prozess für die Anwendung von Standardeinstellungen.

• Benutzerspezifische Datei- und Protokollzuordnung.

• Programmatische Prüfung von Standards.

• Wiederverwendung bekannter Windows-Benutzeroberflächen.

• Werbebereiche innerhalb von Windows.

Diese Funktionalität wurde in erster Linie für strittige Anwendungen entwickelt. Diese Anwendungen wollen als Standardprogramme für bestimmte Dateitypen wie .mp3 oder .jpeg oder Protokolle wie http und mailto verwendet werden. Anwendungen, die hauptsächlich über eigene Protokolle und Dateizuordnungen verfügen, benötigen diese neue Funktionalität typischerweise nicht, da sie nicht der Gefahr einer Interferenz durch andere Anwendungen unterliegen. Unstrittige Anwendungen verhalten sich wie unter XP und werden auf die gleiche Weise installiert. Alle Anwendungen können jedoch die Vorteile der neuen Standardprogramme nutzen.

Die Funktionalität der Standardprogramme ist in Form verschiedener Steuerungskonsolen und offener Programmierschnittstellen in das Betriebssystem integriert. Damit eine Anwendung die Steuerungskonsolen und offenen Programmierschnittstellen (APIs) nutzen kann, muss sie bei der Installation durch Schreiben eines bestimmten Schemas als Teil der Standardprogramme registriert werden. Dies ermöglicht die Einblendung der Anwendung in der Steuerleiste der Standardprogramme und somit die Wiederherstellung der Standard-Dateizuordnungen und Protokolle durch den Benutzer zu jedem Zeitpunkt.

Sobald eine Anwendung innerhalb der Standardprogramme registriert wurde, kann sie die durch die APIs gegebenen Vorteile der neuen Funktionalität nutzen. Standardprogramme bieten APIs, um:

• Alle registrierten Standardeinstellungen wiederherzustellen.

• Einzelne registrierte Standardeinstellungen wiederherzustellen.

• Kanonisch nach dem Eigentümer bestimmte Standard-Dateizuordnungen/Protokolle/Startmenüs zu suchen.

• Standard-Benutzeroberflächen für eine bestimmte Anwendung zu starten.

• Alle benutzerdefinierten Zuordnungen zu löschen.

Die Standardprogramme dienen dazu, die nachträgliche Installation benutzerdefinierter Anwendungen zu vereinfachen und Anwendungen ein einfaches Rahmenwerk für die Ablehnung und Annahme von Standardeinstellungen zu bieten.

Warum sollen Standardprogramme genutzt werden?

Vorteile:

• Standardprogramme unterstützen die Erkennung von Anwendungen.

• Die zugrunde liegende Architektur, die es allen Administratoren ermöglicht hat, HKLM zu schreiben, ändert sich unter Windows Vista.

• Standardprogramme ermöglichen es, Anwendungen und XP-typische Prozessabläufe mit nur sehr geringen Codeänderungen beizubehalten.

• Die Inanspruchnahme von Standardeinstellungen nur auf Computerebene führt nicht immer zu den gewünschten Ergebnissen.

Offensichtlich besteht eine zunehmende Nachfrage nach strittigen Anwendungen, die das Rahmenwerk der Standardprogramme nutzen. Gleichzeitig profitieren auch die Anwendungen erheblich von der Nutzung der Standardprogramme.

Standardprogramme bieten erheblich verbesserte Benutzeroberflächen für registrierte Anwendungen, so dass dem Benutzer all die aufregenden neuen Möglichkeiten vorgestellt werden können. Darüber hinaus können Anwendungen, die mit einer digitalen URL-Signatur versehen sind, diese URL anzeigen und Benutzern die Möglichkeit bieten, zurück zur Startseite zu navigieren und zu entdecken, welche weiteren Anwendungen und Verbesserungen das Unternehmen noch bietet.

Die Anwendung der neuen API reduziert darüber hinaus die Entwicklungskosten für neue Anwendungen. Nahezu alle strittigen Anwendungen verfügen über Überwachungs- oder Prüfungsfunktionen, um zu kontrollieren, ob sie keine Standardanwendungen sind. Mit der neuen API kann dies durch einen einzigen API-Aufruf anstatt durch das Durchsuchen des gesamten Verzeichnisses wie bei den vorherigen Versionen des Betriebssystems erreicht werden.

Die neue API hilft Anwendungen darüber hinaus, in der neuen Umgebung mit der User Account Control (UAC) korrekt zu funktionieren. Die UAC wird implementiert, indem ein Administrator dem System als Standardbenutzer angezeigt wird. Aus diesem Grund kann ein Administrator unter Windows Vista und späteren Windows-Versionen nicht normal in HKLM schreiben. Dies dient dazu, sicherzustellen, dass Prozesse nicht ohne Wissen eines Administrators in dessen Namen agieren können. Die Installation erfolgt erfahrungsgemäß auf höherer Ebene. Anwendungen, die Standardeinstellungen nach der Installation übernehmen wollen, müssen dies auf Benutzer- und nicht auf Computerebene können. Durch den Wechsel zu der neuen API wird dies automatisch erreicht. Anwendungen können Standardeinstellungen nach der Installation nicht mehr auf Computerebene übernehmen.

Ein weiterer wesentlicher Grund für die Nutzung der Standardprogramme durch eine Anwendung ist die konsistente Erzielung der gewünschten Ergebnisse. Datei- und Protokollzuordnungen werden aus einer hierarchischen Struktur im Verzeichnis abgeleitet. Ein Teil dieser Struktur schreibt vor, dass benutzerdefinierte Standardeinstellungen die Standardeinstellungen des Computers in jedem Fall überschreiben. Das heißt, dass, wenn eine Anwendung sich durch ihren Code entscheidet, Erhebungspunkte zu erstellen, um die Standardeinstellungen durch Schreiben in HKLM wie unter XP zu übernehmen, nicht immer das gewünschte Ergebnis erzielt wird. Sobald eine vergleichbare Anwendung installiert wird und die APIs von Standardprogrammen verwendet werden, die benutzerdefinierte Datei- und Protokollzuordnungen nutzen, gilt die vorherige Anwendung nicht mehr als Standardprogramm, da die benutzerdefinierten Standardeinstellungen eine höhere Priorität haben.

Benutzeroberflächen der Standardprogramme.

Die Benutzeroberflächen der Standardprogramme bestehen aus mehreren Teilen. Diese Abbildungen zeigen nicht die endgültige Version, in der Windows Vista ausgeliefert wird, sondern dienen lediglich als allgemeine Übersicht über die Funktionen und als Hilfe zum besseren Verständnis.

Reihenfolge der Benutzeroberflächen von Standardprogrammen:

Abbildung 2 (Klicken Sie auf das Bild, um es zu vergrößern.)

Startmenü:

Abbildung 3 (Klicken Sie auf das Bild, um es zu vergrößern.)

Systemsteuerungsseite der Standardprogramme:

Abbildung 4 (Klicken Sie auf das Bild, um es zu vergrößern.)

Einrichten einer Standardprogramm-Seite:

Abbildung 5 (Klicken Sie auf das Bild, um es zu vergrößern.)

Nur registrierte Anwendungen werden in der Anwendungsliste angezeigt. Wenn eine Anwendung einen Beschreibungswert registriert, wird dieser in dem Listenfenster auf der rechten Seite angezeigt. Bei der Registrierung muss eine Beschreibung angegeben werden.

Abbildung 6 (Klicken Sie auf das Bild, um es zu vergrößern.)

Mit „Restore Defaults“ werden alle registrierten Standardeinstellungen einer Anwendung wieder übernommen. „Advanced“ ermöglicht es dem Benutzer, spezielle Standardeinstellungen für eine Anwendung auszuwählen.

Hinweis: Um eine URL in der Benutzeroberfläche anzuzeigen, muss eine Anwendung diese URL in das digitale Zertifikat einbinden. Anwendungen ohne Signatur können keine URL anzeigen.

Advanced (Erweitert)

Abbildung 7 (Klicken Sie auf das Bild, um es zu vergrößern.)

Diese Ansicht zeigt alle Registrierungen der Anwendungen sowie die derzeit eingestellte Standardanwendung. Eine öffentliche Windows-API ermöglicht es Anwendungen, diese Fenster zu öffnen, so dass diese keine Benutzeroberfläche für die Dateizuordnung mehr benötigen. Es wird empfohlen, diese Benutzeroberfläche zu verwenden, anstatt eine benutzerdefinierte Schnittstelle zu erstellen.

Richtlinien und beste Praktiken für Standardprogramme:

Installation

Unter dem Betriebssystem zu installierende Anwendungen sollten genauso installiert werden wie unter XP. Darüber hinaus muss eine Anwendung ihr Schema für Standardanwendungen erstellen. Die Registrierung des neuen Schemas ermöglicht es einer Anwendung, alle Vorteile der neuen Funktionalität zu nutzen. Anwendungen, die einfach wie unter Windows XP installiert werden, funktionieren zwar noch, müssen aber registriert werden, um nach der Installation die Standardeinstellungen übernehmen zu können Eine Anwendung sollte bei der Installation Folgendes ausführen:

1. Installation der erforderlichen Bin-Dateien (wie unter XP).

2. Schreiben der Programm-IDs in HKLM (wie unter XP).

   Hinweis: Anwendungen müssen anwendungsspezifische ProgIDs für ihre Zuordnungen erstellen.

3. Erfassung der Dateizuordnungen auf Computerebene (wie unter XP).

4. Schreiben in das neue Standardprogramm-Schema (neu für Windows Vista).

Nach der Installation

Erlebnis beim ersten Start:

Anwendungen können wahlweise Sonderfunktionen beim ersten Start ausführen. Dies wird empfohlen. An dieser Stelle sollte die Anwendung dem Benutzer Fragen zu den persönlichen Präferenzen stellen. Anwendungen sollten keinen ersten Start auf Computerebene ausführen. Beim ersten Start sollten dem Benutzer zwei Auswahlmöglichkeiten geboten werden:

1. Übernahme der Standardeinstellungen der Anwendung (diese sollte die Standardvorgehensweise sein).

2. Benutzerdefinierte Einstellungen.

Bei der Übernahme der Standardeinstellungen sollte die API für die Programmvoreinstellungen aufgerufen werden, die alle registrierten Standardeinstellungen für eine Anwendung erfasst. Hierdurch werden die Standard-Dateizuordnungen von den Computereinstellungen in die benutzerdefinierten Einstellungen umgeändert.

Die Auswahl der benutzerdefinierten Einstellungen sollte den Benutzer zu der Dateizuordnungs-Benutzeroberfläche leiten. Anwendungen können die Dateizuordnungs-Benutzeroberfläche für eine bestimmte Anwendung in Windows programmatisch aufrufen. Dies ist die empfohlene Vorgehensweise

Standardeinstellungs-Benutzeroberfläche:

Anwendungen, die sich entscheiden, die Standardeinstellungs-Benutzeroberfläche anzuzeigen, sollten die neuen Standardprogramm-APIs verwenden, um eine anwendungszentrierte Version der Dateizuordnungen zu öffnen.

Beispiel für den Litware Media Player:

Abbildung 8

In dieser Ansicht sieht der Benutzer alle registrierten Standardeinstellung einer bestimmten Anwendung. Der Benutzer kann sehen, was zu einer bestimmten Anwendung gehört. Er erhält einen Überblick über die aktuellen Standardeinstellungen und kann diese für die neue Anwendung ändern. Mit einem Mausklick auf „Save“ (Speichern) werden die Aktualisierungen übernommen und das Fenster geschlossen. Mit einem Mausklick auf „Cancel“ (Abbrechen) wird das Fenster geschlossen. Dank der zur Verfügung gestellten Benutzeroberfläche müssen die Anwendungen keine Entwicklungsressourcen für die Wartung der Dateizuordnungs-Benutzeroberfläche aufwenden und falsche Einstellungen der Zuordnungen werden vermieden.

Prüfen, ob eine Anwendung die Standardanwendung ist:

Viele Anwendungen wie etwa Web-Browser oder E-Mail-Clients verfügen über Datei- und Protokollzuordnungen, die dem Benutzer allgemein bekannt sind. Beispiele hierfür sind HTTP:\ und Mailto:\. Diese Anwendungen führen im Allgemeinen eine Prüfung durch, um festzustellen, ob sie als Standardanwendungen konfiguriert wurden, sobald sie gestartet werden. Anwendungen sollten über die neuen Standardprogramm-APIs prüfen, ob sie als Standardanwendung konfiguriert wurden. Wenn die Anwendung keine Standardanwendung ist, sollte sie eine Benutzeroberfläche bieten, die es dem Benutzer ermöglicht:

1. Alle Einstellungen beizubehalten.

2. Die Anwendung als Standardanwendung zu übernehmen.

Anwendungen sollten darüber hinaus eine aktivierbare Option enthalten, die gewährleistet, dass die Anwendung den Benutzer darauf hinweist, wenn sie <Anwendung> nicht mehr die Standardanwendung ist. Anwendungen sollten NICHT automatisch die Standardeinstellungen übernehmen, ohne den Benutzer vorher zu fragen. Anwendungen sollten #1 implementieren, indem sie die Standardprogramm-APIs aufrufen, um alle registrierten Standardeinstellungen der Anwendung wiederherzustellen.

Ein Beispiel für die Nutzung des Internet Explorers:

Abbildung 9 (Klicken Sie auf das Bild, um es zu vergrößern.)

Registrierung mit Standardprogrammen.

Die Standardprogrammfunktion lässt jede Anwendung ausdrücklich angeben, für welche Dateizuordnungen und Protokolle diese als Standard angesehen werden wollen. Dies wird durch die Registrierung des folgenden Schemas in HKLM erreicht. Beachten Sie, dass „ApplicationDescription“ eine Stringfolge oder ein Verweis auf eine String-Ressource sein kann. Die letztere Option ermöglicht mehrsprachige Benutzeroberflächen.

HKLM\%APPLICATIONCAPABILITYPATH%
   ApplicationDescription = REG_EXPAND_SZ "@path\to\dll.dll,-resourceId"
   ApplicationName = REG_EXPAND "@path\to\dll.dll,-resourceId"
   \FileAssociations
   .file-extension = REG_SZ "file-extension-progid"
   \UrlAssociations
   url-scheme = REG_SZ "url-scheme-progid"
   \MIMEAssociations
      MIME = REG_SZ "mime-progrid"
   \Startmenu  REG_SZ            
   StartmenuInternet ="%app Name%"
          Mail ="%App Name%"

Hinweis: Hierbei handelt es sich um Pointer zu Anwendungen, die für Autorisierungen von HKLM\Software\Clients registriert wurden. Dieser Wert sollte der Name des Schlüssels unter HKLM\software\clients\StartmenuInternet oder HKLM\software\clients\Mail sein.

HKLM\Software\RegisteredApplications
   unique-app-name = REG_SZ "%APPLICATIONCAPABILITYPATH%"

Hinweis: „ApplicationDescription“ ist erforderlich. „ApplicationName“ ist jedoch eine optionale Eingabe, die es unterschiedlichen Arten von Anwendungen ermöglicht, auf die gleiche .exe-Datei zu verweisen und mit unterschiedlichen Namen anzuzeigen.

Hinweis: Um eine URL in der Benutzeroberfläche anzuzeigen, muss eine Anwendung diese URL in das digitale Zertifikat einbinden. Anwendungen ohne Signatur können keine URL anzeigen.

Ein Beispiel für die Nutzung des Contoso Web-Browsers:

Hinweis: Um die Lokalisierung zu ermöglichen, sollte es sich hierbei um eine DLL handeln.

HKLM\software\Contoso\WebBrowser\Capabilities
   Description =" The award-winning Web browser is better than ever. 
   Search the internet in second and find anything you want. Use 
   integrated tabs and new phishing detectors to enhance your internet experience."
\FileAssociations
  .htm = ContosoHTML
  .html = ContosoHTML
  .shtml = ContosoHTML
  .xht = ContosoHTML
  .xhtml = ContosoHTML
\UrlAssociations
  http = Contoso.Url.Http
  https = Contoso.Url.Https
  ftp = Contoso.Url.ftp
\Startmenu
  StartmenuInternet = "Contoso.exe"

HKLM\software\RegisteredApplications
  Contoso.WebBrowser.1.06 = software\Contoso\WebBrowser\Capabilities

ProgIds

Anwendungen müssen anwendungsspezifische ProgIDs bieten. Hierin müssen alle Informationen enthalten sein, die typischerweise in den Standardschlüssel geschrieben werden. Anwendungen können eine 1-zu-1-Anpassung der ProgID an das Protokoll/die Erweiterung vornehmen oder eine ProgID an mehrere Protokolle anpassen. Die Vorgehensweise ist beliebig und beide Methoden sind gleichwertig. In dem obigen Beispiel weist ContosoHTML auf eine einzige ProgID, die die „shellexecute“-Informationen für htm, html, shtml, xht und xhtml enthält. Für jedes Protokoll wird eine spezielle ProgID definiert. Auf diese Weise werden für jedes Protokoll unterschiedliche Ausführungs-Strings ermöglicht.

Wenn Sie eine ProgID für ein MIME definieren, muss die ProgID den CLSID-Subschlüssel zusammen mit der „Class“-ID für die entsprechende Anwendung enthalten. Dieser wird für eine Suche nach der „Class“-ID in der in HKLM gespeicherten MIME-Datenbank verwendet.

Wert-Definitionen.

Capabilities – Der Verzeichnis-Subschlüssel, unter dem alle Standardprogramm (Default Programs)-Informationen für eine bestimmte Anwendung zu finden sind. Der „Capabilities“-Subschlüssel befindet sich immer unter den Verzeichnisschlüsseln der Anwendungen.

Description – Default Programs ermöglicht es den Benutzern, informierte Entscheidungen zu treffen. Wir ermöglichen für jede Anwendung die Registrierung eines Beschreibungs-Strings, damit dieser den Benutzer über die Möglichkeiten der Anwendung informieren kann. Dieser Wert ist eine Eigenschaft (Property) unter „\capabilities“.

Hinweis: Dies ist ein Pflichtfeld. Für jede Anwendung muss hier ein Eintrag vorgenommen werden, der in der Benutzeroberfläche angezeigt wird. Denken Sie daran, Ihre Strings zu lokalisieren.

ApplicationName – Gibt den Namen an, der in der „Default Programs“-Benutzeroberfläche angezeigt wird. Wenn dieses Feld nicht ausgefüllt wird, verwendet das Standardprogramm den Namen der mit der ersten für die Anwendung registrierten ProgID verbundenen .exe-Datei. Der unter „Application“ angegebene Name sollte immer dem „RegisteredApplications“-Namen entsprechen.

FileAssocations – Der Dateizuordnungs-Subschlüssel enthält alle spezifischen Dateizuordnungen der Anwendung. Jede Dateizuordnung wird als Eigenschaft des „FileAssocations“-Subschlüssels gespeichert. Jede Erweiterung sollte auf eine anwendungsspezifische und nicht allgemeine ProgID hinweisen.

UrlAssociations – Im „URL Associations“-Subschlüssel werden alle von der Anwendung übernommenen URL-Zuordnungen angegeben. Jede URL-Zuordnung wird als Eigenschaft des „FileAssocations“-Subschlüssels gespeichert. Jedes Protokoll sollte auf eine anwendungsspezifische und nicht allgemeine ProgID hinweisen.

MIMEAssociations – Im „MIME Associations“-Subschlüssel werden alle von der Anwendung übernommenen MIME-Zuordnungen angegeben. Jede MIME-Zuordnung wird als Eigenschaft des „MIMEAssocations“-Subschlüssels gespeichert. Der Name sollte genau dem in der MIME-Datenbank gespeicherten MIME-Namen entsprechen und der Wert sollte eine anwendungsspezifische ProgID sein, die die entsprechende CLSID enthält.

Startmenu – Der „Startmenu“-Subschlüssel ist für Internet- und E-Mail-Slots im Startmenü reserviert. Anwendungen, die darüber hinaus als Bewerber für diese Speicherorte registriert werden, können diese Funktionalität mit ihrem eigenen „Default Programs“-Eintrag verknüpfen. Durch die Verknüpfung mit der Startmenü-Registrierung kann eine Anwendung anzeigen, dass sie auch den entsprechenden E-Mail- oder Internet-Link wünscht, wenn dieser in Standardprogrammen angezeigt wird. Wenn diese Informationen angegeben werden und der Benutzer die Standardeinstellungen für dieses Programm wiederherstellt, übernimmt dieses Programm auch den Startmenü-Speicherort. Die Registrierung sollte nur unter dem Namen des registrierten Schlüssels unter HKLM\software\clients\StartMenuInternet oder HKLM\software\clients\Mail erfolgen. Im Fall eines E-Mail-Clients wird hierdurch auch der Standard-MAPI-Client eingestellt.

Hinweis: Es steht eine separate Startmenü-Registrierung zur Verfügung. Weitere Informationen hierzu finden Sie unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_adv/registeringapps.asp

HKLM\software\RegisteredApplications – „RegisteredApplications“ ist erforderlich, damit das Betriebssystem weiß, wo die gesamten Informationen über jede Anwendung gespeichert sind. Dies sollte der Name der Anwendung sein.

Nutzung der „Default Programs“-APIs

Sobald eine Anwendung registriert wurde, kann sie eine Reihe von APIs nutzen, um das Erlebnis für den Benutzer zu verbessern. Dieses Interface sollte in der Arbeitsversion des Monats Juni verfügbar sein. Die Beta2-Version enthält eine etwas andere Benutzeroberfläche, die aufgrund des Kunden-Feedbacks verändert wurde.

typedef [v1_enum] enum tagASSOCIATIONLEVEL
{
   AL_MACHINE,
   AL_EFFECTIVE,
   AL_USER
} ASSOCIATIONLEVEL;

typedef [v1_enum] enum tagASSOCIATIONTYPE
{
   AT_FILEEXTENSION,
   AT_URLPROTOCOL,
   AT_STARTMENUCLIENT,
   AT_MIMETYPE
} ASSOCIATIONTYPE;

[
   object,
   uuid(4e530b0a-e611-4c77-a3ac-9031d022281b),
   pointer_default(unique),
   helpstring("Application File Extension and URL Protocol Registration")
]

interface IApplicationAssociationRegistration : IUnknown
{
   HRESULT QueryCurrentDefault(
      [in, string] LPCWSTR pszQuery,
      [in] ASSOCIATIONTYPE atQueryType,
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [out, string] LPWSTR* ppszAssociation);

   HRESULT QueryAppIsDefault(
      [in, string] LPCWSTR pszQuery,
      [in] ASSOCIATIONTYPE atQueryType,
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [in, string] LPCWSTR pszAppRegistryName,
      [out] BOOL* pfDefault);

   HRESULT QueryAppIsDefaultAll(
      [in] ASSOCIATIONLEVEL alQueryLevel,
      [in, string] LPCWSTR pszAppRegistryName,
      [out] BOOL* pfDefault);

   HRESULT SetAppAsDefault(
      [in, string] LPCWSTR pszAppRegistryName,
      [in, string] LPCWSTR pszSet,
      [in] ASSOCIATIONTYPE atSetType);

   HRESULT SetAppAsDefaultAll(
      [in, string] LPCWSTR pszAppRegistryName);

   HRESULT ClearUserAssociations();
}
   
interface IApplicationAssociationRegistrationUI : IUnknown
{
   HRESULT LaunchAdvancedAssociationUI([in, string] LPCWSTR pszAppRegName);
}

AssociationLevel

AL_MACHINE – Gibt die Computer-Standardeinstellung für eine Erweiterung zurück.

AL_EFFECTIVE – Gibt den effektiven Standardwert für den aktuellen Benutzer zurück.

Hinweis: Dies sollte von den meisten Anwendungen genutzt werden.

AL_USER – Gibt die Standardeinstellung pro Benutzer zurück. Wenn keine benutzerdefinierte Standardeinstellung vorhanden ist, wird der Fehlercode 0x80070483 zurückgegeben.

AssociationType

AT_FILEEXTENSION – Wird für die Suche nach einer Dateierweiterung wie .htm oder mp3 verwendet.

AT_URLPROTOCOL – Wird für die Suche nach einem Protokoll wie http:// oder mailto: verwendet.

AT_STARTMENUCLIENT – Wird für die Suche nach dem Eigentümer des Startmenü-Clients für den Mail- oder Internet-Link verwendet.

AT_MIMETYPE – Wird für die Suche nach der MIME-Art wie etwa audio/mp3 gesucht.

QueryCurrentDefault

Geben Sie den String der Dateierweiterung (.mp3, HTTP etc.) und die Art der Erweiterung an, um die ProgID für die aktuelle Standardeinstellung zu erhalten. Anwendungen sollten typischerweise die AL_EFFECTIVE-Zuordnungsebene verwenden, da diese die effektiven Standardeinstellungen für den Benutzer bestimmt. Der Abrufer muss die zurückgegebene ProgID-String mit CoTaskMemFree verwenden.

QueryAppIsDefault

Geben Sie den String der Dateierweiterung (.mp3, HTTP etc.) und die Zuordnungsebene der registrierten Anwendungsmaßnahme an, um einen BOOL zu erhalten, sofern die Anwendung Eigentümer der Standardeinstellung ist. Anwendungen sollten typischerweise die AL_EFFECTIVE-Zuordnungsebene verwenden, da diese die effektiven Standardeinstellungen für den Benutzer bestimmt.

QueryAppIsDefaultAll

Geben Sie die Zuordnungsebene und die registrierte Anwendung an, um einen BOOL zu erhalten, sofern die Anwendung Eigentümer aller Standardeinstellung derselben ist. Anwendungen sollten typischerweise die AL_EFFECTIVE-Zuordnungsebene verwenden, da diese die effektiven Standardeinstellungen für den Benutzer bestimmt.

SetAppAsDefault

Geben Sie den Namen der registrierten Anwendung, die Dateierweiterung (.mp3, HTTP etc.) und die Art der Dateierweiterung an. Der Standardwert wird auf die registrierte Anwendung eingestellt.

SetAppAsDefaultAll

Geben Sie den Namen der registrierten Anwendung an, um alle registrierten Standardeinstellungen der Anwendung zu bestimmen.

ClearUserAssociations

Löscht alle benutzerdefinierten Zuordnungen für den aktuellen Benutzer und setzt denselben auf die vorhandenen Computer-Standardeinstellungen zurück. Derzeit besteht kein definiertes Partner- oder Dritt-Szenario, von dem wir einen Abruf dieser Funktion erwarten könnten. Dennoch sollte diese Möglichkeit angeboten werden.

LaunchAdvancedAssociationUI

Der angegebene Registrierungsname der Anwendung muss einem der unter HKLM\Software\RegisteredApplications registrierten Werte entsprechen. Hierdurch wird die Set Program Associations-Seite für die angegebene Anwendung geöffnet. Diese Funktionalität ist für Anwendungen vorgesehen, die einen direkten UX-Link zu den erweiterten Zuordnungseinstellungen bieten möchten.

Hinweis: Diese API steht erst ab Windows Vista und für spätere Versionen zur Verfügung. Anwendungen, die vorherige Betriebssysteme (XP, Win2K und Win98) unterstützen, sollten ihren bereits vorhandenen Standardeinstellungs-Code für diese Betriebssysteme nutzen und einen SKU-Check durchführen, um zwischen Windows Vista und späteren Versionen dieses Betriebssystems zu unterscheiden.

Code-Beispiele

Das folgende Beispiel zeigt die Implementierung über eine API anhand der Registrierung für den Contoso Web-Browser:

Abfrage, ob der Contoso Web-Browser Eigentümer seiner gesamten Standardeinstellungen ist:

HRESULT CheckContosoHasAllDefaults(__out BOOL* pfHasAllDefaults)
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                 (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->QueryAppIsDefaultAll(AL_EFFECTIVE,
                                        L"Contoso.WebBrowser.1.06",
                                        pfHasAllDefaults);

        pAAR->Release();
    }

    return hr;
}

Abfrage, ob der Contoso Web-Browser Eigentümer der Standardeinstellung für .htm ist:

HRESULT CheckContosoHasDotHTM(__out BOOL* pfHasDotHTM)
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                  (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->QueryAppIsDefault(L".htm",
                                     AT_FILEEXTENSION,
                                     AL_EFFECTIVE,
                                     L"Contoso.WebBrowser.1.06",
                                     pfHasDotHTM);
        pAAR->Release();
    }
    return hr;
}

Einstellung des Contoso Web-Browsers als Standardprogramm für .HTM:

HRESULT SetContosoAsDefaultForDotHTM()
{
    IApplicationAssociationRegistration* pAAR;

    HRESULT hr = CoCreateInstance(CLSID_ApplicationAssociationRegistration,
                                  NULL,
                                  CLSCTX_INPROC,
                                  __uuidof(IApplicationAssociationRegistration),
                                  (void**)&pAAR);
    if (SUCCEEDED(hr))
    {
        hr = pAAR->SetAppAsDefault(L"Contoso.WebBrowser.1.06",
                                   L".htm",
                                   AT_FILEEXTENSION);

        pAAR->Release();
    }

    return hr;
}

Dokumentationen zur Dateizuordnung

Weitere Informationen zur Erstellung einer Dateizuordnung finden Sie unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fileassoc.asp

Weitere Informationen zur Registrierung von Programmen mit Client-Arten finden Sie unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_adv/registeringapps.asp

Weitere Informationen über Verb- und Dateizuordnungen finden Sie unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_verbs.asp

Weitere Informationen zu Dateiarten finden Sie unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_file_types.asp

 

Programmkompatibilitätsassistent in Windows Vista - vorliegende Dokumentation

Einführung in PCA

Der Program Compatibility Wizard (Programmkompatibilitäts-Assistent) im Zubehör und der Kompatibilitäts-Reiter in den Dateieigenschaften sind nützliche Tools zur Behebung von Programmkompatibilitäts-Problemen unter Windows XP. Die Haupteinschränkung dieser Tools besteht in der Erkennbarkeit und der Tatsache, dass der Benutzer wissen muss, wann diese Tools anzuwenden sind Der „Program Compatibility Assistant (PCA)“ ist eine neue Funktion unter Windows Vista, die es ermöglicht, ältere Programme mit Kompatibilitätsproblemen automatisch besser laufen zu lassen. Wenn der PCA ein bekanntes Kompatibilitätsproblem erkennt, nachdem der Benutzer ein älteres Programm gestartet hat, informiert er denselben hierüber und bietet Lösungen an, die beim nächsten Start des Programms angewendet werden können.

Hinweis: Der PCA ist eine reine Client-Funktion und steht nicht auf dem Server zur Verfügung.

Die folgenden Abschnitte beschreiben die Umstände, unter denen der Benutzer erwartungsgemäß mit dem Eingreifen des PCA rechnen muss, und bieten Informationen zu der Wahrnehmung durch den Benutzer, den unter den verschiedenen Umständen angewendeten Lösungen und der späteren Verwaltung der von dem PCA vorgenommenen Einstellungen. Der letzte Abschnitt beschreibt, wie Programme von dem PCA ausgeschlossen werden können.

PCA-Szenarien

Erkennung fehlgeschlagener Installation.

Eines der Hauptszenarien für den PCA ist die Erkennung einer fehlgeschlagenen Installation unter Windows Vista und das Angebot der Anwendung des Windows XP-Kompatibilitätsmodus als Lösung.

Der Hauptgrund für fehlgeschlagene Installationen besteht darin, dass Installationsprogramme die kompatiblen Versionen des Windows-Betriebssystems prüfen. Diese Installationsprogramme blenden in der Regel eine Fehlermeldung ein, die besagt, dass die aktuelle Windows-Version nicht unterstützt wird und beenden das Programm. Um weitere Informationen hierzu zu liefern, verwenden Programme im Allgemeinen GetVersion oder die GetVersionEx-APIs, um Angaben zu dem aktuellen Windows-Betriebssystem zu erhalten. Unter Windows Vista geben diese APIs 6 als Hauptversion an. Wenn das Programm fest eingestellt ist, nach der Hauptversion 5 von Windows XP zu suchen, schlägt die Installation unter Windows Vista fehl. Der im Kompatibilitätsmodus von Windows XP enthaltene XPVersionLie-Fix sendet die XP-Version des Betriebssystems an das Programm, wenn dieses GetVersion oder GetVersionEx-APIs aufruft.

Nachfolgend finden Sie ein Beispiel für eine Fehlermeldung der Microsoft Intellitype-Software für Tastatur und Maus, deren Installation unter Windows Vista während der internen Anwendungskompatibilitäts-Tests fehlgeschlagen ist.

Abbildung 10

Der PCA erkennt dieses Szenario und zeigt nach Abbruch der Installation die folgende Benutzeroberfläche an.

Abbildung 11

Wenn der Benutzer die Option „Reinstall using recommended settings“ (Neuinstallation mit den empfohlenen Einstellungen) wählt, wird der Kompatibilitätsmodus von Windows XP auf das Installationsprogramm angewendet und dasselbe automatisch neu gestartet.

Weitere Details zu den Hintergründen werden durch die nachfolgenden Fragen und Antworten erklärt:

1. Wie stellt sich die Erkennungslogik dar und woher weiß der PCA, dass die Installation aufgrund von Versionsproblemen fehlgeschlagen ist?

   Der PCA sucht nicht speziell nach aufgrund von Versionsproblemen fehlgeschlagenen Installationen. Die von dem PCA genutzte Logik besteht in der Erkennung fehlgeschlagener Installationen. Der PCA überwacht ein als Installation unter Windows Vista erkanntes Programm und prüft, ob dasselbe einen Eintrag in „Add or Remove Programs (ARP)“ (Programme hinzufügen/entfernen) schreibt. Wenn kein Eintrag in ARP erfolgt, schließt der PCA daraus, dass die Installation nicht erfolgreich abgeschlossen wurde und wartet auf den Abbruch des Installationsvorgangs bevor die Benutzeroberfläche angezeigt wird.

2. Wie erhält der PCA Informationen über die Setup-Programme?

   Der PCA nutzt die User Access Control (UAC)-Funktion unter Windows Vista, um zu erkennen, ob es sich um ein Installationsprogramm handelt. Die UAC umfasst die Erkennung von Installationsprogrammen und gewährleistet, dass erkannte Installationsprogramme auf einer übergeordneten Ebene (als Administrator) ausgeführt werden. Dies umfasst den Erhalt des Nachweises der Administratorrechte oder der Bestätigung durch den Benutzer vor dem Start des Programms.

3. Welche Funktionen haben die Optionen im PCA-Installationsdialog?

   • „Reinstall using recommended settings“ (Neuinstallation unter Verwendung der empfohlenen Einstellungen)

     Diese Option gilt für den Kompatibilitätsmodus von Windows XP und startet das Programm neu. Weitere Informationen zur Anwendung des Kompatibilitätsmodus finden Sie in dem nachfolgenden Abschnitt über die Verwaltung der PCA-Einstellungen.

   • „The program installed correctly“ (Die Installation wurde erfolgreich abgeschlossen)

     In einigen Fällen kann es passieren, dass der PCA auf ein Installationsprogramm trifft, das erfolgreich abgeschlossen wurde, aber keinen Eintrag in ARP erstellt hat. In diesen Fällen kann der Benutzer die folgende Option verwenden:

   • „Cancel“ (Abbrechen)

     Der PCA führt hierbei keine Aktion aus.

Bei allen vorgenannten Optionen wird der PCA-Dialog ausgeblendet. Der PCA wird kein weiteres Mal für dasselbe Installationsprogramm aktiviert, sofern der Benutzer nicht im vorherigen Dialog die „Abbrechen“-Option gewählt hat.

Erkennung von fehlgeschlagenen Programmen unter UAC

Im zweiten Szenario erkennt der PCA fehlgeschlagene Programme während der Ausführung unter der „User Access Control (UAC)“ (Benutzerzugangskontrolle). Der PCA erkennt dieses besondere Szenario eines Fehlers eines nicht übergeordneten Programms während des Starts einer Child-Exe, da diese als Installationsprogramm erkannt wird und auf übergeordneter Ebene ausgeführt werden muss. Dies ist typischerweise der Fall bei Programmen, die versuchen eine „Updater.exe“-Datei zu starten. Wenn die gleiche „Updater.exe“-Datei im Explorer ausgeführt wird, erfolgt die Ausführung wie erwartet auf übergeordneter Ebene, da der Explorer in der Lage ist, die Benutzeroberfläche für die UAC-Zustimmung zu öffnen und das Programm auf übergeordneter Ebene auszuführen.

In diesem Fall wendet der PCA den ELEVATECREATEPROCESS-Kompatibilitätsmodus an, der es dem Programm ermöglicht, die Child-Exe beim nächsten Mal erfolgreich als Administrator zu starten. Bei dem nächsten Versuch des Programms, die Child-Exe zu starten, sieht der Benutzer die Benutzeroberfläche für die UAC-Zustimmung und kann die Administratorbefugnisse nachweisen oder bestätigen.

Nachfolgend finden Sie ein Beispiel anhand eines Testprogramms für einen PCA-Dialog, der in diesem Szenario eingeblendet wird.

Abbildung 1 2

Hier hat das Testprogramm erfolglos versucht, einen Updater zu starten, der auf übergeordneter Ebene ausgeführt werden muss. Dies wurde von dem PCA erkannt. Bei der nächsten Ausführung des Programms und dem Versuch, den Updater zu starten, wird derselbe erfolgreich auf übergeordneter Ebene ausgeführt. Der Benutzer sieht die nachfolgend abgebildete Benutzeroberfläche für die UAC-Zustimmung.

Abbildung 1 3

Weitere Details zu den Hintergründen werden durch die nachfolgenden Fragen und Antworten erklärt:

1. Wie stellt sich die Erkennungslogik dar und woher weiß der PCA, dass der Start einer Child-Exe, die als Administrator ausgeführt werden muss, fehlgeschlagen ist?

   Die Erkennung dieses Szenarios erfolgt durch die Instrumentierung in der CreateProcess-API, um Fälle zu erkennen, in denen der Start eines Child-Prozesses aufgrund der Anforderung der Ausführung auf übergeordneter Ebene fehlschlägt.

2. Warum bietet dieser PCA-Dialog keine Optionen?

   Aufgrund der hohen Wahrscheinlichkeit der Problemerkennung in diesem Szenario wird die Lösung (ELEVATECREATEPROCESS-Kompatibilitätsmodus) automatisch angewendet und dem Benutzer werden keine Optionen zur Verfügung gestellt.

„Inform Users About Compatibility Issues with Known Programs at Startup“ (Informierung der Benutzer über Kompatibilitätsprobleme mit bekannten Programmen beim Start).

Neben den zwei folgenden Erkennungsszenarios bei Runtime-Problemen umfasst der PCA auch ein Szenario, in dem er beim Start eines Programms eine Liste von Programmen mit bekannten Kompatibilitätsproblemen einblendet. Diese Liste wird in der Anwendungskompatibilitäts-Datenbank des Systems gespeichert. Dieses Szenario stammt aus Windows XP und diese Meldungen sind als „Application Help“-Meldungen (Anwendungshilfe oder auch „apphelp“) bekannt.

Es gibt zwei Arten von „apphelp“-Meldungen. Sofern ein Programm bekanntermaßen inkompatibel ist und bei Ausführung erhebliche negative Auswirkungen auf das System haben kann (zum Beispiel einen Stop-Fehler oder Blockierung des Boot-Vorgangs nach der Installation etc.), wird eine Blockierungsmeldung wie unten abgebildet angezeigt.

Hinweis: Microsoft erhält von den ISV eine Genehmigung für die gesperrten Programme.

Abbildung 1 4

Die andere Meldungsart beinhaltet keine Blockade und entspricht der Abbildung unten. Diese Meldung wird bei Programmen mit bekannten Kompatibilitätsproblemen ohne ernsthafte Auswirkungen auf das System angezeigt.

Abbildung 1 5

In beiden Fällen sendet „Check for solutions“ einen Windows-Fehlerbericht, um eine Online-Antwort von Microsoft zu erhalten. Diese Antworten werden in der Client-Benutzeroberfläche „Solutions to Problems“ (wercon.exe) (Problemlösungen) angezeigt. Typischerweise gibt es drei Arten von Antworten:

• Der Benutzer wird auf ein ISV-Update für das Programm hingewiesen.

• Der Benutzer wird auf eine ISV-Website mit weiteren Informationen hingewiesen.

• Der Benutzer wird auf einen Artikel mit weiteren Informationen in der „Microsoft Knowledge“-Datenbank hingewiesen.

Verwaltung der PCA-Einstellungen.

Die Kompatibilitätsmodi werden durch die Einstellung eines Registry-Keys unter

„Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers“ mit dem Key-Namen = „vollständiger Pfad der .exe“ und dem String-Wert = „Name des angewendeten Kompatibilitätsmodus“ auf die Programme angewendet.

Im Fall des Installationsszenarios:

• Der Name des Kompatibilitätsmodus lautet WINXPSP2 und wird auf die „installer.exe“-Datei angewendet.

• Der Registry-Key wird unter HKEY_LOCAL_MACHINE eingestellt, damit diese Lösung für alle Benutzer wirksam wird.

Im Fall des UAC-Szenarios:

• Der Name des Kompatibilitätsmodus lautet ELEVATECREATEPROCESS und wird auf die „program.exe“-Datei angewendet. Der Registry-Key wird unter HKEY_CURRENT_USER eingestellt und die Lösung gilt nur für den aktuellen Benutzer.

• Diese Schlüssel müssen gelöscht werden, um die von dem PCA angewendeten Kompatibilitätsmodi zu entfernen.

Programme vom PCA ausschließen.

Der PCA dient dazu, Probleme mit älteren Programmen zu erkennen und nicht für Windows Vista entwickelte Programme zu kontrollieren. Die beste Option zum Ausschluss eines Programms vom PCA besteht darin, mit dem Programm ein Anwendungsmanifest mit Kennzeichnung der Ausführungsebene (entweder Administrator oder eingeschränkter Benutzer) für die UAC einzubinden. Hierdurch wird das Programm für die Ausführung unter der UAC (und unter Windows Vista) getestet und der PCA sucht nach diesem Manifest und schließt das Programm aus. Dies gilt gleichermaßen für Installations- und normale Programme. Weitere Informationen zur UAC und zur Erstellung dieses UAC-Manifests finden Sie unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp.

Eine zur Verfügung stehende „Gruppenrichtlinien“-Einstellung ermöglicht bei Bedarf die Deaktivierung des PCA für alle Programme.

Der Name der Richtlinie lautet „Turn Off Program Compatibility Assistant“. Die Richtlinie steht unter Administrative Templates -> Windows Components -> Application Compatibility im „Group Policy“-Editor (gpedit.msc) zur Verfügung.

Verwaltung von Apphelp-Meldungen.

Ein IT-Experte in einem Unternehmen kann das „Compatibility Administrator“-Tool nutzen, um die in der Anwendungskompatibilitäts-Datenbank des Systems vorhandenen „Apphelp“-Einträge zu deaktivieren oder benutzerdefinierte Datenbanken hinzuzufügen, die „Apphelp“-Meldungen für Programme in seinem Unternehmen enthalten.

Das „Compatibility Administrator“-Tool wird als Teil des „Application Compatibility“-Toolkits geliefert. Weitere Informationen über das Toolkit finden Sie unter https://www.microsoft.com/technet/windowsvista/appcompat/tools.mspx

 

Graphical Device Interface (GDI)

 

Painting (WM_PAINT) Verhaltensunterschiede

Auswirkung der Funktion

Gering

Kurze Beschreibung

Als Teil des Desktop Window Managers hat Microsoft leichte aber wichtige Änderungen der Art und Weise vorgenommen, in der Anwendungen auf dem Bildschirm dargestellt werden. Vor Windows Vista wurde ein hwnd direkt auf den Bildschirm gezeichnet. Diese Vorgehensweise bot gewisse Vorteile, schränkte aber die Anzeige und Verwaltungsmöglichkeiten für Windows-Fenster auf oberster Ebene ein. In Windows Vista werden alle Fenster auf oberster Ebene in einer Offscreen-Bitmap gerendert (vergleichbar mit WS_EX_LAYERED) und der Desktop Window Manager kombiniert die Bilder, um den Desktop zu zeichnen.

Erscheinungsform

Schwarze Bereiche um Tool-Tipps, Popup-Menüs, Sprechblasen, Splash-Screens etc.

Dies kann passieren, wenn die Anwendung nicht den gesamten hwnd gezeichnet hat – üblicherweise, weil die Anwendung angenommen hat, dass die Pixel im Hintergrundfenster ausreichen. Microsoft arbeitet aktiv an diesem Bereich. Versuchen Sie daher nicht, die Darstellung auf der Grundlage der aktuellen Bits zu optimieren, sondern senden Sie uns bitte Ihr Feedback.

Schwarze Einblendungen.

Dieses Problem tritt auf, wenn Anwendungen Zeichnungen ausführen, die nicht Teil eines „WM_PAINT“ sind. Der „USER“ erkennt, dass die Anwendung zeichnet und zeichnet den Desktop neu, obwohl die Anwendung den hwnd möglicherweise noch nicht fertig gestellt hat. In diesem Fall enthält die Hintergrund-Bitmap nicht initialisierte Pixel (Schwarz). Auch an diesem Bereich arbeitet Microsoft aktiv. Senden Sie uns also bitte Ihr Feedback zu Bereichen, die Ihrer Meinung nach einer Verbesserung bedürfen.

Glas wird von einer Anwendung nicht angezeigt.

Dies kann passieren, wenn eine Anwendung in dem Nicht-Client-Bereich des Fensters (der Titelleiste) zeichnet.

Weiche Ränder, benutzerdefinierte Schatten und andere Spezialeffekte.

Diese Effekte werden oftmals mit GetDC(NULL) erzielt. Das Lesen und Schreiben in GetDC(NULL) scheint jedoch Probleme zu verursachen, wenn Anwendungen auf einer Bitmap basieren, anstatt direkt auf den Bildschirm zu zeichnen. Das Lesen und Schreiben auf dem Bildschirm erfolgt erheblich langsamer als unter Windows XP. Darüber hinaus werden GDI-Rasteroperationen nicht unterstützt (wir unterstützen jedoch XOR).

Verbesserte asiatische Schriftarten (Fonts)

Windows Vista hat zahlreiche Änderungen an den chinesischen, japanischen und koreanischen Schriftarten vorgenommen, um deren Lesbarkeit zu verbessern. Aus diesem Grund kann das Textlayout bei Anwendung dieser neuen Schriftarten ein wenig abweichen, da die Schriftzeichen andere Breiten haben. Testen Sie, wie sich der Text auf dem Bildschirm und auf Ausdrucken darstellt. Prüfen Sie auch Bereiche, in denen asiatische Sprachen mit lateinischen Schriftzeichen gemischt werden können (zum Beispiel Englisch).

 

Wiedergabeleistung

Auswirkung der Funktion

Gering

Kurze Beschreibung

Die meisten Anwendungen laufen unter Windows Vista gleich schnell oder schneller; dennoch gibt es einige Änderungen, die beachtet werden müssen.

Erscheinungsform

Hat sich die gesamte GDI-Rendergeschwindigkeit verringert?

Einfache GDI-Objekte wie etwa LineTo und Rectangle werden nun durch die Software und nicht durch die Grafikkarte gerendert, um die Anzeigetreiber erheblich zu vereinfachen. Wir erwarten Auswirkungen nur auf sehr wenige echte Anwendungen, würden uns jedoch in einem solchen Fall über Ihr Feedback freuen.

Werden Texte langsamer gezeichnet?

Aufrufe wie etwa DrawText unterstützen internationale und ostasiatische Sprachen besser. Wir glauben nicht, dass sich dies auf echte Anwendungen auswirkt, würden uns aber andernfalls über Ihr Feedback freuen.

Reduzierter Anwendungs-Adressraum?

Die Bitmap für das Fenster auf oberster Ebene wird im Adressraum der Anwendung gespeichert (siehe Abschnitt zu Zeichenoperationen). Hierdurch wird der verfügbare Adressraum um einige wenige Megabyte reduziert.

Lesen von und schreiben in GetDC(NULL)?

Diese Operation ist langsamer als in den vorherigen Windows-Versionen, da Anwendungen jetzt in eine Offscreen-Bitmap anstatt direkt auf den Bildschirm rendern. Versuchen Sie so weit als möglich in einen HDC auf der Grundlage Ihres HWND zu zeichnen oder überlappende Fenster zu erstellen. GetDC(NULL) ist immer noch die bevorzugte Methode zur Erstellung von Bildschirm-Screenshots.

 

UIPI (GUI- Teil der Benutzerkontenkontrolle)

Auswirkung der Funktion

Gering

Kurze Beschreibung

Als zusätzliche Verteidigungsschicht gegen bösartige Software ermöglicht Windows Vista die Ausführung verschiedener Benutzeroberflächen-Anwendungen auf drei verschiedenen Ebenen der UI-Priorität. Anwendungen können frei mit anderen Anwendungen der gleichen oder einer geringeren Berechtigungsstufe interagieren, sind aber nicht in der Lage, mit Anwendungen höherer Berechtigungsstufen zu interagieren oder diese zu modifizieren. Die meisten Anwendungen laufen mit mittleren Berechtigungsstufen, während Anwendungen, die Administratorenrechte benötigen, in einem höheren Modus laufen. Eingeschränkte Prozesse wie etwa der Internet Explorer mit niedriger Berechtigung nutzen die niedrigste Berechtigungsstufe.

Genauer gesagt: Anwendungen auf niedrigeren Berechtigungsstufen können grundsätzlich keine Mitteilungen an Anwendungen auf höheren Berechtigungsstufen senden, sofern die Anwendung der höheren Berechtigungsstufe dies nicht ausdrücklich durch Aufruf von ChangeWindowMessageFilter() erlaubt. Gleichermaßen können Anwendungen mit niedrigeren Berechtigungsstufen ein HWND einer Anwendung mit einer höheren Berechtigungsstufe zwar lesen, aber nicht modifizieren. Aus Kompatibilitätsgründen geben SendMessage und andere APIs eine Erfolgsmeldung zurück, auch wenn die API aufgrund von Berechtigungsproblemen blockiert wurde. Wenn die Kompatibilitätsauswirkung hoch und das Sicherheitsrisiko gering ist, dürfen auch Anwendungen mit niedriger Berechtigungsstufe in einigen Fällen unaufgefordert Meldungen an Anwendungen mit höheren Berechtigungsstufen senden.

Erscheinungsform

Anwendungen interagieren nicht mehr mit anderen Anwendungen.

Hilfsprogramme, die Fenster verschieben, Tastenoperationen für Sie ausführen, den Fenstern zusätzliche Buttons hinzufügen etc.

Ausschneiden und Einfügen zwischen verschiedenen Anwendungen funktioniert nicht mehr.

Funktioniert dies überhaupt und unterstützt diese Funktion alle verschiedenen Formate der Zwischenablage (rtf, HTML etc.)?

Behelfsmaßnahmen

Journaling-Hooks

WH_JOURNALPLAYBACK und WH_JOURNALRECORD sind inhärent übergreifende Prozesse, die die höchste Berechtigungsstufe benötigen. Die SendInput()-API, die in vielen Fällen keine vollständigen Benutzeroberflächen-Berechtigungen benötigt, kann oftmals anstelle der Journaling-Hooks (Einsprungpunkte) verwendet werden.

Für Programme, zu denen Ihnen der Quellcode zur Verfügung steht, empfehlen wir Ihnen, jeden Code zu prüfen, der die folgenden APIs verwendet, da diese oftmals auf übergreifende Prozesse hinweisen:

• SendInput

• RegisterWindowMessage

• BroadcastSystemMessageEx

• BroadcastSystemMessage

• SetWindowsHook

• SetWindowsHookEx

• CallNextHookEx

• CallNextHook

• SetWinEventHook

• AttachThreadInput

• FindWindowEx

• FindWindow

• CreateDesktop

• CreateDesktopEx

• OpenDesktop

• OpenInputDesktop

• EnumDesktops

• EnumDesktopWindows

• SwitchDesktop

• SetThreadDesktop

• GetThreadDesktop

• CloseDesktop

• CreateWindowStation

• OpenWindowStation

• EnumWindowStations

• CloseWindowStation

• GetProcessWindowStation

Dies ist weder eine erschöpfende Liste noch eine Garantie für erforderliche Änderungen; es ist jedoch eine gute Ausgangsbasis zur Ermittlung von Problemen im Gegensatz zur Minimierung falscher positiver Werte. Sie können Quelldateien mit findstr /s /g:temp.txt *.c *.cpp *.h *.hpp suchen; wobei temp.txt die in eine Textdatei kopierte obige Liste der APIs ist.

 

Hohe Dpi-Skalierung

Auswirkung der Funktion

Gering

Kurze Beschreibung

Auf Systemen, die hohe dpi-Einstellungen verwenden, werden Anwendungen, die von sich aus keine hohen dpi-Einstellungen verstehen, automatisch vergrößert.

Erscheinungsform

Die Pixelgrößen waren für lange Zeit einigermaßen konstant, doch LCD-Hersteller bringen in zunehmendem Maße Monitore mit immer kleineren, als „High Dots per Inch (dpi)“ bekannten Pixeln heraus. Wenn eine Anwendung die gleiche Anzahl an Pixeln wie auf einem 96 dpi-Bildschirm auf einem „High dpi“-Bildschirm verwendet, erscheint diese Anwendung sehr klein. Windows Vista bietet erstmals die Möglichkeit, für 96 dpi-Bildschirme geschriebene Anwendungen zu vergrößern, indem die Bitmap der Anwendung größer gerendert wird. Wie alle Bitmap-Skalierungen kann auch diese zu einiger Unschärfe führen. Ansonsten wird jedoch ein korrekt gerendertes Bild in der richtigen Größe dargestellt. Anwendungen können „high dpi“ auch von vornherein unterstützen, um ein möglichst scharfes Bild darzustellen. Derzeit können Anwendungen die Skalierung abschalten & und sich selbst durch Aufruf von SetProcessDPIAware() als dpi-erkennend erklären. Ein manifest-basiertes Verfahren, um dies zu erklären, wird derzeit untersucht. Weitere Informationen zur Entwicklung von Anwendungen, die „high dpi“ standardmäßig unterstützen, finden Sie unter https://msdn.microsoft.com/library/en-us/dngdi/html/highdpiapp.asp.

Der Rest dieses Abschnitts befasst sich mit den potenziellen Problemen von Anwendungen ohne DPI-Erkennung. Anwendungen fragen Windows beispielsweise: „Wie viele Pixel beträgt die Breite der Scroll-Leiste?“. Wenn eine 96dpi-Anwendung fragt, gibt Windows Vista der Anwendung die 96dpi-Antwort. Es gibt jedoch auch Fälle, in denen Windows keine Antwort auf der Grundlage der Anwendung gibt; üblicherweise, weil Windows Vista noch nicht genügend Informationen erhalten hat (wir bitten um Ihr Feedback) und manchmal, weil die „richtige Antwort“ davon abhängt, was die Anwendung mit dieser Antwort macht. (Dieses Problem wird oftmals durch Bildschirmkoordinaten ausgelöst)

Die meisten Kompatibilitätsprobleme ergeben sich durch diese unzureichenden Bedingungen. Dinge, auf die Sie beim Testen achten sollten:

• Text ist geclippt (teilweise unsichtbar).

• Text ist zu groß.

• Etwas wird in der falschen Größe oder an der falschen Stelle gezeichnet.

Behelfsmaßnahmen

Weitere Informationen zur Entwicklung von Anwendungen, die „high dpi“ standardmäßig unterstützen, finden Sie unter https://msdn.microsoft.com/library/en-us/dngdi/html/highdpiapp.asp.

 

PNG-Symbole

Auswirkung der Funktion

Gering

Kurze Beschreibung

Das Symboldatei-Format (*.ico) unterstützt jetzt PNG-Dateien zusätzlich zu den älteren BMP-Symbolen. Viele Symbole in Windows Vista nutzen die PNG-Variante.

Erscheinungsform

Anwendungen, die Symboldateien betrachten oder bearbeiten, verstehen das neue Format möglicherweise nicht.

Links

https://blogs.msdn.com/nickkramer/archive/2006/04/24/582365.aspx

Diese Information ist ein Nachtrag zu https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AppComp.asp

 

Named Pipe-Härtung

Kurze Beschreibung

In Windows Vista laufen viele Dienste unter weniger privilegierten Accounts, wie etwa NetworkService (NS) oder LocalService (LS) anstatt Local System. „Service Hardening“ ist eine Initiative zur Verbesserung der Trennung zwischen den Diensten, so dass ein kompromittierter Dienst keine anderen Dienste des Systems beeinträchtigen kann. Windows Vista führt strengere Sicherheitsvorschriften für die von RPC-Servern verwendeten Schnittstellen ein, um zu verhindern, dass diese von anderen Prozessen in Beschlag genommen werden können.

Unter Windows XP erstellt ein RPC-Server eine benannte Schnittstelle und die ACL (Zugangskontrolllisten) auf der Schnittstelle gewähren LocalService oder NetworkService „Full Control“. Dies beinhaltet die Fähigkeit, „Server-Instanzen“ der Schnittstelle zu erstellen, um die Verbindung mit Clients zu ermöglichen. Der einzige Prozess, der Instanzen einer Schnittstelle erstellen können sollte, ist der Prozess, der die Schnittstelle ursprünglich erstellt hat. Microsofts geänderte ACL beschränkt die Fähigkeit der Erstellung von Server-Instanzen auf den Prozess, der die Schnittstelle ursprünglich erstellt hat.

Erscheinungsform

Die folgenden Dienste wurden betroffen: Dienste, die als „LocalService“ oder „NetworkService“ laufen, Dienste, die sich für die Nutzung von Sids entscheiden sowie Dienste, die RPC über benannte Schnittstellen, die den Standardsicherheitsnamen der benannten Schnittstelle fordern, nutzen.

Wenn Dienste Service-Sids benutzen, wird kein externer Dienst durch die Standardeinstellung betroffen. „Service-Sids“ ist eine neue Funktion unter Windows Vista, die Sie durch Einsetzen eines DWORD in die Konfiguration Ihres Dienstes nutzen können. Entwickler, die sich hierzu entscheiden, haben die Möglichkeit, die Tests mit den neuen strengeren Sicherheitsvorschriften durchzuführen. Diese Änderung wäre eine dieser Verhaltensweisen.

Wenn Dienste die RPC über benannte Schnittstellen, die den Standardsicherheitsnamen der benannten Schnittstelle fordern, nutzen, sehen sie keine Änderung, wenn ein RPC-Server einen benutzerdefinierten Sicherheitsnamen aufgrund spezieller Anforderungen angibt. Nachfolgend finden Sie eine Liste der betroffenen Schnittstellen:

• Epmapper

• Eventlog

• Dav rpc

• Keysvc

• Winreg

• Tapserv

• W32time_alt

• Termsvcapi

• Ctx_winsta

• Hydralspipe

 

SPAP Deprecation (Pstore)

Kurze Beschreibung

Protected Storage (PStore), das Anwendungen eine Schnittstelle zur Speicherung von sicher oder frei von Modifikationen aufzubewahrenden Benutzerdaten bietet, kann in Windows Vista nicht mehr verändert werden. Das bedeutet, dass Anwendungen keine neuen PStore-Datenobjekte mehr erstellen können.

Behelfsmaßnahmen

Verwenden Sie die DP-API für zukünftige PStore-Verfahren.

Weitere Informationen über bestehende PStore-Objekte und die Nutzung der DP-API zu deren Verwaltung finden Sie unter https://msdn.microsoft.com/library/en-us/dnsecure/html/windataprotection-dpapi.asp?frame=true

 

WMI-Anbieter: Standardsicherheits-Hosting-Modell

Kurze Beschreibung

Das Default HostingModel für WMI-Provider hat sich von LocalSystem in NetworkServiceHost geändert.

Wenn in früheren Windows-Versionen (Pre-Windows Vista Beta 2) das HostingModel eines WMI-Providers (__Win32Provider.HostingModel property) nicht spezifiziert war, wurde es standardmäßig auf LocalSystem eingestellt. Da LocalSystem ein Account mit hoher Berechtigungsstufe ist, setzt der in diesem Zusammenhang laufende WMI-Provider das Betriebssystem dem Risiko einer Anhebung der Berechtigungsstufe je nach Qualität und Prüfung des Provider-Codes aus.

In den meisten Fällen ist LocalSystem nicht erforderlich und der NetworkServiceHost-Kontext ist eher geeignet. Dies gilt insbesondere, da die meisten WMI-Provider die Identität (Identitätswechselstufe = 1) in Verbindung mit der Client-Sicherheit vornehmen müssen, so dass die geforderten Operationen im Auftrag des WMI-Clients durchgeführt werden können.

Erscheinungsform

Wenn ein WMI-Provider nicht über eine Definition für ein Hosting-Modell verfügt und wie auf der LocalSystem-Ebene ausgeführt wird, funktioniert er nicht ordnungsgemäß.

Behelfsmaßnahmen

Das erwartete Hosting-Modell muss geändert werden, um sicherzustellen, dass der Code des WMI-Providers die Operationen im Client-Sicherheitskontext durch Identitätswechsel des WMI-Clients ausführt. Fälle, in denen der LocalSystem-Sicherheitskontext benötigt wird, sind extrem selten. Wenn LocalSystem jedoch unbedingt erforderlich ist, geben Sie das Hosting-Modell ausdrücklich mit der HostingModel=LocalSystemHost-Anweisung in der MOF-Datei des Providers an.

Links

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/provider_hosting_and_security.asp

 

Volumenschattenkopie-Dienst

Kurze Beschreibung

Der Volume Shadow Copy Service (VSS) ist ein neuer Dienst, der in Windows XP und Windows Server 2003 eingeführt wurde. Hierbei handelt es sich um ein Rahmenwerk, das die Kommunikation zwischen Anwendungen, Speicher-Untersystemen und Speicherverwaltungsanwendungen (einschließlich Backup-Anwendungen) ermöglicht. Dieser Dienst definiert, erhält und nutzt Point-in-Time-Kopien der Speicherdaten.

Erscheinungsform

Kompatibilität mit Backup-Anwendungen unter XP.

Verschiedene Schnittstellen haben sich seit XP geändert und die Bibliotheken sind nicht mit Windows Vista kompatibel. Die Anwendung muss mindestens entweder mithilfe von Headern oder Bibliotheken aus VSS SDK 7.2 oder dem mit Windows Vista Beta 2 veröffentlichten Plattform-SDK rekompiliert werden.

Kompatibilität mit „2K3 SP 1“ (2003 – Servicepack 1) Backup-Anwendungen.

Die Binärdateien aus dem Servicepack 1 2003 sind mit Windows Vista kompatibel. Die meisten Backup-Anwendungen würden darüber hinaus einen Account für die Änderung in den Inbox-Schreibern, der Datei- und Verzeichnis-Virtualisierung, WRP und die Nutzung von festen Links in %windir%system32 benötigen, so dass die Wahrscheinlichkeit, dass eine Backup-Anwendung aus WS 2K3 SP1 in unveränderter Form funktioniert, gering ist.

Kompilieren von Backup-Anwendungen für Windows Vista

Anwendungen, die in Server 2003 verfügbare Schnittstellen verwenden, können mithilfe der in VSS SDK 7.2 bereitgestellten Header und Bibliotheken kompiliert werden. Um die neuen spezifischen Schnittstellen in Windows Vista zu nutzen, rekompilieren Sie unter Verwendung der VSS-Header und -Bibliotheken des Plattform-SDK für Windows Vista. Der erste SDK mit VSS-Komponenten steht mit der Beta 2 zur Verfügung.

VSS-Schreiber in Windows Vista

Registry-Schreiber

Der „Registry Writer“ führt jetzt vor Ort Backups und Wiederherstellungen des Verzeichnisses durch und steht damit im Gegensatz zu dem vorherigen verteilten Schreiberschema. Benutzer-Hives werden vom Registry Writer nicht gemeldet.

COM+ RegDB Writer

Fertigt Sicherungskopien des Inhalts der %systemroot%\registration an. COM+ hängt von dem gesicherten Verzeichnisschlüssel ab und muss daher mit dem Verzeichnis gesichert und wiederhergestellt werden.

MS Search Writer

Diese Funktion löscht den Suchindex nach der Erstellung aus den Schattenkopien.

MSDE Writer

Dies ist der Standardschreiber für SQL 2000- und SQL 2005-Datenbanken.

WMI Writer

Der WMI VSS-Schreiber wird für die Erstellung von Sicherungskopien WMI-spezifischer Zustände und Daten während der Backup-Operationen verwendet. Diese Daten beinhalten Dateien aus dem WBEM-Repository und erfordern ein Registry-Backup.

Background Intelligent Transfer Service (BITS) Writer

Dieser Schreiber verwendet den FilesNotToBackup-Verzeichnisschlüssel, um Dateien aus dem Verzeichnis %allusersprofile%\application\data\microsoft\network\downloader auszuschließen.

Automated System Recovery (ASR) Writer

Der ASR-Schreiber speichert die Konfiguration der Laufwerke des Systems.

System Writer

Der Systemschreiber in Windows Vista generiert eine Liste der Dateien mithilfe der folgenden Formel:

1. Alle installierten statischen Dateien. Diese werden durch das Attribut writeabletype = „static“ oder writeabletype ist „“ im Komponenten-Manifest identifiziert. Hierzu zählen alle WRP-Dateien. Darüber hinaus können einige als statisch gekennzeichnete Dateien vorhanden sein, die keine WRP-Dateien sind. Spiele sind beispielsweise statisch, aber keine WRP-Dateien, so dass Administratoren die Altersfreigabe ändern können.

2. Der WinSxS-Ordner, der alle Manifeste, optionalen Komponenten und Win32-Dateien von Drittanbietern enthält.

3. Alle PNP-Dateien für installierte Treiber (PNP-Eigentum).

4. Alle „User Mode“-Dienste und Nicht-PNP-Treiber.

5. Alle Kataloge von CryptSvc.

Die Dateien in %windir%\system32 sind unveränderliche Links zum winsxs-Verzeichnis.

Die Wiederherstellungsanwendung ist für die Ablage der Dateien und das Verzeichnis sowie die Einstellung der ACLs entsprechend der Systemabbildung verantwortlich. Die entsprechenden unveränderlichen Links müssen ebenfalls erstellt werden.

Microsoft Optimization Writer

Dieser Schreiber löscht bestimmte Dateien aus den Abbildungen. Die Dateilöschungen minimieren „Copy On Write (COW) I/O“ während der Abbildungswartungsphase, und die Dateien sind typischerweise temporäre Dateien oder Dateien, die keinen Benutzer- oder Systemstatus darstellen.

Links

http://search.msdn.microsoft.com/search/default.aspx?siteId=0&tab=0&query=Volume+Shadow+Copy+Service

http://search.msdn.microsoft.com/search/default.aspx?__VIEWSTATE=&query=Volume+Shadow+Copy+Service+Vista&siteid=0&tab=0

 

Standard-Benutzeranalyzer

Der „Standard User Analyzer“ (vormals bekannt als „LUA Analyzer“) ist ein Tool, das unabhängigen Software-Entwicklern (ISVs), IT-Experten und Benutzern hilft, mögliche Probleme in einer Anwendung zu diagnostizieren, wenn diese als Standardbenutzer ausgeführt wird. Der „Standard User Analyzer“ basiert auf der „LUA Predictor“-Technologie, die Teil des „Microsoft Application Verifier“ ist.

Installationsvoraussetzungen und Kompatibilität.

Betriebssysteme: Windows Vista, Windows XP und Windows Server 2003.

Hinweis:   Derzeit ist nur eine 32-bit-Version des „Standard User Analyzer“ verfügbar.

Installationsvoraussetzungen: Der „Application Verifier“ muss installiert werden, bevor die Installation des „Standard User Analyzer“ gestartet werden kann. Der „Application Verifier“ kann kostenlos von der Microsoft-Website heruntergeladen werden.

Installation

Um den „Standard User Analyzer“ zu starten, führen Sie die Datei „SUAnalyzer.msi file“ aus. Alle „Standard User Analyzer“-Dateien werden in den Ordner „Program Files\Standard User Analyzer“ kopiert.

Hinweis:   Für den „Standard User Analyzer“ müssen Sie die neueste Version des „Application Verifier“ installieren.

Nutzen Sie den „Standard User Analyzer“, um Standardbenutzer-Kompatibilitätsprobleme innerhalb einer Anwendung zu diagnostizieren.

Hinweis:   Der „Standard User Analyzer“ sollte auf einem Windows Vista-Computer ausgeführt werden, um Standardbenutzer-Kompatibilitätsprobleme richtig zu erkennen. Die folgende Prozedur wird geschrieben, um von einem Standardbenutzer auf einem Windows Vista-Computer ausgeführt zu werden.

1. Klicken Sie auf „Start“, weisen Sie auf „All Programs“ hin und klicken Sie dann doppelt auf „Standard User Analyzer“.

2. Geben Sie im Reiter „App Info“ im Feld „Target Application“ den Verzeichnisort für die ausführbare Datei der Anwendung an oder verwenden Sie die „Durchsuchen“-Funktion.

3. Geben Sie im Reiter „App Info“ im „Parameters“-Feld die Parameter für die Anwendung an, sofern zutreffend.

4. Markieren Sie im Reiter „App Info“ die „Launch Elevated“-Checkbox und klicken Sie dann auf den „Launch“-Button.

5. Wenn eine „User Account Control“-Nachweisaufforderung für die SUAnalyzerSrv.exe angezeigt wird, geben Sie die Administratordaten ein und klicken Sie auf „Submit“ (Senden).

6. Geben Sie in der „User Account Control“-Eingabeaufforderung für die Zielanwendung ihre Administratordaten ein und klicken Sie auf „Submit“ (Senden).

Hinweis:   Der „SUAnalyzerSrv.exe“-Prozess benötigt für die Ausführung dieser Prozedur eventuell eine höhere Berechtigung. Dieser Prozess ist ein Backend-Prozess, der für die Verwaltung von Aufgaben, für die ein Administrator-Token benötigt wird, wie etwa die Änderung von Einstellungen im „Application Verifier“, verantwortlich ist.

Während des Tests startet der „Standard User Analyzer“ die Anwendung, überwacht deren Aktionen und wartet darauf, dass die Anwendung geschlossen wird. Der „Standard User Analyzer“ generiert und analysiert eine Logfile für die Anwendung. Dieser Vorgang kann einige Zeit in Anspruch nehmen. Sobald die Logfile erstellt und analysiert wurde, klicken Sie auf die einzelnen Reiter, um von dem „Standard User Analyzer“ erkannte Probleme zu betrachten.

Interpretieren Sie die Testdaten des „Standard User Analyzer“.

Reiter	Details
File (Datei)	Listet Dateisystem-Zugangsprobleme auf. Beispielsweise eine Anwendung, die versucht, in eine Datei zu schreiben, auf die normalerweise nur Administratoren zugreifen können.
Registry (Verzeichnis)	Listet Probleme bei Zugriffen auf das Systemverzeichnis auf. Zum Beispiel eine Anwendung, die versucht, in einen Verzeichnisschlüssel unter HKLM zu schreiben – einem Ort, auf den normalerweise nur Administratoren zugreifen können.
INI	Listet Probleme der „WriteProfile“-APIs auf. „WriteProfile“-APIs wurden ursprünglich für 16-bit-Windows verwendet, sind aber immer noch für einige moderne Anwendungen beliebt. Beispielsweise der Taschenrechner in Windows XP. Wenn die Ansicht von „Standard“ auf „Scientific“ geändert wird, ruft die „calc.exe“-Datei die „WriteProfile“-API auf, um in die „windows\win.ini“-Datei zu schreiben. Dies ist nur Administratoren erlaubt.
Token	Listet Probleme bei der Prüfung von Zugangs-Token auf. Wenn eine Anwendung ausdrücklich nach der „Builtin\Administrators“-Sicherheits-ID in dem Zugangs-Token eines Benutzers fragt, funktioniert die Anwendung höchstwahrscheinlich nicht bei einem Standardbenutzer.
Privilege (Berechtigung)	Listet Berechtigungsprobleme auf. Wenn eine Anwendung beispielsweise ausdrücklich „SeDebugPrivilege“ zulässt, funktioniert diese nicht bei einem Standardbenutzer.
Name Space	Listet die Probleme auf, die entstehen, wenn eine Anwendung Systemobjekte in eingeschränkten Namespaces erstellt (z.B. Events, Memory Mappings etc.). Anwendungen mit diesem Fehler funktionieren nicht bei einem Standardbenutzer.
Other Objects (Sonstige Objekte)	Listet Probleme in Verbindung mit dem Zugriff auf andere Objekte als Dateien und Verzeichnisschlüssel auf.

Wenn Sie auf ein Problem in irgendeinem Reiter klicken, werden in der unteren linken Leiste des „Standard User Analyzer“ alle damit verbundenen Protokolle aus der Logdatei angezeigt. Wenn Sie dann auf eines der Protokolle klicken, werden dessen ausführliche Informationen einschließlich einer formatierten Meldung sowie der Parameter und der Stapelüberwachung angezeigt. ISVs können Stapelüberwachungsdaten nutzen, um den Ursprung eines Problems im Quellcode der Anwendung zu finden.

„Standard User Analyzer“-Hauptmenü

Dateimenü

„Open Log File“: Öffnet eine gespeicherte Logdatei.

„Export Log File“: Speichert die aktuelle Logdatei.

„View Raw Log File“ (Raw-Logdatei anzeigen) Öffnet die aktuelle Logdatei im „raw xml“-Format. (Warnung: Bei großen Dateien kann der Ladevorgang einige Zeit in Anspruch nehmen.)

„Exit“ (Verlassen): Beendet das Programm.

„View menu“ (Anzeigemenü):

Wählen Sie aus, welche Arten von Meldungen Sie anzeigen wollen. Im Allgemeinen sind nur Fehlermeldungen erforderlich.

„Options Menu“ (Optionsmenü):

„Filter Noise“ (Wertlose Daten filtern): Aktiviert/deaktiviert die Anzeige wertloser Daten.

„Load Noise Filter File“ (Datenfilterdatei laden): Lädt eine Datenfilterdatei.

„Export Noise Filter File“ (Datenfilterdatei exportieren): Speichert eine Datenfilterdatei.

„Only Display Records with Application Name in StackTrace“ (Nur Protokolle mit Anwendungsnamen in der Stapelüberwachung anzeigen): Hierdurch werden wertlose Daten reduziert. Da der „Standard User Analyzer“ jedoch nur die ersten 32 Stapel-Frames erfasst, können durch die Aktivierung dieser Option echte Probleme herausgefiltert werden, wenn eine Call-Überwachung über mehr als 32 Frames verfügt.

Logging: Logging-Optionen Es wird empfohlen, die „Log Information“-Checkbox markiert zu lassen, um zu verhindern, dass die Logdatei zu groß wird.

 

Hilfemodul-Support

Microsoft ist bestrebt, Hilfe- und Support-Technologien auf der Windows-Plattform anzubieten und forscht auch weiterhin nach neuen Lösungen für Software-Entwickler. Dieses Dokument erklärt den Support in Windows Vista für vier Hilfe-Technologien von Microsoft: Windows Help, HTML Help 1.x, das Hilfe- und Support-Center und der „Assistance Platform“-Client.

Windows Help (WinHelp.exe & WinHlp32.exe)

Windows Help (WinHelp.exe & WinHlp32.exe) ist die original Hilfe-Engine, die seit Windows 3.1 integriert wurde. Windows Help ist erforderlich, um Hilfedateien mit der .HLP-Dateierweiterung anzuzeigen.

Windows Help wird für Windows Vista abgelehnt. Windows Help wird in der Beta 2 nicht unterstützt und ein Teil des Windows Help-Codes wurde für die Veröffentlichung entfernt. Um Hilfedateien mit der .HLP-Dateierweiterung in Windows Vista anzuzeigen, müssen Sie die Datei „WinHlp32.exe“ im Microsoft Download Center herunterladen und installieren. Dieser Download steht für die Beta 2 nicht zur Verfügung.

Microsoft empfiehlt Software-Entwicklern dringend, die „Windows Help“-Anwendung in Vista nicht mehr zu benutzen. Software-Entwickler, die Programme anbieten, die die .HLP-Dateien nutzen, werden ermutigt, ein alternatives Hilfedatei-Format wie etwa CHM, HTML oder XML zu verwenden. Darüber hinaus müssen Sie Ihre Aufrufe von der WinHelp()-API auf die neue Inhaltsquelle umändern. Verschiedene Drittanbieter-Tools unterstützen Autoren bei der Konvertierung der Inhalte in ein anderes Format.

HTML Help 1.x (HH.exe)

Microsoft HTML Help 1.x (HH.exe) ist ein seit Windows 98 in Windows-Versionen enthaltenes Hilfesystem. „HTML Help“ wird benötigt, um kompilierte Hilfedateien mit der .CHM-Dateierweiterung anzuzeigen.

„HTML Help“ wird in Windows Vista enthalten sein. Es werden jedoch nur wirklich wichtige Updates der Engine vorgenommen. Der HTML Help-Engine werden für Windows Vista oder spätere Windows-Versionen keine neuen Funktionen oder Funktionsverbesserungen hinzugefügt.

Weitere Informationen zu der HTML-Hilfe und eine Anleitung zur Erstellung von Dateien für die HTML-Hilfe finden Sie im „Help 1.4 SDK“ (https://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/vsconhh1start.asp).

Hilfe- und Support-Center (HelpCtr.exe)

Das Hilfe- und Support-Center (HelpCtr.exe) war eine für Windows XP und Windows Server 2003 entwickelte Hilfeanwendung. Das Hilfe- und Support-Center zeigte kompilierte Hilfedateien mit der .CHM-Dateierweiterung an.

Das Hilfe- und Support-Center ist nicht in Windows Vista enthalten und dessen Funktionen werden nicht unterstützt. Kompilierte Hilfedateien mit der .CHM-Dateierweiterung werden nur in der „HTML-Hilfe“ wie oben beschrieben angezeigt.

„Assistance Platform“-Client (HelpPane.exe)

Der „Assistance Platform“-Client (HelpPane.exe) ist eine neue Hilfe-Engine, die für Windows Vista entwickelt wurde. Diese Engine ist nicht mit früheren Windows-Versionen kompatibel. Der „Assistance Platform“-Client wird benötigt, um Hilfedateien mit der .H1S-Dateierweiterung anzuzeigen.

In Windows Vista kann der „Assistance Platform“-Client von OEMs, Systemherstellern und Unternehmenskunden im Rahmen einer Lizenzvereinbarung angepasst werden. Eine Nutzung durch Drittanbieter-Programme ist nicht möglich. Weitere Informationen zur Anpassung des „Assistance Platform“-Clients finden Sie im Windows SDK.

 

Siehe auch

Interoperabilität & Migration