Freigeben über


Archiv: Zertifizierungsanforderungen für Windows Desktop Apps v3.0

Dokumentversion: 3.0

Dokumentdatum: 29. Juni 2012

Dieses Dokument enthält die technischen Anforderungen und Voraussetzungen, die eine Desktop-App erfüllen muss, um am Zertifizierungsprogramm für Windows 8 Desktop-App teilzunehmen. Für Windows 7 wurde dieses Programm als Windows-Softwarelogo-Programm bezeichnet.

Willkommen!

Die Windows-Plattform unterstützt ein breites Ökosystem von Produkten und Partnern. Das Anzeigen des Windows-Logos auf Ihrem Produkt stellt eine Beziehung und eine gemeinsame Verpflichtung zur Qualität zwischen Microsoft und Ihrem Unternehmen dar. Kunden vertrauen der Windows-Marke auf Ihrem Produkt, weil sie sicherstellt, dass es Kompatibilitätsstandards erfüllt und auf der Windows-Plattform gut funktioniert. Das erfolgreiche Bestehen der Windows-App-Zertifizierung ermöglicht es, Ihre App im Windows Compatibility Center zu präsentieren, und es ist auch ein notwendiger Schritt, um eine Desktop-App-Referenz im Windows Store aufzulisten.

Das Zertifizierungsprogramm für Windows-Apps besteht aus programmbezogenen und technischen Anforderungen, um sicherzustellen, dass Apps von Drittanbietern, die die Windows-Marke tragen, sowohl einfach zu installieren als auch zuverlässig auf PCs mit Windows sind. Kunden schätzen Stabilität, Kompatibilität, Zuverlässigkeit, Leistung und Qualität in den von ihnen erworbenen Systemen. Microsoft konzentriert sich auf seine Investitionen, um diese Anforderungen für Software-Apps zu erfüllen, die für die Ausführung auf der Windows-Plattform für PCs entwickelt wurden. Diese Bemühungen umfassen Kompatibilitätstests für Konsistenz, verbesserte Leistung und erhöhte Sicherheit auf PCs, auf denen Windows-Software ausgeführt wird. Microsoft-Kompatibilitätstests wurden in Zusammenarbeit mit Branchenpartnern entwickelt und werden kontinuierlich verbessert, um den Branchenentwicklungen und der Nachfrage der Verbraucher gerecht zu werden.

Das Zertifizierungskit für Windows-Apps wird verwendet, um die Konformität mit diesen Anforderungen zu überprüfen, und ersetzt die WSLK, die für die Validierung im Windows 7-Softwarelogoprogramm verwendet wird. Das Zertifizierungskit für Windows-Apps ist eine der Komponenten, die im Windows Software Development Kit (SDK) für Windows 8 enthalten sind. Es ist auch in Microsoft Visual Studio 2012 Express für Windows 8 integriert.

App-Berechtigung

Damit sich eine App für Windows 8 Desktop-App-Zertifizierung qualifizieren kann, muss sie die folgenden Kriterien und alle in diesem Dokument aufgeführten technischen Anforderungen erfüllen.

  • Es muss sich um eine eigenständige App
  • Sie muss auf einem lokalen Windows 8.1 Computer ausgeführt werden.
  • Dies kann eine Clientkomponente einer zertifizierten Windows Server-App sein.
  • Es muss code- und featurevollständig sein.

1. Apps sind kompatibel und resilient

Die Zeiten, in denen eine App abstürzt oder nicht mehr reagiert, führen zu einer erheblichen Frustration der Benutzer. Es wird erwartet, dass Apps resilient und stabil sind, und die Beseitigung solcher Fehler trägt dazu bei, dass Software besser vorhersagbar, verwaltbar, leistungsfähig und vertrauenswürdiger ist.

1.1 Ihre App darf keine Abhängigkeit von Windows-Kompatibilitätsmodi, AppHelp-Nachrichten und anderen Kompatibilitätskorrekturen aufweisen.
1.2 Ihre App darf keine Abhängigkeit von der VB6-Runtime annehmen.
1.3 Ihre App darf keine beliebigen DLLs laden, um Win32-API-Aufrufe mithilfe von HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls abzufangen.

2. Apps müssen den bewährten Windows-Sicherheitsmethoden entsprechen

Die Verwendung bewährter Windows-Sicherheitsmethoden trägt dazu bei, die Gefährdung von Windows-Angriffsflächen zu vermeiden. Angriffsflächen sind die Einstiegspunkte, die ein böswilliger Angreifer nutzen kann, um das Betriebssystem auszunutzen, indem er Sicherheitsrisiken in der Zielsoftware ausnutzt. Eines der größten Sicherheitsrisiken ist die Rechteerweiterung.

2.1 Ihre App muss starke und geeignete ACLs verwenden, um ausführbare Dateien zu schützen 2.2 Ihre App muss starke und geeignete ACLs verwenden, um Verzeichnisse zu schützen 2.3 Ihre App muss starke und geeignete ACLs verwenden, um Registrierungsschlüssel zu schützen 2.4 Ihre App muss starke und geeignete ACLs verwenden, um Verzeichnisse zu sichern, die Objekte enthalten 2.5 Ihre App muss den Zugriff von Nichtadministratoren auf Dienste reduzieren, die anfällig für Manipulationen sind 2.6 Ihre App muss Dienste mit schnellem Zugriff verhindern. neustartt mehr als zweimal alle 24 Stunden
**Hinweis: Der Zugriff sollte nur für die Entitäten gewährt werden, die ihn benötigen.**

Das Zertifizierungsprogramm für Windows-Apps überprüft, ob Windows-Angriffsflächen nicht verfügbar gemacht werden, indem überprüft wird, ob ACLs und Dienste auf eine Weise implementiert sind, die das Windows-System nicht gefährdet.

3. Apps unterstützen Windows-Sicherheitsfeatures

Das Windows-Betriebssystem verfügt über viele Features, die Systemsicherheit und Datenschutz unterstützen. Apps müssen diese Features unterstützen, um die Integrität des Betriebssystems aufrechtzuerhalten. Nicht ordnungsgemäß kompilierte Apps können Pufferüberläufe verursachen, die wiederum zu Denial-of-Service führen oder schädlichen Code ausführen lassen können.

3.1 Ihre App darf AllowPartiallyTrustedCallersAttribute (APTCA) nicht verwenden, um den sicheren Zugriff auf Assemblys mit starkem Namen sicherzustellen.
3.2 Ihre App muss mit dem /SafeSEH-Flag kompiliert werden, um eine sichere Ausnahmebehandlung sicherzustellen.
3.3 Ihre App muss mit dem Flag /NXCOMPAT kompiliert werden, um die Datenausführung zu verhindern.
3.4 Ihre App muss mithilfe des Flags /DYNAMICBASE für die Zufällige Layout randomisierung des Adressraums (ASLR) kompiliert werden.
3.5 Ihre App darf die freigegebenen PE-Abschnitte nicht lesen/schreiben.

4. Apps müssen den Meldungen des Systemneustart-Managers entsprechen.

Wenn Benutzer das Herunterfahren initiieren, haben sie in der Regel den starken Wunsch, dass das Herunterfahren erfolgreich ist. Sie können es eilig haben, das Büro zu verlassen, und möchten nur, dass ihre Computer ausgeschaltet werden. Apps müssen diesen Wunsch respektieren, indem sie das Herunterfahren nicht blockieren. Während in den meisten Fällen ein Herunterfahren nicht kritisch ist, müssen Apps auf die Möglichkeit eines kritischen Herunterfahrens vorbereitet sein.

4.1 Ihre App muss kritische Herunterfahren ordnungsgemäß verarbeiten
Beim kritischen Herunterfahren werden Apps, die FALSE an WM_QUERYENDSESSION zurückgeben, WM_ENDSESSION gesendet und geschlossen, während apps, die als Reaktion auf WM_QUERYENDSESSION ein Timeout ausführen, beendet werden.

4.2 Eine GUI-App muss sofort TRUE zurückgeben, um einen Neustart vorzubereiten.
WM\_QUERYENDSESSION mit LPARAM = ENDSESSION\_CLOSEAPP(0x1). Konsolen-Apps können SetConsoleCtrlHandler aufrufen, um die Funktion anzugeben, die Benachrichtigungen zum Herunterfahren verarbeitet. Dienst-Apps können RegisterServiceCtrlHandlerEx aufrufen, um die Funktion anzugeben, die Benachrichtigungen zum Herunterfahren empfängt.
4.3 Ihre App muss innerhalb von 30 Sekunden 0 zurückgeben und heruntergefahren werden.
WM\_ENDSESSION mit LPARAM = ENDSESSION\_CLOSEAPP(0x1). Die App sollte mindestens vorbereiten, indem sie alle Benutzerdaten speichert und die informationen angeben, die nach einem Neustart benötigt werden.
4.4 Konsolen-Apps, die die Benachrichtigung STRG\_C\_EVENT erhalten, sollten sofort heruntergefahren werden 4.5 Treiber dürfen kein Veto gegen ein Ereignis zum Herunterfahren des Systems
**Hinweis: Apps, die das Herunterfahren aufgrund eines Vorgangs blockieren müssen, der nicht unterbrochen werden kann, sollten dem Benutzer den Grund erklären.** Verwenden Sie ShutdownBlockReasonCreate, um eine Zeichenfolge zu registrieren, die dem Benutzer den Grund erklärt. Wenn der Vorgang abgeschlossen ist, sollte die App ShutdownBlockReasonDestroy aufrufen, um anzugeben, dass das System heruntergefahren werden kann.

5. Apps müssen eine sauber, umkehrbare Installation unterstützen.

Eine sauber, umkehrbare Installation ermöglicht es Benutzern, Apps auf ihren Systemen erfolgreich zu verwalten (bereitstellen und entfernen).

5.1 Ihre App muss eine sauber, umkehrbare Installation ordnungsgemäß implementieren.
Wenn die Installation fehlschlägt, sollte die App in der Lage sein, ein Rollback durchzuführen und den vorherigen Zustand des Computers wiederherzustellen.

5.2 Ihre App darf den Benutzer niemals zwingen, den Computer sofort neu zu starten.
Ein Neustart des Computers sollte nie die einzige Option am Ende einer Installation oder eines Updates sein. Benutzer sollten die Möglichkeit haben, später neu zu starten.
5.3 Ihre App darf niemals von 8.3 kurzen Dateinamen (SFN) abhängig sein 5.4 Ihre App darf die automatische Installation/Deinstallation nie blockieren 5.5 Ihr App-Installationsprogramm muss die richtigen Registrierungseinträge erstellen, um eine erfolgreiche Erkennung und Deinstallation zu ermöglichen.
Windows-Inventurtools und Telemetrietools erfordern vollständige Informationen zu installierten Apps. Wenn Sie ein MSI-basiertes Installationsprogramm verwenden, erstellt MSI automatisch die folgenden Registrierungseinträge. Wenn Sie kein MSI-Installationsprogramm verwenden, muss das Installationsmodul während der Installation die folgenden Registrierungseinträge erstellen:
  • DisplayName
  • InstallLocation
  • Publisher
  • UninstallString
  • VersionMajor oder MajorVersion
  • VersionMinor oder MinorVersion

6. Apps müssen Dateien und Treiber digital signieren

Mit einer digitalen Authenticode-Signatur können Benutzer sicher sein, dass die Software original ist. Es ermöglicht auch zu erkennen, ob eine Datei manipuliert wurde, z. B. ob sie von einem Virus infiziert wurde. Die Erzwingung der Codesignatur im Kernelmodus ist ein Windows-Feature, das als Codeintegrität (CI) bezeichnet wird und die Sicherheit des Betriebssystems verbessert, indem die Integrität einer Datei bei jedem Laden des Images der Datei in den Arbeitsspeicher überprüft wird. CI erkennt, ob böswilliger Code eine Systembinärdatei geändert hat. Generiert außerdem ein Diagnose- und Systemüberwachungsprotokollereignis, wenn die Signatur eines Kernelmoduls nicht ordnungsgemäß überprüft werden kann.

6.1 Alle ausführbaren Dateien (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) müssen mit einem Authenticode-Zertifikat signiert sein.
6.2 Alle von der App installierten Kernelmodustreiber müssen über eine Microsoft-Signatur verfügen, die über das Windows-Hardwarezertifizierungsprogramm abgerufen wurde. Alle Dateisystemfiltertreiber müssen von Microsoft signiert werden.
6.3 Ausnahmen und Verzichtserklärungen
Verzichtserklärungen werden nur für nicht signierte Verteiler von Drittanbietern berücksichtigt, mit Ausnahme von Treibern. Ein Kommunikationsnachweis, der eine signierte Version der Verteiler anfordert, ist erforderlich, damit dieser Verzicht gewährt wird.

7. Apps blockieren die Installation oder den App-Start nicht basierend auf einer Betriebssystemversionsprüfung.

Es ist wichtig, dass Kunden nicht künstlich daran gehindert werden, ihre App zu installieren oder auszuführen, wenn es keine technischen Einschränkungen gibt. Wenn Apps für Windows Vista oder höhere Versionen von Windows geschrieben wurden, sollten sie die Betriebssystemversion im Allgemeinen nicht überprüfen müssen.

7.1 Ihre App darf keine Versionsüberprüfungen auf Gleichheit durchführen.
Wenn Sie ein bestimmtes Feature benötigen, überprüfen Sie, ob das Feature selbst verfügbar ist. Wenn Sie Windows XP benötigen, suchen Sie nach Windows XP oder höher (>= 5.1). Auf diese Weise funktioniert Ihr Erkennungscode auch in zukünftigen Versionen von Windows. Treiberinstallationsprogramme und Deinstallationsmodule sollten niemals die Betriebssystemversion überprüfen.

7.2 Ausnahmen und Verzichtserklärungen werden für Apps berücksichtigt, die die folgenden Kriterien erfüllen:
  • Apps, die als ein Paket bereitgestellt werden, die auch unter Windows XP, Windows Vista und Windows 7 ausgeführt werden und die Betriebssystemversion überprüfen müssen, um zu ermitteln, welche Komponenten unter einem bestimmten Betriebssystem installiert werden sollen.
  • Apps, die nur die Mindestversion des Betriebssystems überprüfen (nur während der Installation, nicht zur Laufzeit), indem sie nur die genehmigten API-Aufrufe verwenden, und die die Mindestversionsanforderung ordnungsgemäß im App-Manifest auflisten.
  • Sicherheits-Apps (Antivirus, Firewall usw.), Systemprogramme (z. B. Defragmentierung, Sicherungen und Diagnose Tools), die die Betriebssystemversion überprüfen, indem nur die genehmigten API-Aufrufe verwendet werden.

8. Apps laden keine Dienste oder Treiber im abgesicherten Modus

Im abgesicherten Modus können Benutzer Windows diagnostizieren und Problembehandlungen durchführen. Treiber und Dienste dürfen nicht auf das Laden im abgesicherten Modus festgelegt werden, es sei denn, sie werden für grundlegende Systemvorgänge wie Speichergerätetreiber oder für Diagnose- und Wiederherstellungszwecke, z. B. Virenscanner, benötigt. Wenn Windows sich im abgesicherten Modus befindet, wird standardmäßig nur die Treiber und Dienste gestartet, die mit Windows vorinstalliert wurden.

  • 8.1 Ausnahmen und Verzichtserklärungen
    Treiber und Dienste, die im abgesicherten Modus gestartet werden müssen, erfordern einen Verzicht. Die Verzichtsanforderung muss jeden anwendbaren Treiber oder Dienst enthalten, der in die SafeBoot-Registrierungsschlüssel schreibt, und die technischen Gründe beschreiben, warum die App oder der Dienst im abgesicherten Modus ausgeführt werden muss. Das App-Installationsprogramm muss alle diese Treiber und Dienste mit den folgenden Registrierungsschlüsseln registrieren:
    - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal – HKLM/System/CurrentControlSet/Control/SafeBoot/Network

Hinweis: Sie müssen diese Treiber und Dienste testen, um sicherzustellen, dass sie fehlerfrei im abgesicherten Modus funktionieren.

9. Apps müssen die Richtlinien für die Benutzerkontensteuerung befolgen

Einige Windows-Apps werden im Sicherheitskontext eines Administratorkontos ausgeführt, und Apps fordern häufig übermäßige Benutzerrechte und Windows-Rechte an. Durch die Steuerung des Zugriffs auf Ressourcen haben Benutzer die Kontrolle über ihre Systeme und schützen sie vor unerwünschten Änderungen. Eine unerwünschte Änderung kann böswillig sein, z. B. ein Rootkit, das die Kontrolle über den Computer übernimmt, oder das Ergebnis einer Aktion von Personen sein, die über eingeschränkte Berechtigungen verfügen. Die wichtigste Regel zum Steuern des Zugriffs auf Ressourcen besteht darin, den geringsten Zugriff auf den Standardbenutzerkontext bereitzustellen, der für einen Benutzer erforderlich ist, um seine erforderlichen Aufgaben auszuführen. Die Einhaltung der Richtlinien für die Benutzerkontensteuerung (User Account Control, UAC) stellt der App die erforderlichen Berechtigungen bereit, wenn sie von der App benötigt werden, ohne dass das System ständig Sicherheitsrisiken ausgesetzt ist. Die meisten Apps erfordern keine Administratorrechte zur Laufzeit und sollten als Standardbenutzer problemlos ausgeführt werden.

9.1 Ihre App muss über ein Manifest verfügen, das Ausführungsebenen definiert und dem Betriebssystem mitteilt, welche Berechtigungen die App zum Ausführen benötigt.
Die App-Manifestmarkierung gilt nur für EXEs, nicht für DLLs. Dies liegt daran, dass UAC dlLs während der Prozesserstellung nicht überprüft. Es ist auch erwähnenswert, dass UAC-Regeln nicht für Microsoft-Dienste gelten. Das Manifest kann eingebettet oder extern sein.
Um ein Manifest zu erstellen, erstellen Sie eine Datei mit dem Namen <app_name>.exe.manifest, und speichern Sie sie im selben Verzeichnis wie die EXE. Beachten Sie, dass jedes externe Manifest ignoriert wird, wenn die App über ein internes Manifest verfügt. Beispiel:
<requestedExecutionLevel level="asInvoker | höchsteVerfügbar | requireAdministrator"" uiAccess=""true|false"/>

9.2 Ihre App Standard Prozess muss als Standardbenutzer (asInvoker) ausgeführt werden.
Alle administrativen Features müssen in einen separaten Prozess verschoben werden, der mit Administratorrechten ausgeführt wird. Benutzerbezogene Apps, z. B. apps, auf die über die Programmgruppe im Startmenü zugegriffen werden kann und die die Erhöhung erfordern, müssen Authenticode signiert sein.
9.3 Ausnahmen und Verzichtserklärungen
Eine Verzichtserklärung ist für Apps erforderlich, die ihren Standard-Prozess mit erhöhten Rechten ausführen (requireAdministrator oder highestAvailable). Der Standard Prozess wird als Einstiegspunkt des Benutzers zur App identifiziert. Verzichtserklärungen werden für die folgenden Szenarien berücksichtigt:
  • Verwaltungs- oder Systemtools, deren Ausführungsebene auf "höchste Verfügbar" und/oder "requireAdministrator" festgelegt ist
  • Nur die Framework-App für Barrierefreiheit oder Benutzeroberflächenautomatisierung legt das uiAccess-Flag auf true fest, um die Benutzeroberflächenberechtigungsisolation (UIPI) zu umgehen. Um die App-Auslastung ordnungsgemäß zu starten, muss dieses Flag Authenticode signiert sein und muss sich an einem geschützten Speicherort im Dateisystem befinden, nämlich Programme.

10. Apps müssen standardmäßig in den richtigen Ordnern installiert werden.

Benutzer sollten über eine konsistente und sichere Erfahrung mit dem Standardinstallationsspeicherort von Dateien verfügen, während die Option beibehalten wird, eine App am Speicherort ihrer Wahl zu installieren. Es ist auch erforderlich, App-Daten am richtigen Speicherort zu speichern, damit mehrere Personen denselben Computer verwenden können, ohne die Daten und Einstellungen des anderen zu beschädigen oder zu überschreiben. Windows stellt bestimmte Speicherorte im Dateisystem bereit, um Programme und Softwarekomponenten, freigegebene App-Daten und benutzerspezifische App-Daten zu speichern.

10.1 Ihre App muss standardmäßig im Ordner Programme installiert sein.
Für native 32-Bit- und 64-Bit-Apps in %ProgramFiles% und %ProgramFiles(x86)% für 32-Bit-Apps, die unter x64 ausgeführt werden. Benutzerdaten oder App-Daten dürfen aufgrund der für diesen Ordner konfigurierten Sicherheitsberechtigungen nie an diesem Speicherort gespeichert werden.

10.2 Ihre App muss vermeiden, dass beim Start automatisch gestartet wird
Beispielsweise sollte Ihre App keine der folgenden Optionen festlegen:
  • Registrierungsausführungsschlüssel HKLM und oder HKCU unter Software\Microsoft\Windows\CurrentVersion
  • Registrierungsausführungsschlüssel HKLM und oder HKCU unter Software\Wow6432Node\Microsoft\windows\CurrentVersion
  • Startmenü AllProgrammstart >
10.3 Ihre App-Daten, die für Benutzer auf dem Computer freigegeben werden müssen, sollten in ProgramData 10.4 Ihre App-Daten gespeichert werden, die exklusiv für einen bestimmten Benutzer sind und nicht für andere Benutzer des Computers freigegeben werden sollen, müssen unter Benutzer\\<Benutzername>\\AppData 10.5 Gespeichert werden. Ihre App darf niemals direkt in das Verzeichnis "Windows" und oder die Unterverzeichnisse schreiben.
Verwenden Sie die richtigen Methoden zum Installieren von Dateien, z. B. Schriftarten oder Treiber.
10.6 Ihre App muss Benutzerdaten bei der ersten Ausführung und nicht während der Installation in Computerinstallationen schreiben.
Wenn die App installiert ist, gibt es keinen richtigen Benutzerspeicherort, an dem Daten gespeichert werden sollen. Versuche einer App, das Standardzuordnungsverhalten auf Computerebene nach der Installation zu ändern, sind nicht erfolgreich. Stattdessen müssen Standardwerte auf Benutzerebene beansprucht werden, was verhindert, dass mehrere Benutzer die Standardwerte des anderen überschreiben.
10.7 Ausnahmen und Verzichtserklärungen
Für Apps, die in den globalen Assemblycache (GAC) schreiben, ist eine Verzichtserklärung erforderlich.NET-Apps sollten Assemblyabhängigkeiten privat halten und im App-Verzeichnis speichern, es sei denn, die Freigabe einer Assembly ist explizit erforderlich.

11. Apps müssen Sitzungen mit mehreren Benutzern unterstützen

Windows-Benutzer sollten in der Lage sein, gleichzeitige Sitzungen ohne Konflikte oder Unterbrechungen auszuführen.

11.1 Ihre App muss sicherstellen, dass die normale Funktionalität der App bei der Ausführung in mehreren Sitzungen entweder lokal oder remote nicht beeinträchtigt wird.
11.2 Einstellungen und Datendateien Ihrer App dürfen nicht benutzerübergreifend beibehalten werden.
11.3 Datenschutz und Einstellungen eines Benutzers müssen für die Sitzung des Benutzers isoliert werden.
11.4 Ihre App-Instanzen müssen voneinander isoliert sein
Dies bedeutet, dass Benutzerdaten aus einer instance für einen anderen instance der App nicht sichtbar sind. Sound in einer inaktiven Benutzersitzung sollte in einer aktiven Benutzersitzung nicht gehört werden. In Fällen, in denen mehrere App-Instanzen freigegebene Ressourcen verwenden, muss die App sicherstellen, dass es keinen Konflikt gibt.

11.5 Apps, die für mehrere Benutzer installiert sind, müssen Daten in den richtigen Ordnern und Registrierungsspeicherorten speichern.
Weitere Informationen finden Sie unter UAC-Anforderungen.
11.6 Benutzer-Apps müssen in mehreren Benutzersitzungen ausgeführt werden können (Schnelle Benutzerumschaltung) für lokalen Zugriff und Remotezugriff 11.7 Ihre App muss andere Terminaldienstsitzungen (TS) auf vorhandene Instanzen der App überprüfen.
**Hinweis:** Wenn eine App mehrere Benutzersitzungen oder Remotezugriff nicht unterstützt, muss sie dies beim Starten von dieser Art von Sitzung eindeutig angeben.

12. Apps müssen x64-Versionen von Windows unterstützen.

Da 64-Bit-Hardware immer häufiger wird, erwarten Benutzer, dass App-Entwickler die Vorteile der 64-Bit-Architektur nutzen, indem sie ihre Apps zu 64-Bit migrieren, oder dass 32-Bit-Versionen der App unter 64-Bit-Versionen von Windows gut ausgeführt werden.

12.1 Ihre App muss nativ 64-Bit- oder mindestens 32-Bit-Windows-basierte Apps auf 64-Bit-Systemen unterstützen, um die Kompatibilität mit 64-Bit-Versionen von Windows zu gewährleisten.
12.2 Ihre App und ihre Installationsprogramme dürfen keinen 16-Bit-Code enthalten oder sich auf eine 16-Bit-Komponente verlassen.
12.3 Ihr App-Setup muss die richtigen Treiber und Komponenten für die 64-Bit-Architektur erkennen und installieren.
12.4 Alle Shell-Plug-Ins müssen unter 64-Bit-Versionen von Windows ausgeführt werden
12.5 App, die unter dem WoW64-Emulator ausgeführt wird, sollte nicht versuchen, Wow64-Virtualisierungsmechanismen zu unterlaufen oder zu umgehen.
Wenn es bestimmte Szenarien gibt, in denen Apps erkennen müssen, ob sie unter dem WoW64-Emulator ausgeführt werden, sollten sie dies tun, indem sie IsWow64Process aufrufen.

Zusammenfassung

Wenn sich diese Anforderungen weiterentwickeln, werden wir die Änderungen im Folgenden im Revisionsverlauf notieren. Stabile Anforderungen sind von entscheidender Bedeutung für Ihre beste Arbeit. Daher werden wir sicherstellen, dass die Von uns vorgenommenen Änderungen nachhaltig sind und Ihre Apps weiterhin schützen und verbessern.

Nochmals vielen Dank, dass Sie sich an unserem Engagement für eine hervorragende Kundenerfahrung beteiligt haben.

Revisionsverlauf

Date Version Revisionsbeschreibung Link zum Dokument
20. Dezember 2011 1.0 Anfänglicher Dokumententwurf für die Vorschauversion.
26. Januar 2012 1.1 Aktualisieren Sie auf Abschnitt 2. 1.1
31. Mai 2012 1.2 Zusammenfassungstestergebnisse hinzugefügt 1.2
29. Juni 2012 3.0 Windows 8 Abschlussdokument 3.0

Weitere Informationen zur Zertifizierung von Desktop-Apps

Anforderung BESCHREIBUNG Weitere Informationen
Kompatibilität und Resilienz & Abstürze sind eine große Störung für die Benutzer und verursachen Frustration. Es wird erwartet, dass Apps robust und stabil sind, sodass die Beseitigung solcher Fehler dazu beiträgt, dass Software vorhersagbarer, verwaltbarer, performanter und vertrauenswürdiger ist. Windows Vista, Windows 7 und Windows 8 Betriebssysteme
Application Verifier
AppInit-DLLs
Befolgen Windows-Sicherheit bewährter Methoden Die Verwendung bewährter Windows-Sicherheitsmethoden hilft, die Entstehung von Windows-Angriffsflächen zu vermeiden. Angriffsflächen sind die Einstiegspunkte, die ein böswilliger Angreifer verwenden könnte, um das Betriebssystem auszunutzen, indem er Sicherheitsrisiken in der Zielsoftware ausnutzt. Eines der schlimmsten Sicherheitsrisiken ist die Rechteerweiterung. Attack Surface Analyzer
Zugriffssteuerungslisten
Unterstützung Windows-Sicherheit Features Das Windows-Betriebssystem hat viele Maßnahmen zur Unterstützung der Systemsicherheit und des Datenschutzes implementiert. Anwendungen müssen diese Maßnahmen unterstützen, um die Integrität des Betriebssystems aufrechtzuerhalten. Nicht ordnungsgemäß kompilierte Anwendungen können Pufferüberläufe verursachen, die wiederum zu Denial-of-Service führen oder schädlichen Code ausführen können. Referenz zum BinScope-Tool
Befolgen von Systemneustart-Manager-Meldungen Wenn Benutzer das Herunterfahren initiieren, haben sie in den meisten Fällen den starken Wunsch, dass das Herunterfahren erfolgreich ist; Sie können es eilig haben, das Büro zu verlassen und "nur wollen", dass ihre Computer ausgeschaltet werden. Apps müssen diesen Wunsch respektieren, indem sie das Herunterfahren nicht blockieren. Während ein Herunterfahren in den meisten Fällen nicht kritisch ist, müssen Apps auf die Möglichkeit eines kritischen Herunterfahrens vorbereitet sein. Änderungen beim Herunterfahren der Anwendung in Windows Vista
Neustarten der Managerentwicklung
Bereinigen der umkehrbaren Installation Eine sauber, umkehrbare Installation ermöglicht es Benutzern, Apps auf ihren Systemen erfolgreich zu verwalten (bereitzustellen und zu entfernen). Gewusst wie: Installieren von erforderlichen Komponenten mit einer ClickOnce-Anwendung
Anwendungsinstallation auf 64-Bit-Systemen
Digitales Signieren von Dateien und Treibern Mit einer digitalen Authenticode-Signatur können Benutzer sicher sein, dass die Software original ist. Es ermöglicht auch zu erkennen, ob eine Datei manipuliert wurde, z. B. wenn sie von einem Virus infiziert wurde. Die Erzwingung von Codesignaturen im Kernelmodus ist ein Windows-Feature, das als Codeintegrität (CI) bezeichnet wird, das die Sicherheit des Betriebssystems verbessert, indem die Integrität einer Datei jedes Mal überprüft wird, wenn das Image der Datei in den Arbeitsspeicher geladen wird. CI erkennt, ob böswilliger Code eine System-Binärdatei geändert hat. Generiert außerdem ein Diagnose- und Systemüberwachungsprotokollereignis, wenn die Signatur eines Kernelmoduls nicht ordnungsgemäß überprüft werden kann. Digitale Signaturen für Kernelmodule unter Windows
Blockieren Sie die Installation oder den App-Start nicht basierend auf der Überprüfung der Betriebssystemversion Es ist wichtig, dass Kunden nicht künstlich daran gehindert werden, ihre App zu installieren oder auszuführen, wenn es keine technischen Einschränkungen gibt. Wenn Apps für Windows Vista oder höhere Versionen geschrieben wurden, sollten sie im Allgemeinen keinen Grund haben, die Betriebssystemversion zu überprüfen. Betriebssystemversionsverwaltung
Dienste und Treiber nicht im abgesicherten Modus laden Im abgesicherten Modus können Benutzer Windows diagnostizieren und Problembehandlungen durchführen. Sofern dies nicht für grundlegende Vorgänge des Systems (z. B. Speichergerätetreiber) oder für Diagnose- und Wiederherstellungszwecke (z. B. Virenscanner) erforderlich ist, dürfen Treiber und Dienste nicht auf das Laden im abgesicherten Modus festgelegt werden. Standardmäßig startet der abgesicherte Modus die meisten Treiber und Dienste nicht, die nicht mit Windows vorinstalliert waren. Sie sollten deaktiviert bleiben, es sei denn, das System benötigt sie für grundlegende Vorgänge oder für Diagnose- und Wiederherstellungszwecke. Bestimmen, ob das Betriebssystem im abgesicherten Modus ausgeführt wird
Befolgen der Richtlinien für die Benutzerkontensteuerung Einige Windows-Apps werden im Sicherheitskontext eines Administratorkontos ausgeführt, und viele erfordern übermäßige Benutzerrechte und Windows-Berechtigungen. Durch die Kontrolle des Zugriffs auf Ressourcen können Benutzer ihre Systeme gegen unerwünschte Änderungen kontrollieren (Eine unerwünschte Änderung kann böswillig sein, z. B. ein Rootkit, das den Computer heimlich übernimmt, oder eine Aktion von Personen, die über eingeschränkte Rechte verfügen, z. B. ein Mitarbeiter, der verbotene Software auf einem Arbeitscomputer installiert). Die wichtigste Regel zum Steuern des Zugriffs auf Ressourcen besteht darin, den geringsten Zugriff auf den Standardbenutzerkontext bereitzustellen, der für einen Benutzer erforderlich ist, um seine erforderlichen Aufgaben auszuführen. Die folgenden UAC-Richtlinien bieten der App bei Bedarf die erforderlichen Berechtigungen, ohne dass das System ständig Sicherheitsrisiken ausgesetzt ist. Benutzerkontensteuerung
UAC: Richtlinien für Anwendungsupdates
Standardmäßige Installation in den richtigen Ordnern Benutzer sollten über eine konsistente und sichere Erfahrung mit dem Standardinstallationsspeicherort von Dateien verfügen, während die Option beibehalten wird, eine App an dem von ihnen ausgewählten Speicherort zu installieren. Es ist auch erforderlich, App-Daten am richtigen Speicherort zu speichern, damit mehrere Personen denselben Computer verwenden können, ohne die Daten und Einstellungen des anderen zu beschädigen oder zu überschreiben. Zusammenfassung der Installations-/Deinstallationsanforderungen
Unterstützung von Sitzungen mit mehreren Benutzern Windows-Benutzer sollten in der Lage sein, gleichzeitige Sitzungen ohne Konflikte oder Unterbrechungen auszuführen. Programmierrichtlinien für Remotedesktopdienste
Unterstützung von x64-Versionen von Windows Da 64-Bit-Hardware immer häufiger auftritt, erwarten Benutzer, dass App-Entwickler die Vorteile der 64-Bit-Architektur nutzen, indem sie ihre Apps zu 64-Bit migrieren, oder dass 32-Bit-Versionen der App unter 64-Bit-Versionen von Windows gut ausgeführt werden. Anwendungskompatibilität: Windows Vista 64-Bit

Siehe auch