Windows SDK

Windows SDK (10.0.22621) para Windows 11, versión 22H2 proporciona los encabezados, bibliotecas, metadatos y herramientas más recientes para compilar aplicaciones Windows. Usa este SDK para compilar aplicaciones Plataforma universal de Windows (UWP) y Win32 para Windows 11, versión 22H2 y versiones anteriores de Windows.

Sugerencia

SDK para aplicaciones de Windows
El SDK de Aplicaciones para Windows proporciona un conjunto unificado de API y herramientas que se desacoplan del sistema operativo y se publican para desarrolladores a través de paquetes NuGet. Estas API y herramientas se pueden usar de forma coherente mediante cualquier aplicación de escritorio en Windows 11 y nivel inferior para Windows 10, versión 1809.

Introducción

Puede obtener windows SDK de dos maneras: instalarlo desde esta página seleccionando el vínculo de descarga o seleccionando "sdk de Windows 11 (10.0.22621.0)" en los componentes opcionales del instalador de Visual Studio 2022. Antes de instalar este SDK:

Última actualización: 4 de octubre de 2021

Requisitos del sistema

Windows SDK tiene los siguientes requisitos mínimos:

Sistemas operativos admitidos

  • Windows 10 versión 1507 o posterior: Home, Professional, Education y Enterprise (LTSB y S no se admiten para UWP)
  • Windows Server 2022, Windows Server 2019, Windows Server 2016 y Windows Server 2012 R2 (solo línea de comandos)
  • Windows 8.1
  • Windows 7 SP1

(No todas las herramientas son compatibles con los sistemas operativos anteriores)

Requisitos de hardware

  • Procesador de 1.6 GHz o más rápido
  • 1 GB de RAM
  • 4 GB de espacio disponible en el disco duro

Requisitos adicionales de SDK

La instalación en Windows 8.1 y sistemas operativos anteriores requiere una actualización para C Runtime universal en Windows. Para instalar a través de Windows Update, asegúrate de instalar las actualizaciones y los parches recomendados más recientes desde Microsoft Update antes de instalar el Windows SDK.

Ejemplos

Los ejemplos de aplicaciones de Windows ya están disponibles a través de GitHub. Puede examinar el código en GitHub, clonar una copia personal del repositorio desde Git o descargar un archivo comprimido de todos los ejemplos. Agradecemos los comentarios. No dudes en abrir una incidencia en el repositorio si tienes un problema o una pregunta. Estas muestras están diseñadas para ejecutarse en dispositivos de escritorio, móviles y futuros dispositivos que admitan la Plataforma universal de Windows (UWP).

Versiones anteriores de SDK

Los SDK y emuladores distribuidos anteriormente, incluyendo los detalles de las actualizaciones, pueden encontrarse en la página de archivo.

Activación de las API

Al usar nuevas API, considere la posibilidad de escribir la aplicación para que sea adaptable para que se ejecute correctamente en la matriz más amplia de dispositivos Windows. Una aplicación adaptable "se enciende" con nuevas características siempre que los dispositivos y la versión de Windows los admitan, pero de lo contrario solo ofrece la funcionalidad disponible en la versión de la plataforma detectada. Para obtener más información sobre la implementación, consulte el artículo Código adaptable de versión.

Notas de la versión y problemas conocidos

Windows SDK para Windows 11, versión 22H2
  • Actualización de mantenimiento 10.0.22621.755. Incluye compatibilidad con ARM64 para la versión de VS 17.4
SDK de Windows 10, versión 2104
  • 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 quitó irprops.lib. Las aplicaciones que se vinculaban con irprops.lib pueden cambiar a bthprops.lib como reemplazo de eliminación.

  • Se ha movido la etiqueta ENUMServerSelection de wuapicommon.h a wupai.h y se 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 permite agregar la compatibilidad más reciente con las API de Windows Runtime a las bibliotecas y aplicaciones de .NET Framework 4.5+ y .NET Core 3.0+. Para acceder al paquete nuget Windows 10 Api Pack de WinRT, 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 de 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 obtener más información, consulte este problema conocido. Encuentre más actualizaciones en las pruebas.

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

    • Ahora detecta la marca de orden de bytes (BOM) Unicode 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 los asistentes ETW generados por MC/C++ causados 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 compatibilidad con versiones anteriores, si se especifica el parámetro de línea de comandos -UnicodeIgnore, los archivos que comienzan con 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 esto es un problema, considere la posibilidad de convertir los archivos de entrada en UTF-8 (con BOM) o mediante el parámetro de línea de comandos -cp:UTF-8 para evitar la codificación de ambigüedad.
  • Actualizaciones de TraceLoggingProvider.h:

    • Evita 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 ahora respetarán la definición de TLG_EVENT_WRITE_TRANSFER en cada archivo .cpp en lugar de seleccionar arbitrariamente uno u otro).
    • 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 los 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á lo siguiente:

    • 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 dirigirse a plataformas ARM64.
  • DirectXMath (incluida la versión 3.16 de esta versión) no es compatible con Clang/LLVM para Windows en ARM64.

  • 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

Windows 10 SDK, versión 2004, actualización de mantenimiento (publicada el 12/16/2020)

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).

Más recursos