Kit de développement logiciel (SDK) Windows

Mise à jour de maintenance 10.0.22621.3235.

Mise à jour de maintenance 10.0.22621.2428.

Mise à jour 10.0.22621.1778. Les fonctionnalités mises en évidence sont les suivantes :

• Les API WindowTabManager permettent aux applications avec des interfaces à onglets de fournir des informations sur les onglets ouverts à l’interpréteur de commandes Windows.
• Mises à jour aux API HumanPresence pour améliorer la facilité d’utilisation et ajouter de nouveaux paramètres pour les capteurs qui prennent en charge les fonctionnalités de présence humaine.
• Les API RemoteDesktop permettent aux applications de basculer entre un bureau distant et un bureau local.

• Mise à jour de maintenance 10.0.22621.755. Inclut la prise en charge d’ARM64 pour la version VS 17.4

• Suppression de 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 t OneCoreUAP.lib en remplacement.

• Suppression de irprops.lib. Les applications qui étaient liées à irprops.lib peuvent basculer vers bthprops.lib comme remplacement de la liste déroulante.

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

• Le pack d’API winRT Windows 10 vous permet d’ajouter la prise en charge des API Windows Runtime les plus récentes à 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 de fonctions printf est désormais conforme aux règles d’arrondi IEEE 754 lors de l’impression de nombres à virgule flottante représentant exactement et respectera le mode d’arrondi demandé via 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 d’application et le Windows Store. Si la liste prise en charge contient des API 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 des tests.

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

  • Détecte maintenant la marque d’ordre d’octet Unicode dans les fichiers .mc. Si le fichier .mc commence par une nomenclature UTF-8, il sera lu sous la forme d’un fichier UTF-8. Sinon, si elle commence par une nomenclature UTF-16LE, elle sera lue en tant que fichier UTF-16LE. Si le paramètre -u a été spécifié, il sera lu sous la forme d’un fichier UTF-16LE. Sinon, il sera lu à l’aide de la page de code active (CP_ACP).
  • Évite maintenant les problèmes de règle à une définition (ODR) dans les assistances ETW C/C++ générées par MC, causés par des macros de configuration en conflit (par exemple, lorsque deux fichiers .cpp avec des définitions de MCGEN_EVENTWRITETRANSFER en conflit sont liés dans le même binaire, les assistances ETW générées par MC respectent désormais la définition de MCGEN_EVENTWRITETRANSFER dans chaque fichier .cpp au lieu de sélectionner arbitrairement l’un ou l’autre).

• Mises à jour du préprocesseur de traces 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’octet (BOM) UTF-8 ou UTF-16 sont lus en unicode. Les fichiers d’entrée qui ne commencent pas par une nomenclature sont lus à l’aide de la page de code active (CP_ACP). Pour la compatibilité descendante, si le paramètre de ligne de commande -UnicodeIgnore est spécifié, les fichiers commençant par une nomenclature 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 code active (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 maintenant 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 un traitement de 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 code actuelle. En cas de problème, envisagez de convertir les fichiers d’entrée en UTF-8 (avec boM) et/ou d’utiliser le paramètre de ligne de commande -cp :UTF-8 pour éviter toute ambiguïté d’encodage.

• TraceLoggingProvider.h met à jour :

  • Évite les problèmes de règle à une définition (ODR) causés par des macros de configuration en conflit (par exemple, lorsque deux fichiers .cpp avec des définitions de TLG_EVENT_WRITE_TRANSFER en conflit sont liés dans le même binaire, les assistances TraceLoggingProvider.h respectent désormais la définition de TLG_EVENT_WRITE_TRANSFER dans chaque fichier .cpp au lieu de sélectionner 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 variadiques.

• Signature de vos applications. La signature Device Guard est une fonctionnalité Device Guard disponible dans Microsoft Store pour Entreprises et Éducation, 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 à la norme dans le compilateur MSVC cl.exe (/Zc :préprocesseur, introduit dans VS 2019 v16.6).

• Correction : « GdiplusTypes.h ne se compile pas avec NOMINMAX ». Consultez Commentaires visual Studio.

• Lors de la génération 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 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 lors du ciblage des 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 à chaud requis (version 3.16b).
    • www.nuget.org/packages/directxmath
    • github.com/microsoft/vcpkg/tree/master/ports/directxmath
    • github.com/microsoft/DirectXMath

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

  • OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h et OleCtl.h ont tous été mis en minuscules.
  • Pour les builds Clang/LLVM pour Windows, pour prendre en charge à la fois l’ancienne version et la dernière version du SDK Windows 10 sans avertissements, ajoutez -Wno-nonportable-system-include-path à l’interface CLI ou aux #pragma suivantes dans la source :

  #ifdef __clang__

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

  #endif

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 problèmes imprévisibles et difficiles à diagnostiquer lors de la liaison des bibliothèques parapluie 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
• Résolution du problème qui provoquait l’échec de WACK avec « La tâche n’a pas pu activer HighVersionLie »