Windows SDK

Das Windows SDK (10.0.22000) für Windows 11 enthält die neuesten Header, Bibliotheken, Metadaten und Tools zum Entwickeln von Apps für Windows. Verwende dieses SDK, um UWP- und Win32-Anwendungen für Windows 11 und frühere Windows-Releases zu entwickeln.

Erste Schritte

Du kannst das Windows SDK auf zwei Arten beziehen: Installiere es über diese Website, indem du auf den Downloadlink klickst, oder wähle „Windows 11 SDK (10.0.22000)“ aus den optionalen Komponenten im Installer für Visual Studio 2019 aus.

Vor der SDK-Installation:

  1. Informieren Sie sich über sämtliche Systemanforderungen.
  2. Beende Visual Studio 2019 vor der Installation.
  3. Lesen Sie die Versionshinweise und die bekannten Probleme.

Systemanforderungen

Für das Windows SDK gelten folgende Mindestvoraussetzungen:

Unterstützte Betriebssysteme

  • Entwicklung von UWP-Apps (universelle Windows-Plattform)
    • Windows 10, Version 1507 oder höher: Home, Professional, Education und Enterprise (LTSB und S werden nicht unterstützt)
    • Windows Server 2019, Windows Server 2016 und Windows Server 2012 R2 (nur Befehlszeile)
  • Entwicklung von Win32-Apps
    • Windows 10 ab Version 1507
    • Windows Server 2019, Windows Server 2016 und Windows Server 2012 R2 (nur Befehlszeile)
    • Windows 8.1
    • Windows 7 SP1

(Unter früheren Betriebssystemen werden nicht alle Tools unterstützt.)

Hardwareanforderungen

  • Prozessor mit 1,6 GHz oder mehr
  • 1 GB RAM
  • 4 GB verfügbarer Speicherplatz auf der Festplatte

Weitere SDK-Anforderungen

Die Installation unter Windows 8.1 und älteren Betriebssystemen erfordert KB2999226. Für die Installation über Windows Update sollten die neuesten empfohlenen Updates und Patches von Microsoft Update installiert sein, bevor Sie das Windows SDK installieren.

Neuigkeiten

Mit Windows SDK für Windows 11 kannst du deine Apps für die neueste Version des Windows-Betriebssystems aktualisieren. Hier erfährst du mehr über die neuen Features von Windows 11.

Die neu mit Windows 11 eingeführten APIs findest du unter Neue APIs in Windows 11 Build 22000.

Die Binärdateien von Windows 11 wurden für ARM-Betriebssysteme mit ARM64EC neu erstellt, sodass der von x64-Apps geladene Systemcode mit nativer Geschwindigkeit ausgeführt wird. Mithilfe von ARM64EC kannst du deine Apps nach und nach für die Ausführung mit nativer Geschwindigkeit unter ARM optimieren, auch wenn Abhängigkeiten oder Plug-Ins vorhanden sind, die ARM noch nicht unterstützen. Hier kannst du die Ankündigung lesen.

Beispiele

Beispiele für Windows-Apps sind jetzt auf GitHub verfügbar. Sie können den Code auf GitHub durchsuchen, von Git eine persönliche Kopie des Repositorys klonen oder ein gezipptes Archiv mit allen Beispielen herunterladen. Wir freuen uns immer über Feedback. Erstellen Sie im Repository also gern eine Anfrage, wenn Sie ein Problem oder eine Frage haben. Diese Beispiele sind für die Ausführung auf Desktopgeräten, mobilen Geräten und zukünftigen Geräten ausgelegt, welche die Universelle Windows-Plattform (UWP) unterstützen.

Vorherige SDK-Versionen

Früher veröffentlichte SDKs und Emulatoren sowie Updatedetails finden Sie auf der Archivseite.

Neue APIs

Bedenke bei der Verwendung neuer APIs, deine App anpassbar zu programmieren, damit sie auf möglichst vielen Windows-Geräten ausgeführt werden kann. Eine anpassbare App liefert neue Features, wenn Geräte und die Windows-Version diese unterstützen, bietet aber ansonsten nur die Features, die auf der erkannten Plattformversion verfügbar sind. Implementierungsdetails finden Sie im Artikel zu versionsadaptivem Code.

Versionshinweise und bekannte Probleme

Windows 10 SDK, Version 2104

  • Die Datei „api-ms-win-net-isolation-l1-1-0.lib“ wurde entfernt. Für Apps, die mit „api-ms-win-net-isolation-l1-1-0.lib“ verknüpft waren, kann „OneCoreUAP.lib“ als Ersatz verwendet werden.
  • Die Datei „irprops.lib“ wurde entfernt. Für Apps, die mit „irprops.lib“ verknüpft waren, kann „bthprops.lib“ als Ersatz verwendet werden.
  • Das Element „ENUM tagServerSelection“ von „wuapicommon.h“ in „wupai.h“ verschoben, und der Header wurde entfernt. Wenn Sie „ENUM tagServerSelection“ verwenden möchten, müssen Sie „wuapi.h“ oder „wuapi.idl“ einbinden.
  • Mit dem Windows 10 WinRT API Pack können Sie Ihren .NET Framework 4.5- (oder höher) und .NET Core 3.0-Bibliotheken (oder höher) und -Apps die neueste Unterstützung für Windows-Runtime-APIs hinzufügen. Weitere Informationen zum Zugriff auf das Windows 10 WinRT API Pack finden Sie unter Microsoft.Windows.SDK.Contracts-NuGet-Paket.
  • Die printf-Funktionsfamilie ist nun mit den IEEE 754-Rundungsregeln konform, wenn genau darstellbare Gleitkommazahlen ausgegeben werden. Der Rundungsmodus wird bei Aufrufen von fesetround berücksichtigt. Du kannst das vorherige Verhalten nutzen, indem du eine Verknüpfung mit legacy_stdio_float_rounding.obj herstellst.
  • Windows App Certification Kit: Mehrere neue APIs wurden zur Liste der unterstützten APIs im App Certification Kit und im Microsoft Store hinzugefügt. Wenn in der unterstützten Liste APIs vorhanden sind, die in Visual Studio ausgegraut oder als deaktiviert angezeigt werden, können Sie eine kleine Änderung an der Quelldatei vornehmen, um auf diese zuzugreifen. Weitere Informationen finden Sie im Artikel zu bekannten Problemen. Hier findest du weitere Updates an Tests.
  • Updates für Message Compiler (mc.exe):
    • Die Byte Order Mark (BOM) für Unicode wird jetzt in MC-Dateien erkannt. Wenn die MC-Datei mit einer UTF-8-BOM beginnt, wird sie als UTF-8-Datei gelesen. Wenn sie dagegen mit einer UTF-16LE-BOM beginnt, wird sie als UTF-16LE-Datei gelesen. Wenn der Parameter -u angegeben wurde, wird sie als UTF-16LE-Datei gelesen. Andernfalls wird sie mithilfe der aktuellen Codepage (CP_ACP) gelesen.
    • ODR-Probleme (One Definition Rule) in aus MC-Dateien generierten C/C++-ETW-Hilfsprogrammen, die durch widersprüchliche Konfigurationsmakros verursacht werden, werden jetzt vermieden. Diese liegen beispielsweise vor, wenn zwei CPP-Dateien mit widersprüchlichen Definitionen von MCGEN_EVENTWRITETRANSFER mit derselben Binärdatei verknüpft werden. Die aus MC-Dateien generierten ETW-Hilfsprogramme berücksichtigen jetzt die Definition von MCGEN_EVENTWRITETRANSFER in jeder CPP-Datei, anstatt willkürlich eine auszuwählen.
  • Updates für Windows Trace Preprocessor (tracewpp.exe):
    • Unicode-Eingabedateien (INI-Dateien, TPL-Dateien und Quellcodedateien) werden unterstützt. Eingabedateien, die mit einer UTF-8- oder UTF-16-BOM beginnen, werden als Unicode gelesen. Eingabedateien, die nicht mit einer BOM beginnen, werden mithilfe der aktuellen Codepage (CP_ACP) gelesen. Aus Gründen der Abwärtskompatibilität werden Dateien, die mit einer UTF-16-BOM beginnen, als leer behandelt, wenn der Befehlszeilenparameter -UnicodeIgnore angegeben ist.
    • Unicode-Ausgabedateien (TMH-Dateien) werden unterstützt. Standardmäßig werden Ausgabedateien mithilfe der aktuellen Codepage (CP_ACP) codiert. Verwenden Sie die Befehlszeilenparameter -cp:UTF-8 oder -cp: UTF-16, um Unicode-Ausgabedateien zu generieren.
    • Verhaltensänderung: tracewpp konvertiert nun den gesamten Eingabetext in Unicode, führt die Verarbeitung in Unicode durch und konvertiert den Ausgabetext in die angegebene Ausgabecodierung. Frühere Versionen von tracewpp haben Unicode-Konvertierungen vermieden und die Textverarbeitung wie bei einem Einzelbytezeichensatz ausgeführt. Dadurch kann eine Verhaltensänderung auftreten, wenn die Eingabedateien nicht der aktuellen Codepage entsprechen. Falls daraus ein Problem entsteht, sollten Sie die Eingabedateien in UTF-8 (mit BOM) konvertieren und/oder den Befehlszeilenparameter -cp:UTF-8 verwenden, um Mehrdeutigkeiten bei der Codierung zu vermeiden.
  • Updates für „TraceLoggingProvider.h“:
    • ODR-Probleme (One Definition Rule), die durch widersprüchliche Konfigurationsmakros verursacht werden, werden vermieden. Diese liegen beispielsweise vor, wenn zwei CPP-Dateien mit widersprüchlichen Definitionen von TLG_EVENT_WRITE_TRANSFER mit derselben Binärdatei verknüpft werden. Die TraceLoggingProvider.h-Hilfsprogramme berücksichtigen jetzt die Definition von TLG_EVENT_WRITE_TRANSFER in jeder CPP-Datei, anstatt willkürlich eine auszuwählen.
    • Im C++-Code wurde das TraceLoggingWrite-Makro aktualisiert, sodass mithilfe von Variadic-Vorlagen eine bessere Codefreigabe zwischen ähnlichen Ereignissen möglich ist.
  • Apps signieren: Die Device Guard-Signatur ist ein Feature von Device Guard, das im Microsoft Store für Unternehmen und Bildungseinrichtungen verfügbar ist. Unternehmen können mit diesem Feature zuverlässig überprüfen, ob Apps aus vertrauenswürdigen Quellen stammen. Weitere Informationen finden Sie in der Dokumentation zur Device Guard-Signatur.
  • Die SDK-Header wurden aktualisiert, um Fehler zu beheben, die beim Kompilieren mit dem standardkonformen C-Präprozessor in der „cl.exe“ des MSVC-Compilers (/Zc:preprocessor, eingeführt in VS 2019 v16.6) aufgetreten sind.
  • Behoben: „GdiplusTypes.h does not compile with NOMINMAX.“ (GdiplusTypes.h kann mit NOMINMAX nicht kompiliert werden.) Weitere Informationen finden Sie unter dem Visual Studio-Feedback.
  • Bei der Entwicklung mit „/std:c11“ oder „/std:c17“ erhalten Sie jetzt Folgendes:
    • C99 tgmath.h
    • C11 static_assert in assert.h
    • C11 stdalign.h
    • C11 stdnoreturn.h
  • Clang/LLVM für Windows v11 für ARM64 ist nicht mit der neuesten „winnt.h“-Datei kompatibel
    • Verwenden Sie als Problemumgehung die vorherige Version des Windows 10 SDK (Build 19041) oder clang/LLVM für Windows v10 für ARM64-Plattformen.
  • DirectXMath (einschließlich Version 3.16 in diesem Release) ist nicht mit Clang/LLVM für Windows unter ARM64 kompatibel.
  • Die Schreibweise einiger Headerdateien wurde geändert, um sie für Dateisysteme zu normalisieren, bei denen die Groß-/Kleinschreibung beachtet wird:
    • Die Namen „OAIdl.h“, „ObjIdl.h“, „ObjIdlbase.h“, „OCIdl.h“, „Ole2.h“, „OleAuto.h“ und „OleCtl.h“ wurden in Kleinbuchstaben geändert.
    • Damit für Builds vom Typ Clang/LLVM für Windows sowohl die frühere Version als auch das aktuelle Windows 10 SDK ohne Warnungen unterstützt wird, sollten Sie der CLI „-Wno-nonportable-system-include-path“ oder den folgenden #pragma-Code in der Quelle hinzufügen:

      #ifdef __clang__
      #pragma clang diagnostic ignored "-Wnonportable-system-include-path"
      #endif

Wartungsupdate für Windows 10 SDK, Version 2004 (Veröffentlichung: 16.12.2020)

    Dieses Release enthält die folgenden Dateien. Wenn diese Probleme bei Ihnen auftreten, sollten Sie Ihre SDK-Version so schnell wie möglich aktualisieren, um diese zu vermeiden:
  • Unvorhersehbare und schwer diagnostizierbare Abstürze bei der Verknüpfung von umbrella-Bibliotheken und nativen Betriebssystembibliotheken (z. B. „onecoreuap.lib“ und „kernel32.lib“) wurden behoben.
  • Es wurde ein Problem behoben, das dazu geführt hat, dass AppVerifier nicht mehr funktioniert.
  • Es wurde der WACK-Fehler „Task failed to enable HighVersionLie“ (Der Task konnte HighVersionLie nicht aktivieren.) behoben.

Feedback senden

Bekannte Probleme finden Sie im Q&A zu winapi-sdk.

Sie können neue Entwicklerfeatures über die Kategorie „Developer Platform/API“ (Entwicklerplattform/API) in der Feedback-Hub-App vorschlagen.

Weitere Informationsquellen

Downloads und Tools

Laden Sie sich die neuesten Editionen von Visual Studio und den Windows 10-Entwicklungstools herunter.

WEITERE INFORMATIONEN

SDK-Archiv

Suchen Sie nach vorherigen Versionen des Windows SDK und anderen Tools.

ARCHIV ANZEIGEN

Windows-Blog

Auf unserem Blog erhalten Sie immer die aktuellen Informationen zu den neuesten SDK-Flights.

INFORMATIONEN ZU SDK-FLIGHTS ERHALTEN

Informationen zum Windows-Lebenszyklus

Informationen zu den Terminen der Veröffentllichung von Windows-Releaseupdates und zum Ende des Supports.

INFORMATIONEN ANZEIGEN