Windows SDK

Windows SDK (10.0.22000) para Windows 11 proporciona los encabezados, las bibliotecas, los metadatos y las herramientas más recientes para crear aplicaciones Windows. Usa este SDK para crear aplicaciones para la Plataforma universal de Windows (UWP) y Win32 para Windows 11 y versiones anteriores de Windows.

Introducción

Puedes obtener Windows SDK de dos formas: instalarlo desde esta página seleccionando el vínculo de descarga, o bien seleccionando “Windows 11 SDK (10.0.22000)” en los componentes opcionales del instalador de Visual Studio 2019.

Antes de instalar este SDK:

  1. revisa todos los requisitos del sistema.
  2. Sal de Visual Studio antes de que empiece la instalación.
  3. Revisa las notas de la versión y los problemas conocidos.

Requisitos del sistema

Windows SDK tiene los siguientes requisitos mínimos:

Sistemas operativos compatibles

  • Desarrollo de aplicaciones para la Plataforma universal de Windows (UWP)
    • Windows 10, versión 1507 o posterior: Home, Professional, Education y Enterprise (no se admiten LTSB y S)
    • Windows Server 2019, Windows Server 2016 y Windows Server 2012 R2 (solo la línea de comandos)
  • Desarrollo de aplicaciones para Win32
    • Windows 10, versión 1507, o superior
    • Windows Server 2019, Windows Server 2016 y Windows Server 2012 R2 (solo la 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 disco duro

Requisitos adicionales de SDK

La instalación en Windows 8.1 y en sistemas operativos anteriores requiere KB2999226. 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.

Novedades

Windows SDK para Windows 11 te permite actualizar tus aplicaciones para la versión más reciente del sistema operativo Windows. Más información sobre las nuevas características de Windows 11.

Para conocer las nuevas API que incorpora Windows 11, consulta Novedades de Windows 11 para desarrolladores.

Se han recompilado los archivos binarios del propio sistema operativo Windows 11 en ARM con ARM64EC, para que cualquier código del sistema cargado por aplicaciones x64 se ejecute a una velocidad nativa. Aprovecha ARM64EC para cambiar gradualmente tus aplicaciones con el fin de que se ejecuten con una velocidad nativa en ARM, incluso si tienen dependencias o complementos que aún no sean compatibles con ARM. Lee el anuncio.

Muestras

Hay ejemplos de aplicaciones Windows disponibles en GitHub. Puede examinar el código en GitHub, clonar una copia personal del repositorio desde Git o descargar un archivo comprimido de todas las muestras. 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, incluidos los detalles de las actualizaciones, pueden encontrarse en la página de archivo.

Activación de las API

Cuando uses API nuevas, considera la posibilidad de escribir la aplicación para que sea adaptable con el fin de que se ejecute correctamente en el mayor número posible de dispositivos Windows. Una aplicación adaptable "activa" las características nuevas cuando el dispositivo y la versión de Windows las admiten. En caso contrario, ofrece solo la funcionalidad disponible en la versión de la plataforma detectada. Para los detalles de implementación, consulte el artículo sobre el código adaptativo para versiones.

Notas de la versión y problemas conocidos

Windows 10 SDK, versión 2104

  • Se ha quitado api-ms-win-net-isolation-l1-1-0.lib. Las aplicaciones vinculadas con api-ms-win-net-isolation-l1-1-0.lib pueden cambiar a OneCoreUAP.lib como reemplazo.
  • Se ha quitado irprops.lib. Las aplicaciones vinculadas con irprops.lib pueden cambiar a bthprops.lib como reemplazo inmediato.
  • Se ha movido ENUM tagServerSelection de wuapicommon.h a wupai.h y se ha quitado el encabezado. Si desea usar ENUM tagServerSelection, deberá incluir wuapi.h o wuapi.idl.
  • El paquete de API de WinRT en Windows 10 le permite agregar compatibilidad para las API de Windows Runtime más recientes a sus aplicaciones y bibliotecas de .NET Framework 4.5+ y .NET Core 3.0+. Para acceder al paquete de API de WinRT en Windows 10, consulte el paquete NuGet Microsoft.Windows.SDK.Contracts.
  • Ahora la familia de funciones printf cumple las reglas de redondeo IEEE 754 al imprimir números de punto flotante de representación exacta y respeta el modo de redondeo solicitado mediante llamadas a fesetround. El comportamiento heredado está disponible al crear un vínculo con legacy_stdio_float_rounding.obj.
  • Kit para la certificación de aplicaciones en Windows. Se han agregado varias API nuevas a la lista de API compatibles en el Kit para la certificación de aplicaciones y en Microsoft Store. Si hay API en la lista compatible atenuadas o deshabilitadas en Visual Studio, puede realizar un pequeño cambio en el archivo de origen para tener acceso a ellas. Para obtener más detalles, consulte este problema conocido. Busca más actualizaciones de 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 empieza con un UTF-8 BOM, se leerá como archivo UTF-8. De lo contrario, si empieza con un UTF-16LE BOM, se leerá como archivo UTF-16LE. Si se ha especificado el parámetro -u, se leerá como archivo UTF-16LE. De lo contrario, se leerá mediante la página de códigos actual (CP_ACP).
    • Ahora evita problemas relativos a una regla de definición (ODR) en las aplicaciones auxiliares de ETW de C/C++ generadas por MC 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, las aplicaciones auxiliares de ETW generadas por MC ahora respetarán la definición de MCGEN_EVENTWRITETRANSFER en cada archivo .cpp en lugar de seleccionar arbitrariamente uno o el 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 que empiezan con una marca de orden de bytes (BOM) UTF-8 o UTF-16 se leerán como Unicode. Los archivos de entrada que no empiezan con un BOM se leerán mediante la página de códigos actual (CP_ACP). En cuanto a la compatibilidad con versiones anteriores, si se especifica el parámetro de línea de comandos -UnicodeIgnore, los archivos que empiezan por un 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 los 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 evitaban conversiones Unicode y realizaban el procesamiento de texto suponiendo un grupo de caracteres de byte único. Esto puede provocar cambios de comportamiento en 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 ambigüedad de codificación.
  • Actualizaciones de TraceLoggingProvider.h:
    • Evita problemas relativos a 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 archivo 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 o el otro).
    • En el código C++, la macro TraceLoggingWrite se ha actualizado para habilitar un mejor uso compartido de código entre eventos similares mediante plantillas variádicas.
  • Firma de las aplicaciones. Firma de Device Guard es una característica de Device Guard disponible en Microsoft Store para Empresas y Educación 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 aplicaciones con el preprocesador de C conforme con la normativa en el archivo cl.exe del compilador MSVC (/Zc:preprocessor, incluido en VS 2019 v16.6).
  • Corregido: “GdiplusTypes.h no se compila con NOMINMAX”. Lee los comentarios del equipo de Visual Studio.
  • Al compilar aplicaciones con /std:c11 o /std:c17, ahora se obtiene lo siguiente:
    • C99 tgmath.h
    • C11 static_assert in assert.h
    • C11 stdalign.h
    • C11 stdnoreturn.h
  • Clang/LLVM para Windows v11 con ARM64 como destino no es compatible con la versión más reciente de winnt.h.
    • Como solución alternativa, usa la versión anterior de Windows 10 SDK (compilación 19041) o clang/LLVM para Windows v10 cuando la plataforma de destino sea ARM64.
  • DirectXMath (incluida la versión 3.16 de este lanzamiento) no es compatible con Clang/LLVM para Windows en ARM64.
  • Se han cambiado las mayúsculas y minúsculas de algunos archivos de encabezado con el fin de normalizarlos para los 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 han cambiado a minúsculas.
    • En el caso de las compilaciones de Clang/LLVM para Windows, para admitir la versión anterior y la más reciente de Windows 10 SDK sin advertencias, agrega “-Wno-nonportable-system-include-path” a la CLI, o el siguiente #pragma en el código fuente:

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

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

    Esta versión contiene los siguientes archivos. Si experimentas estos problemas, se recomienda que actualices tu versión del SDK tan pronto como sea posible para evitarlos:
  • Se han resuelto los bloqueos impredecibles y difíciles de diagnosticar que se producían al vincular bibliotecas paraguas y bibliotecas nativas del sistema operativo (por ejemplo, onecoreuap.lib y kernel32.lib).
  • Se ha resuelto el problema que impedía el funcionamiento de AppVerifier.
  • Se ha resuelto el problema que causaba el error de WACK de que la tarea no pudo habilitar HighVersionLie.

Proporcionar comentarios

Para ver los problemas conocidos, consulta la sección de Q&A sobre winapi-sdk.

Si quieres solicitar nuevas características para desarrolladores, puedes hacerlo a través de la aplicación Centro de opiniones en la categoría de API/plataforma para desarrolladores.

Más recursos

Descargas y herramientas

Obtenga las ediciones más recientes de Visual Studio y las herramientas de desarrollo de Windows 10.

MÁS INFORMACIÓN

Archivo de SDK

Busca versiones anteriores de Window SDK y otras herramientas.

VER ARCHIVO

Blog de Windows

Siga en contacto con los pilotos de SDK más recientes suscribiéndose a nuestro blog.

RECIBIR NOTICIAS SOBRE PILOTOS DE SDK

Hoja informativa del ciclo de vida de Windows

Encuentre las fechas clave para las actualizaciones de versiones de Windows y la finalización del soporte.

VER LA HOJA INFORMATIVA