SDK do Windows

O SDK do Windows (10.0.22621) para Windows 11, versão 22H2 fornece os cabeçalhos, bibliotecas, metadados e ferramentas mais recentes para a criação de aplicativos Windows. Use esse SDK para criar aplicativos Plataforma Universal do Windows (UWP) e Win32 para Windows 11, versão 22H2 e versões de Windows anteriores.

Dica

SDK do Aplicativo do Windows
O SDK do Aplicativo Windows fornece um conjunto unificado de APIs e ferramentas que são dissociadas do sistema operacional e liberadas para desenvolvedores por meio de pacotes de NuGet. Essas APIs e ferramentas podem ser usadas de forma consistente por qualquer aplicativo da área de trabalho no Windows 11 e no nível inferior para Windows 10, versão 1809.

Introdução

Você pode obter o SDK Windows de duas maneiras: instalá-lo nesta página selecionando o link de download ou selecionando "Windows 11 SDK (10.0.22621.0)" nos componentes opcionais do Instalador Visual Studio 2022. Antes de instalar este SDK:

Última atualização: 4 de outubro de 2021

Requisitos do sistema

O SDK do Windows tem os seguintes requisitos mínimos do sistema:

Sistemas operacionais com suporte

  • Windows 10 versão 1507 ou superior: Home, Professional, Education e Enterprise (LTSB e S não têm suporte para UWP)
  • Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows Server 2012 R2 (somente linha de comando)
  • Windows 8.1
  • Windows 7 SP1

(Nem todas as ferramentas têm suporte em sistemas operacionais anteriores)

Requisitos de hardware

  • Processador de 1,6 GHz ou mais rápido
  • 1 GB de RAM
  • 4 GB de espaço em disco disponível

Requisitos adicionais do SDK

A instalação em sistemas operacionais Windows 8.1 e anteriores requer uma atualização para o Runtime Universal C em Windows. Para instalar por meio de Windows Update, instale as atualizações e patches mais recentes recomendados do Microsoft Update antes de instalar o SDK do Windows.

Exemplos

Windows exemplos de aplicativo agora estão disponíveis por meio de GitHub. Você pode navegar pelo código em GitHub, clonar uma cópia pessoal do repositório do Git ou baixar um arquivo compactado de todos os exemplos. Damos as boas-vindas aos comentários, portanto, fique à vontade para abrir um problema dentro do repositório se você tiver um problema ou pergunta. Esses exemplos foram projetados para serem executados em dispositivos de área de trabalho, móveis e futuros que dão suporte à UWP (Plataforma Universal do Windows).

Versões anteriores do SDK

SDKs e emuladores lançados anteriormente, incluindo detalhes da atualização, podem ser encontrados na página de arquivo morto.

Iluminação da API

Ao usar novas APIs, considere escrever seu aplicativo como adaptável para que ele seja executado corretamente na matriz mais ampla de dispositivos Windows. Um aplicativo adaptável "acende" com novos recursos em qualquer lugar onde os dispositivos e Windows versão dão suporte a eles, mas de outra forma oferece apenas a funcionalidade disponível na versão da plataforma detectada. Para obter detalhes da implementação, consulte o artigo de código adaptável de versão.

Notas de versão e problemas conhecidos

Windows 10 SDK, versão 2104
  • Removido api-ms-win-net-isolation-l1-1-0.lib. Os aplicativos que estavam vinculados ao api-ms-win-net-isolation-l1-1-0.lib podem alternar o OneCoreUAP.lib como substituto.

  • Removido irprops.lib. Os aplicativos que estavam vinculados ao irprops.lib podem alternar para bthprops.lib como uma substituição de drop-in.

  • Moveu eNUM tagServerSelection de wuapicommon.h para wupai.h e removeu o cabeçalho. Se você quiser usar a tagServerSelection ENUM, precisará incluir wuapi.h ou wuapi.idl.

  • O pacote de API do Windows 10 WinRT permite adicionar as APIs de Windows Runtime mais recentes às bibliotecas e aplicativos do .NET Framework 4.5+ e do .NET Core 3.0+. Para acessar o pacote de API do WinRT Windows 10, consulte o Microsoft.Windows. SDK. Contratos de pacote nuget.

  • A família de funções printf agora está em conformidade com as regras de arredondamento do IEEE 754 ao imprimir números de ponto flutuante exatamente representáveis e honrará o modo de arredondamento solicitado por meio de chamadas para fesetround. O comportamento herdado está disponível ao vincular com legacy_stdio_float_rounding.obj.

  • Windows Kit de Certificação de Aplicativos. Várias novas APIs foram adicionadas à lista de APIs com suporte no Kit de Certificação de Aplicativos e na Windows Store. Se houver APIs na lista com suporte que apareçam esmaeçadas ou desabilitadas em Visual Studio, você poderá fazer uma pequena alteração no arquivo de origem para acessá-las. Para obter mais detalhes, consulte este problema conhecido. Encontre mais atualizações para testes.

  • Atualizações do Compilador de Mensagens (mc.exe):

    • Agora detecta a marca de ordem de bytes Unicode (BOM) nos arquivos .mc. Se o arquivo .mc começar com um BOM UTF-8, ele será lido como um arquivo UTF-8. Caso contrário, se ele começar com um BOM UTF-16LE, ele será lido como um arquivo UTF-16LE. Se o parâmetro -u tiver sido especificado, ele será lido como um arquivo UTF-16LE. Caso contrário, ele será lido usando a página de código atual (CP_ACP).
    • Agora evita problemas de regra de definição única (ODR) em auxiliares de ETW C/C++ gerados por MC causados por macros de configuração conflitantes (por exemplo, quando dois arquivos .cpp com definições conflitantes de MCGEN_EVENTWRITETRANSFER estão vinculados ao mesmo binário, os auxiliares do ETW gerados por MC agora respeitarão a definição de MCGEN_EVENTWRITETRANSFER em cada arquivo .cpp em vez de escolher arbitrariamente um ou outro).
  • Atualizações do pré-processador de rastreamento de Windows (tracewpp.exe):

    • Dá suporte a arquivos de entrada Unicode (.ini, .tpl e código-fonte). Os arquivos de entrada que começam com uma MARCA DE ordem de bytes UTF-8 ou UTF-16 (BOM) serão lidos como Unicode. Arquivos de entrada que não começam com um BOM serão lidos usando a página de código atual (CP_ACP). Para compatibilidade com versões anteriores, se o parâmetro de linha de comando -UnicodeIgnore for especificado, os arquivos que começam com um BOM UTF-16 serão tratados como vazios.
    • Dá suporte a arquivos de saída Unicode (.tmh). Por padrão, os arquivos de saída serão codificados usando a página de código atual (CP_ACP). Use parâmetros de linha de comando -cp:UTF-8 ou -cp:UTF-16 para gerar arquivos de saída Unicode.
    • Alteração de comportamento: o tracewpp agora converte todo o texto de entrada em Unicode, executa o processamento no Unicode e converte o texto de saída na codificação de saída especificada. Versões anteriores do tracewpp evitaram conversões Unicode e executaram o processamento de texto assumindo um conjunto de caracteres de byte único. Isso pode levar a alterações de comportamento nos casos em que os arquivos de entrada não estão em conformidade com a página de código atual. Nos casos em que esse é um problema, considere converter os arquivos de entrada em UTF-8 (com BOM) e/ou usar o parâmetro de linha de comando -cp:UTF-8 para evitar a ambiguidade de codificação.
  • Atualizações de TraceLoggingProvider.h:

    • Evita problemas de ODR (regra de definição única) causados por macros de configuração conflitantes (por exemplo, quando dois arquivos .cpp com definições conflitantes de TLG_EVENT_WRITE_TRANSFER estão vinculados ao mesmo binário, os auxiliares TraceLoggingProvider.h agora respeitarão a definição de TLG_EVENT_WRITE_TRANSFER em cada arquivo .cpp em vez de escolher arbitrariamente um ou outro).
    • No código C++, a macro TraceLoggingWrite foi atualizada para habilitar um melhor compartilhamento de código entre eventos semelhantes usando modelos variadic.
  • Assinando seus aplicativos. A assinatura do Device Guard é um recurso do Device Guard que está disponível no Microsoft Store para Empresas e no Education, que permite que as empresas garantam que todos os aplicativos sejam provenientes de uma fonte confiável. Consulte a documentação sobre a Assinatura do Device Guard.

  • Os cabeçalhos do SDK foram atualizados para solucionar erros ao compilar usando o pré-processador C de conformidade padrão no compilador MSVC cl.exe (/Zc:preprocessor, introduzido no VS 2019 v16.6).

  • Corrigido: "GdiplusTypes.h não é compilado com NOMINMAX". Consulte Visual Studio Comentários.

  • Ao construir com /std:c11 ou /std:c17, agora você obtém:

    • C99 tgmath.h
    • C11 static_assert em assert.h
    • C11 stdalign.h
    • C11 stdnoreturn.h
  • Clang/LLVM para Windows v11 direcionando ARM64 não é compatível com o winnt.h mais recente

    • Como solução alternativa, use a versão anterior do SDK Windows 10 (build 19041) ou clang/LLVM para Windows v10 ao direcionar plataformas ARM64
  • O DirectXMath (incluindo a versão 3.16 nesta versão) não é compatível com Clang/LLVM para Windows no ARM64.

  • O caso de alguns arquivos de cabeçalho foram alterados para normalizá-los para sistemas de arquivos que diferenciam maiúsculas de minúsculas:

    • OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h e OleCtl.h foram todos feitos em minúsculas inferiores.
    • Para clang/LLVM para builds de Windows, para dar suporte à versão mais antiga e ao SDK de Windows 10 mais recente sem avisos, adicione -Wno-nonportable-system-include-path à CLI ou a seguinte #pragma na origem:

    #ifdef __clang__

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

    #endif

Windows 10 SDK, atualização de manutenção da versão 2004 (lançada em 16/12/2020)

Esta versão contém os seguintes arquivos. Se você encontrar esses problemas, recomendamos que você atualize sua versão do SDK o mais rápido possível para evitá-los:

  • Resolvido imprevisível e difícil de diagnosticar falhas ao vincular bibliotecas de guarda-chuva e bibliotecas nativas do sistema operacional (por exemplo, onecoreuap.lib e kernel32.lib)
  • Problema resolvido que impediu o AppVerifier de funcionar
  • Problema resolvido que fazia com que o WACK falhasse com "Falha na tarefa para habilitar o HighVersionLie"

Mais recursos