Windows SDK

Actualización de mantenimiento 10.0.22621.2428.

Actualización 10.0.22621.1778. Entre las características resaltadas se incluyen:

• Las API windowTabManager permiten a las aplicaciones con interfaces con pestañas proporcionar información sobre las pestañas abiertas al shell de Windows.
• Novedades a las API de HumanPresence para mejorar la facilidad de uso y agregar nuevas configuraciones para los sensores que admiten funcionalidades de presencia humana.
• Las API de RemoteDesktop permiten a las aplicaciones cambiar entre un escritorio remoto y local.

• Actualización de mantenimiento 10.0.22621.755. Incluye compatibilidad con ARM64 para la versión de VS 17.4.

• Se ha quitado api-ms-win-net-isolation-l1-1-0.lib. Las aplicaciones que se vinculaban con api-ms-win-net-isolation-l1-1-0.lib pueden cambiar a OneCoreUAP.lib como reemplazo.

• Se ha quitado irprops.lib. Las aplicaciones que se vinculaban con irprops.lib pueden cambiar a bthprops.lib como reemplazo desplegable.

• Movió ENUM tagServerSelection de wuapicommon.h a wupai.h y quitó el encabezado. Si desea usar la etiqueta ENUMServerSelection, deberá incluir wuapi.h o wuapi.idl.

• El paquete de API de WinRT de Windows 10 le permite agregar la compatibilidad con las API de Windows Runtime más recientes a las bibliotecas y aplicaciones de .NET Framework 4.5+ y .NET Core 3.0+. Para acceder al paquete de API de WinRT de Windows 10, consulte el paquete nuGet Microsoft.Windows.SDK.Contracts.

• La familia de funciones printf ahora se ajusta a las reglas de redondeo IEEE 754 al imprimir números de punto flotante que se pueden representar exactamente y respetará el modo de redondeo solicitado a través de llamadas a fesetround. El comportamiento heredado está disponible al vincular con legacy_stdio_float_rounding.obj.

• Kit para la certificación de aplicaciones de Windows. Se agregaron varias API nuevas a la lista Api admitidas en el Kit de certificación de aplicaciones y la Tienda Windows. Si hay API en la lista admitida que aparecen atenuadas o deshabilitadas en Visual Studio, puede realizar un pequeño cambio en el archivo de origen para acceder a ellas. Para más información, consulte este problema conocido. Busque más actualizaciones para las pruebas.

• Actualizaciones del compilador de mensajes (mc.exe):

  • Ahora detecta la marca de orden de bytes Unicode (BOM) en los archivos .mc. Si el archivo .mc comienza con una BOM UTF-8, se leerá como un archivo UTF-8. De lo contrario, si comienza con una BOM UTF-16LE, se leerá como un archivo UTF-16LE. Si se especificó el parámetro -u, se leerá como un archivo UTF-16LE. De lo contrario, se leerá con la página de códigos actual (CP_ACP).
  • Ahora evita problemas de una regla de definición (ODR) en asistentes ETW de C/C++ generados por MC generadas por macros de configuración en conflicto (por ejemplo, cuando dos archivos .cpp con definiciones en conflicto de MCGEN_EVENTWRITETRANSFER están vinculados al mismo binario, los asistentes ETW generados por MC ahora respetarán la definición de MCGEN_EVENTWRITETRANSFER en cada archivo .cpp en lugar de seleccionar arbitrariamente uno u otro).

• Actualizaciones del preprocesador de seguimiento de Windows (tracewpp.exe):

  • Admite archivos de entrada Unicode (.ini, .tpl y código fuente). Los archivos de entrada a partir de una marca de orden de bytes (BOM) UTF-8 o UTF-16 se leerán como Unicode. Los archivos de entrada que no comienzan con una lista de materiales se leerán mediante la página de códigos actual (CP_ACP). Por motivos de compatibilidad con versiones anteriores, si se especifica el parámetro de línea de comandos -UnicodeIgnore, los archivos que comienzan por una BOM UTF-16 se tratarán como vacíos.
  • Admite archivos de salida Unicode (.tmh). De forma predeterminada, los archivos de salida se codificarán mediante la página de códigos actual (CP_ACP). Use parámetros de línea de comandos -cp:UTF-8 o -cp:UTF-16 para generar archivos de salida Unicode.
  • Cambio de comportamiento: tracewpp ahora convierte todo el texto de entrada en Unicode, realiza el procesamiento en Unicode y convierte el texto de salida en la codificación de salida especificada. Las versiones anteriores de tracewpp evitaron conversiones Unicode y realizaron el procesamiento de texto suponiendo un juego de caracteres de un solo byte. Esto puede provocar cambios de comportamiento en los casos en los que los archivos de entrada no se ajustan a la página de códigos actual. En los casos en los que se trata de un problema, considere la posibilidad de convertir los archivos de entrada en UTF-8 (con BOM) o usar el parámetro de línea de comandos -cp:UTF-8 para evitar la ambigüedad de codificación.

• Actualizaciones de TraceLoggingProvider.h:

  • Evita los problemas de una regla de definición (ODR) causados por macros de configuración en conflicto (por ejemplo, cuando dos archivos .cpp con definiciones en conflicto de TLG_EVENT_WRITE_TRANSFER están vinculados al mismo binario, los asistentes TraceLoggingProvider.h respetarán ahora la definición de TLG_EVENT_WRITE_TRANSFER en cada archivo .cpp en lugar de elegir arbitrariamente una u otra).
  • En el código de C++, la macro TraceLoggingWrite se ha actualizado para permitir un mejor uso compartido de código entre eventos similares mediante plantillas variádicas.

• Firma de las aplicaciones. La firma de Device Guard es una característica de Device Guard que está disponible en Microsoft Store para Empresas y Educación, lo que permite a las empresas garantizar que todas las aplicaciones proceden de un origen de confianza. Consulte la documentación sobre la firma de Device Guard.

• Los encabezados del SDK se han actualizado para solucionar errores al compilar mediante el preprocesador de C conforme a estándar en el compilador de MSVC cl.exe (/Zc:preprocessor, introducido en VS 2019 v16.6).

• Corregido: "GdiplusTypes.h no se compila con NOMINMAX". Consulte Comentarios de Visual Studio.

• Al compilar con /std:c11 o /std:c17, ahora obtendrá:

  • C99 tgmath.h
  • C11 static_assert en assert.h
  • C11 stdalign.h
  • C11 stdnoreturn.h

• Clang/LLVM para Windows v11 que tiene como destino ARM64 no es compatible con la versión más reciente de winnt.h

  • Como solución alternativa, use la versión anterior del SDK de Windows 10 (compilación 19041) o clang/LLVM para Windows v10 al tener como destino plataformas ARM64.

• DirectXMath (incluida la versión 3.16 de esta versión) no es compatible con Clang/LLVM para Windows en ARM64.

  • Como solución alternativa, use la versión más reciente de DirectXMath, disponible en NuGet, vcpkg o GitHub. Estas versiones incluyen las correcciones de acceso rápido necesarias (versión 3.16b).
    • www.nuget.org/packages/directxmath
    • github.com/microsoft/vcpkg/tree/master/ports/directxmath
    • github.com/microsoft/DirectXMath

• Se cambiaron las mayúsculas y minúsculas de algunos archivos de encabezado para normalizarlos para sistemas de archivos que distinguen mayúsculas de minúsculas:

  • OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h y OleCtl.h se hicieron minúsculas.
  • Para las compilaciones de Clang/LLVM para Windows, para admitir tanto la versión anterior como el SDK de Windows 10 más reciente sin advertencias, agregue -Wno-nonportable-system-include-path a la CLI o los siguientes #pragma en el origen:

  #ifdef __clang__

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

  #endif

Esta versión contiene los siguientes archivos. Si encuentra estos problemas, se recomienda actualizar la versión del SDK lo antes posible para evitarlos:

• Se resolvieron bloqueos imprevisibles y difíciles de diagnosticar al vincular bibliotecas paraguas y bibliotecas del sistema operativo nativas (por ejemplo, onecoreuap.lib y kernel32.lib).
• Problema resuelto que impedía que AppVerifier funcionara
• Se ha resuelto el problema que provocaba un error de WACK con "Task failed to enable HighVersionLie" (Error de tarea al habilitar HighVersionLie).