SDK Windows

SDK Windows 10, version 2104 Développer les notes

• Nous avons supprimé api-ms-win-net-isolation-l1-1-0.lib. Les applications qui se connectaient à api-ms-win-net-isolation-l1-1-0.lib peuvent basculer vers OneCoreUAP.lib en remplacement.
• Nous avons supprimé irprops.lib. Les applications qui se connectaient à irprops.lib peuvent basculer vers bthprops.lib en remplacement.
• Nous avons déplacé ENUM tagServerSelection de wuapicommon.h vers wupai.h et supprimé l’en-tête. Si vous souhaitez utiliser ENUM tagServerSelection, vous devez inclure wuapi.h ou wuapi.idl.
• Avec le pack d’API Windows 10 WinRT, ajoutez les toutes dernières API Windows Runtime à vos bibliothèques et applications .NET Framework 4.5+ et .NET Core 3.0+. Pour accéder au pack d’API Windows 10 WinRT, consultez le package nuget Microsoft.Windows.SDK.Contracts.
• Désormais, la famille de fonctions printf se conforme aux règles d’arrondi IEEE 754 lors de l’affichage de valeurs en virgule flottante représentables exactement et honorera le mode d’arrondi demandé via des 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 Microsoft Store. S’il existe des API dans la liste des API prises 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, reportez-vous à ce problème connu. Recherchez d’autres mises à jour pour les tests.
• Mises à jour Message Compiler (mc.exe) :
  • Détecte à présent la marque d’ordre d’octet Unicode dans les fichiers .mc. Si le fichier .mc commence par une marque d’ordre d’octet UTF-8, il est lu en tant que fichier UTF-8. Sinon, s’il commence par une marque d’ordre d’octet 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, il est lu à l’aide de la page de codes actuelle (CP_ACP).
  • Évite à présent les problèmes de règle à une seule définition dans les applications auxiliaires C/C++ ETW générées par MC en raison de conflits de macros de configuration. Par exemple, lorsque deux fichiers .cpp avec des définitions en conflit de MCGEN_EVENTWRITETRANSFER sont liés au même binaire, les applications auxiliaires ETW générées par MC respectent à présent la définition de MCGEN_EVENTWRITETRANSFER dans chaque fichier .cpp au lieu de choisir arbitrairement l’une ou l’autre.
• Mises à jour du préprocesseur de trace de Windows (tracewpp.exe) :
  • Prise en charge des fichiers d’entrée Unicode (.ini, .tpl et code source). Les fichiers d’entrée commençant par une marque d’ordre d’octet UTF-8 ou UTF-16 sont lus au format Unicode. Les fichiers d’entrée qui ne commencent pas par une marque d’ordre d’octet sont lus à l’aide de la page de codes actuelle (CP_ACP). À des fins de compatibilité descendante, si le paramètre de ligne de commande -UnicodeIgnore est spécifié, les fichiers commençant par une marque d’ordre d’octet UTF-16 sont traités comme vides.
  • Prise en charge des 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.
  • Changement de comportement : tracewpp convertit à présent tout le texte d’entrée en Unicode, effectue le traitement en Unicode et convertit le texte de sortie dans l’encodage de sortie spécifié. Les versions antérieures de tracewpp évitaient les conversions Unicode et effectuaient le traitement du texte en supposant un jeu de caractères codés sur un octet. Cela peut entraîner des changements de comportement lorsque les fichiers d’entrée ne sont pas conformes à la page de codes actuelle. Si cela constitue un problème, envisagez de convertir les fichiers d’entrée en UTF-8 (avec marque d’ordre d’octet) et/ou en utilisant le paramètre de ligne de commande -cp:UTF-8 pour éviter toute ambiguïté d’encodage.
• Mises à jour du fichier TraceLoggingProvider.h :
  • Évite les problèmes de règle à une seule définition dus à des conflits de macros de configuration. Par exemple, lorsque deux fichiers .cpp avec des définitions en conflit de TLG_EVENT_WRITE_TRANSFER sont liés au même binaire, les applications auxiliaires TraceLoggingProvider.h respectent à présent la définition de TLG_EVENT_WRITE_TRANSFER dans chaque fichier .cpp au lieu de choisir arbitrairement l’une 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 variadiques.
• Signature de vos applications. La signature Device Guard est une fonctionnalité Device Guard disponible dans Microsoft Store pour Entreprises et Éducation. Elle permet aux entreprises de garantir que chaque application provient d’une source fiable. Consultez la documentation sur la signature Device Guard.
• Les en-têtes du SDK ont été mis à jour pour résoudre les erreurs lors de la compilation à l’aide du préprocesseur C conforme aux standards dans le compilateur MSVC cl.exe (/Zc:preprocessor, introduit dans VS 2019 v16.6).
• Résolution : « GdiplusTypes.h n’est pas compilé avec NOMINMAX ». Consultez les commentaires sur Visual Studio.
• Lors de la génération avec /std :c11 ou /std:C17, vous bénéficiez à présent des éléments suivants :
  • 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 de 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 lorsque vous ciblez les plateformes ARM64
• DirectXMath (y compris la version 3.16 dans cette version) n’est pas compatible avec Clang/LLVM pour Windows sur ARM64.
  • Pour contourner ce problème, utilisez la dernière version de DirectXMath, disponible à partir de NuGet, vcpkg ou GitHub. Ces versions incluent les correctifs requis (version 3.16b).
    • https://www.nuget.org/packages/directxmath
    • https://github.com/microsoft/vcpkg/tree/master/ports/directxmath
    • https://github.com/microsoft/DirectXMath
• La casse de certains fichiers d’en-tête a été modifiée, afin de 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 sont à présent tous en minuscules.
  • Pour les builds Clang/LLVM pour Windows, pour prendre en charge à la fois la version antérieure et le dernier SDK Windows 10 sans avertissements, ajoutez « -Wno-nonportable-system-include-path » à l’interface CLI ou le #pragma suivant dans la source :

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