Windows SDK

Karbantartási frissítés: 10.0.22621.2428.

Frissítés: 10.0.22621.1778. A kiemelt funkciók közé tartoznak a következők:

• A WindowTabManager API-k lehetővé teszik, hogy a többlapos felülettel rendelkező alkalmazások információt nyújtsanak a Windows rendszerhéj nyitott lapjairól.
• Frissítések a HumanPresence API-khoz, hogy javítsa a könnyű használatot, és új beállításokat adjon hozzá az emberi jelenléti képességeket támogató érzékelőkhöz.
• A RemoteDesktop API-k lehetővé teszik az alkalmazások számára a távoli és a helyi asztal közötti váltást.

• Karbantartási frissítés: 10.0.22621.755. Arm64-támogatást tartalmaz a VS 17.4 kiadáshoz

• Eltávolította az api-ms-win-net-isolation-l1-1-0.lib fájlt. Az api-ms-win-net-isolation-l1-1-0.lib fájlhoz kapcsolt alkalmazások lecserélhetik a t OneCoreUAP.lib fájlt.

• Eltávolított irprops.lib. Az irprops.lib-hez kapcsolt alkalmazások a bthprops.lib fájlra válthatnak lemorzsolódási csereként.

• Áthelyezte az ENUM tagServerSelection-et a wuapicommon.h-ról a wupai.h-ra, és eltávolította a fejlécet. Ha az ENUM tagServerSelectiont szeretné használni, a wuapi.h vagy a wuapi.idl értéket kell tartalmaznia.

• A Windows 10 WinRT API-csomag lehetővé teszi, hogy a legújabb Windows-futtatókörnyezet API-támogatást adja hozzá a .NET-keretrendszer 4.5+ és .NET Core 3.0+-tárakhoz és alkalmazásokhoz. A Windows 10 WinRT API Pack eléréséhez tekintse meg a Microsoft.Windows.SDK.Contracts nuget-csomagot.

• A nyomtatófüggvény-család mostantól megfelel az IEEE 754 kerekítési szabályainak , amikor pontosan ábrázolható lebegőpontos számokat nyomtat, és tiszteletben tartja a fesetround hívásaival kért kerekítési módot. Az örökölt viselkedés a legacy_stdio_float_rounding.obj-val való összekapcsoláskor érhető el.

• Windows-alkalmazástanúsítvány-készlet. Az alkalmazástanúsítvány-készlet és a Windows Áruház számos új API-t adott hozzá a támogatott API-k listájához. Ha a támogatott listában vannak olyan API-k, amelyek szürkén jelennek meg vagy le vannak tiltva a Visual Studióban, a forrásfájlt kis módosítással érheti el. További részletekért lásd ezt az ismert problémát. További frissítések a tesztekhez.

• Az Üzenetfordító (mc.exe) frissítései:

  • Most észleli a Unicode bájtok sorrendjének jelölését (BOM) a .mc fájlokban. Ha a .mc fájl UTF-8 BOM-tal kezdődik, az UTF-8 fájlként lesz olvasható. Ellenkező esetben, ha egy UTF-16LE BOM-tal kezdődik, az UTF-16LE fájlként lesz olvasható. Ha a -u paraméter meg van adva, az UTF-16LE-fájlként lesz olvasható. Ellenkező esetben az aktuális kódlap (CP_ACP) használatával lesz olvasható.
  • Most elkerüli az egydefiníciós szabályokkal (ODR) kapcsolatos problémákat az MC által létrehozott C/C++ ETW-segédekben, amelyeket ütköző konfigurációs makrók okoznak (például ha két ,cpp fájl ütköző definíciókkal rendelkező MCGEN_EVENTWRITETRANSFER ugyanabba a bináris fájlba van csatolva, az MC által létrehozott ETW-segítők mostantól tiszteletben tartják az egyes .cpp fájlokban lévő MCGEN_EVENTWRITETRANSFER definícióját ahelyett, hogy önkényesen kiválasztanák az egyiket vagy a másikat).

• A Windows Trace Preprocessor (tracewpp.exe) frissítései:

  • Támogatja a Unicode-bemeneti (.ini, .tpl és forráskód) fájlokat. Az UTF-8 vagy UTF-16 bájtos rendelési jellel (BOM) kezdődő bemeneti fájlok Unicode-ként lesznek felolvasva. A nem AJ-vel kezdődő bemeneti fájlok az aktuális kódlapon (CP_ACP) lesznek olvashatók. A visszamenőleges kompatibilitás érdekében, ha a -UnicodeIgnore parancssori paraméter van megadva, az UTF-16 BOM-val kezdődő fájlok üresként lesznek kezelve.
  • Támogatja a Unicode-kimeneti (.tmh) fájlokat. A kimeneti fájlok alapértelmezés szerint az aktuális kódlap (CP_ACP) használatával lesznek kódolva. Unicode-kimeneti fájlok létrehozásához használja a -cp:UTF-8 vagy -cp:UTF-16 parancssori paramétereket.
  • Viselkedésváltozás: a tracewpp mostantól az összes bemeneti szöveget Unicode-ra konvertálja, Unicode-beli feldolgozást végez, és a kimeneti szöveget a megadott kimeneti kódolásra konvertálja. A tracewpp korábbi verziói elkerülték a Unicode-átalakításokat, és egy bájtos karakterkészletet feltételezve szövegfeldolgozást hajtottak végre. Ez viselkedésbeli változásokhoz vezethet olyan esetekben, amikor a bemeneti fájlok nem felelnek meg az aktuális kódlapnak. Azokban az esetekben, amikor ez probléma, fontolja meg a bemeneti fájlok UTF-8-ra (BOM-val) való konvertálását, és/vagy használja a -cp:UTF-8 parancssori paramétert a kódolás kétértelműségének elkerülése érdekében.

• A TraceLoggingProvider.h frissítései:

  • Elkerüli az ütköző konfigurációs makrók által okozott egydefiníciós szabály (ODR) problémákat (például ha két ,cpp fájl ütköző definíciójával rendelkező TLG_EVENT_WRITE_TRANSFER ugyanabba a bináris fájlba van csatolva, a TraceLoggingProvider.h segítői mostantól tiszteletben tartják az egyes .cpp fájlokban lévő TLG_EVENT_WRITE_TRANSFER definícióját ahelyett, hogy önkényesen kiválasztanák az egyiket vagy a másikat).
  • A C++ kódban a TraceLoggingWrite makró frissült, hogy a variadikus sablonokkal jobb kódmegosztást lehessen lehetővé tenni a hasonló események között.

• Az alkalmazások aláírása. A Device Guard-aláírás az Microsoft Store Vállalatoknak és az Oktatás területen elérhető Eszközőr szolgáltatás, amellyel a vállalatok garantálják, hogy minden alkalmazás megbízható forrásból származik. Tekintse meg a Device Guard-aláírás dokumentációját.

• Az SDK-fejlécek frissültek, hogy elhárítsuk a vs 2019 v16.6-os verzióban bevezetett szabványos C-előfeldolgozóval kapcsolatos hibákat az MSVC fordító cl.exe (/Zc:preprocessor) használatával.

• Javítva: "A GdiplusTypes.h nem fordítja le a NOMINMAX-tal". Lásd: Visual Studio Visszajelzés.

• Ha az /std:c11 vagy /std:c17 használatával épít, a következőt kapja:

  • C99 tgmath.h
  • C11 static_assert az assert.h fájlban
  • C11 stdalign.h
  • C11 stdnoreturn.h

• Az ARM64-et megcélzó Windows v11-hez készült Clang/LLVM nem kompatibilis a legújabb winnt.h-val

  • Áthidaló megoldásként használja az Windows 10 SDK (19041-es build) vagy a windowsos v10-es clang/LLVM korábbi verzióját ARM64-platformok megcélzásakor

• A DirectXMath (beleértve a jelen kiadás 3.16-os verzióját is) nem kompatibilis az ARM64-en futó Clang/LLVM rendszerrel.

  • Áthidaló megoldásként használja a DirectXMath legújabb verzióját, amely a NuGet, a vcpkg vagy a GitHub szolgáltatásból érhető el. Ezek a verziók tartalmazzák a szükséges gyorsjavításokat (3.16b verzió).
    • www.nuget.org/packages/directxmath
    • github.com/microsoft/vcpkg/tree/master/ports/directxmath
    • github.com/microsoft/DirectXMath

• Néhány fejlécfájl esete módosult, hogy normalizálja őket a kis- és nagybetűkre érzékeny fájlrendszerekhez:

  • Az OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h és OleCtl.h mind kisbetűsek voltak.
  • Windows-buildekhez készült Clang/LLVM esetén, ha a régebbi verziót és a legújabb Windows 10 SDK-t is támogatja figyelmeztetések nélkül, adja hozzá -Wno-nonportable-system-include-path a parancssori felülethez, vagy a következő #pragma a forrásban:

  #ifdef __clang__

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

  #endif

Ez a kiadás a következő fájlokat tartalmazza. Ha ezeket a problémákat tapasztalja, javasoljuk, hogy a lehető leghamarabb frissítse az SDK verzióját, hogy elkerülje őket:

• Kiszámíthatatlan és nehezen diagnosztizálható összeomlások megoldása az esernyőtárak és a natív operációsrendszer-kódtárak (például a onecoreuap.lib és a kernel32.lib) összekapcsolásakor
• Megoldódott a probléma, amely megakadályozta az AppVerifier működését
• Kijavítottuk azt a hibát, amely miatt a WACK meghiúsult a következővel: "A feladat nem tudta engedélyezni a HighVersionLie-t"