Kit de développement logiciel (SDK) Windows

Le SDK Windows (10.0.22621) pour Windows 11, version 22H2 fournit les derniers en-têtes, bibliothèques, métadonnées et outils pour la création d’applications Windows. Utilisez ce Kit de développement logiciel (SDK) pour générer des applications plateforme Windows universelle (UWP) et Win32 pour Windows 11, version 22H2 et versions antérieures de Windows.

Conseil

Kit de développement logiciel (SDK) pour application Windows
Le SDK d'application Windows fournit un ensemble unifié d’API et d’outils découplés du système d’exploitation et publiés pour les développeurs via des packages NuGet. Ces API et outils peuvent être utilisés de manière cohérente par n’importe quelle application de bureau sur Windows 11 et de bas niveau pour Windows 10, version 1809.

Prise en main

Vous pouvez obtenir le SDK Windows de deux façons : l’installer à partir de cette page en sélectionnant le lien de téléchargement ou en sélectionnant « Windows 11 SDK (10.0.22621.0) » dans les composants facultatifs du programme d’installation de Visual Studio 2022. Avant d’installer ce SDK :

Dernière mise à jour : 4 octobre 2021

Configuration requise

La configuration minimale requise pour le SDK Windows est la suivante :

Systèmes d’exploitation pris en charge

  • Windows 10 version 1507 ou ultérieure : Famille, Professionnel, Éducation et Entreprise (LTSB et S ne sont pas pris en charge pour UWP)
  • Windows Server 2022, Windows Server 2019, Windows Server 2016 et Windows Server 2012 R2 (ligne de commande uniquement)
  • Windows 8.1
  • Windows 7 SP1

(Tous les outils ne sont pas pris en charge sur les systèmes d’exploitation antérieurs.)

Configuration matérielle requise

  • Processeur 1,6 GHz minimum
  • 1 Go de mémoire RAM
  • 4 Go d’espace disque disponible

Exigences supplémentaires

L’installation sur Windows 8.1 et les systèmes d’exploitation antérieurs nécessite une mise à jour pour le runtime C universel dans Windows. Pour effectuer l’installation via Windows Update, veillez à installer les derniers correctifs et mises à jour Microsoft Update recommandés avant d’installer le SDK Windows.

Exemples

Les exemples d’applications Windows sont désormais disponibles via GitHub. Vous pouvez parcourir le code sur GitHub, cloner une copie personnelle du référentiel à partir de Git ou télécharger une archive compressée de tous les exemples. Vos commentaires sont les bienvenus, n’hésitez pas à ouvrir un ticket dans le référentiel en cas de problème ou de question. Ces exemples sont conçus pour s’exécuter sur tous les appareils (de bureau, mobiles et futurs) qui prennent en charge la plateforme Windows universelle (UWP).

Versions précédentes du Kit de développement logiciel (SDK)

Les Kits de développement logiciel (SDK) et émulateurs précédemment publiés sont accessibles sur la page Archives.

API Light Up

Lorsque vous utilisez de nouvelles API, envisagez d’écrire votre application pour qu’elle s’exécute correctement sur le plus large éventail d’appareils Windows. Une application adaptative « s’allume » avec de nouvelles fonctionnalités partout où les appareils et la version de Windows les prennent en charge, mais offre uniquement les fonctionnalités disponibles sur la version de la plateforme détectée. Pour plus d’informations sur l’implémentation, consultez l’article sur le code adaptatif version.

Notes de publication et problèmes connus

sdk Windows 10, version 2104
  • Suppression d’api-ms-win-net-isolation-l1-1-0.lib. Les applications qui étaient liées à api-ms-win-net-isolation-l1-1-0.lib peuvent basculer vers OneCoreUAP.lib en remplacement.

  • Suppression d’irprops.lib. Les applications qui étaient liées à irprops.lib peuvent basculer vers bthprops.lib comme remplacement de dépôt.

  • Déplacez ENUM tagServerSelection de wuapicommon.h vers wupai.h et supprimez l’en-tête. Si vous souhaitez utiliser la balise ENUM tagServerSelection, vous devez inclure wuapi.h ou wuapi.idl.

  • Le pack d’API WinRT Windows 10 vous permet d’ajouter la dernière prise en charge des API Windows Runtime à vos bibliothèques et applications .NET Framework 4.5+ et .NET Core 3.0+. Pour accéder au pack d’API WinRT Windows 10, consultez le package nuget Microsoft.Windows.SDK.Contracts.

  • La famille printf de fonctions est désormais conforme aux règles d’arrondi IEEE 754 lors de l’impression de nombres à virgule flottante représentant exactement et honorera le mode d’arrondi demandé par les appels à fesetround. Le comportement hérité est disponible lors de la liaison avec legacy_stdio_float_rounding.obj.

  • Kit de certification des applications Windows. Plusieurs nouvelles API ont été ajoutées à la liste des API prises en charge dans le Kit de certification des applications et le Windows Store. S’il existe des API dans la liste prise en charge qui apparaissent grisées ou désactivées dans Visual Studio, vous pouvez apporter une petite modification à votre fichier source pour y accéder. Pour plus d’informations, consultez ce problème connu. Trouvez d’autres mises à jour pour les tests.

  • Mises à jour du compilateur de messages (mc.exe) :

    • Détecte maintenant la marque d’ordre d’octet Unicode (BOM) dans les fichiers .mc. Si le fichier .mc commence par un boM UTF-8, il est lu en tant que fichier UTF-8. Sinon, s’il commence par un boM UTF-16LE, il est lu en tant que fichier UTF-16LE. Si le paramètre -u a été spécifié, il est lu en tant que fichier UTF-16LE. Sinon, elle sera lue à l’aide de la page de codes actuelle (CP_ACP).
    • À présent, évitez les problèmes d’une règle de définition (ODR) dans les helpers ETW générés par MC générés par C/C++ etW causés par des macros de configuration en conflit (par exemple, lorsque deux fichiers .cpp avec des définitions conflictuelles de MCGEN_EVENTWRITETRANSFER sont liés dans le même binaire, les helpers ETW générés par MC respectent désormais la définition de MCGEN_EVENTWRITETRANSFER dans chaque fichier .cpp au lieu de choisir arbitrairement l’un ou l’autre).
  • Mises à jour du préprocesseur de trace Windows (tracewpp.exe) :

    • Prend en charge les fichiers d’entrée Unicode (.ini, .tpl et code source). Les fichiers d’entrée commençant par une marque d’ordre d’ordre d’octet UTF-8 ou UTF-16 sont lus au format Unicode. Les fichiers d’entrée qui ne commencent pas par un boM sont lus à l’aide de la page de codes actuelle (CP_ACP). Pour une compatibilité descendante, si le paramètre de ligne de commande -UnicodeIgnore est spécifié, les fichiers commençant par un boM UTF-16 sont traités comme vides.
    • Prend en charge les fichiers de sortie Unicode (.tmh). Par défaut, les fichiers de sortie sont encodés à l’aide de la page de codes actuelle (CP_ACP). Utilisez les paramètres de ligne de commande -cp:UTF-8 ou -cp:UTF-16 pour générer des fichiers de sortie Unicode.
    • Modification du comportement : tracewpp convertit désormais tout le texte d’entrée en Unicode, effectue le traitement en Unicode et convertit le texte de sortie en encodage de sortie spécifié. Les versions antérieures de tracewpp ont évité les conversions Unicode et effectué le traitement du texte en supposant un jeu de caractères sur un octet. Cela peut entraîner des changements de comportement dans les cas où les fichiers d’entrée ne sont pas conformes à la page de codes actuelle. Dans les cas où il s’agit d’un problème, envisagez de convertir les fichiers d’entrée en UTF-8 (avec boM) et/ou en utilisant le paramètre de ligne de commande -cp:UTF-8 pour éviter l’ambiguïté de l’encodage.
  • Mises à jour de TraceLoggingProvider.h :

    • Évite les problèmes de règle d’une seule définition (ODR) causés par des macros de configuration en conflit (par exemple, lorsque deux fichiers .cpp avec des définitions conflictuelles de TLG_EVENT_WRITE_TRANSFER sont liés au même binaire, les helpers TraceLoggingProvider.h respectent désormais la définition de TLG_EVENT_WRITE_TRANSFER dans chaque fichier .cpp au lieu de choisir arbitrairement l’un ou l’autre).
    • Dans le code C++, la macro TraceLoggingWrite a été mise à jour pour permettre un meilleur partage de code entre des événements similaires à l’aide de modèles variadiciques.
  • Signature de vos applications. La signature Device Guard est une fonctionnalité Device Guard disponible dans Microsoft Store pour Entreprises et Éducation, ce qui permet aux entreprises de garantir que chaque application provient d’une source approuvée. Consultez la documentation relative à la signature Device Guard.

  • Les en-têtes du Kit de développement logiciel (SDK) ont été mis à jour pour résoudre les erreurs lors de la compilation à l’aide du préprocesseur C conforme aux normes dans le compilateur MSVC cl.exe (/Zc:preprocessor, introduit dans VS 2019 v16.6).

  • Correction : « GdiplusTypes.h ne se compile pas avec NOMINMAX ». Consultez les commentaires de Visual Studio.

  • Lorsque vous générez avec /std:c11 ou /std:c17, vous obtenez maintenant :

    • C99 tgmath.h
    • C11 static_assert dans assert.h
    • C11 stdalign.h
    • C11 stdnoreturn.h
  • Clang/LLVM pour Windows v11 ciblant ARM64 n’est pas compatible avec la dernière version winnt.h

    • Pour contourner ce problème, utilisez la version précédente du SDK Windows 10 (build 19041) ou clang/LLVM pour Windows v10 lors du ciblage des plateformes ARM64
  • DirectXMath (y compris la version 3.16 de cette version) n’est pas compatible avec Clang/LLVM pour Windows sur ARM64.

  • Le cas de certains fichiers d’en-tête a été modifié pour les normaliser pour les systèmes de fichiers sensibles à la casse :

    • OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h et OleCtl.h ont tous été effectués en minuscules.
    • Pour Clang/LLVM pour les builds Windows, pour prendre en charge les versions antérieures et les derniers Windows 10 SDK sans avertissements, ajoutez -Wno-nonportable-system-include-path à l’interface CLI ou les #pragma suivantes dans la source :

    #ifdef __clang__

    #pragma clang diagnostic ignored "-Wnonportable-system-include-path"

    #endif

Windows 10 SDK, version 2004 mise à jour de maintenance (publiée 12/16/2020)

Cette version contient les fichiers suivants. Si vous rencontrez ces problèmes, nous vous recommandons de mettre à jour votre version du Kit de développement logiciel (SDK) dès que possible pour les éviter :

  • Résolution des incidents imprévisibles et difficiles à diagnostiquer lors de la liaison des bibliothèques de parapluies et des bibliothèques de système d’exploitation natives (par exemple, onecoreuap.lib et kernel32.lib)
  • Problème résolu qui empêchait AppVerifier de fonctionner
  • Problème résolu qui a provoqué l’échec de WACK avec « Échec de la tâche pour activer HighVersionLie »

Plus de ressources