Windows SDK

O Windows SDK (10.0.22621) para Windows 11, Versão 22H2, fornece os cabeçalhos, bibliotecas, metadados e ferramentas mais recentes para criar aplicações do Windows. Utilize este SDK para criar aplicações Plataforma Universal do Windows (UWP) e Win32 para Windows 11, Versão 22H2 e versões anteriores do Windows.

Dica

SDK de aplicações Windows
O SDK de aplicações Windows fornece um conjunto unificado de APIs e ferramentas que são desacopladas do SO e lançadas para programadores através de pacotes NuGet. Estas APIs e ferramentas podem ser utilizadas de forma consistente por qualquer aplicação de ambiente de trabalho no Windows 11 e de nível inferior para Windows 10, versão 1809.

Introdução

Pode obter o SDK do Windows de duas formas: instalá-lo a partir desta página ao selecionar a ligação de transferência ou ao selecionar "Windows 11 SDK (10.0.22621.0)" nos componentes opcionais do Instalador do Visual Studio 2022. Antes de instalar este SDK:

Última atualização: maio de 2023

Requisitos de sistema

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

Sistemas operativos suportados

  • Windows 10 versão 1507 ou superior: Home, Professional, Education e Enterprise (LTSB e S não são suportados para UWP)
  • Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows Server 2012 R2 (Apenas linha de comandos)
  • Windows 8.1
  • Windows 7 SP1

(Nem todas as ferramentas são suportadas em sistemas operativos anteriores)

Requisitos de hardware

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

Requisitos adicionais do SDK

A instalação no Windows 8.1 e em sistemas operativos anteriores requer uma Atualização do Universal C Runtime no Windows. Para instalar através de Windows Update, certifique-se de que instala as atualizações e patches recomendados mais recentes do Microsoft Update antes de instalar o Windows SDK.

Amostras

Os exemplos de aplicações do Windows estão agora disponíveis através do GitHub. Pode procurar o código no GitHub, clonar uma cópia pessoal do repositório a partir do Git ou transferir um arquivo zipado de todos os exemplos. Agradecemos o seu feedback, pelo que pode abrir um problema no repositório se tiver um problema ou pergunta. Estes exemplos foram concebidos para serem executados em dispositivos de secretária, dispositivos móveis e futuros que suportam a Plataforma Universal do Windows (UWP).

Versões anteriores do SDK

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

API Light Up

Quando utilizar novas APIs, considere escrever a sua aplicação como adaptável para que seja executada corretamente na maior matriz de dispositivos Windows. Uma aplicação adaptável "acende-se" com novas funcionalidades onde quer que os dispositivos e a versão do Windows as suportem, mas, caso contrário, oferece apenas a funcionalidade disponível na versão de plataforma detetada. Para obter detalhes sobre a implementação, veja o artigo Código adaptável da versão.

Notas de versão e problemas conhecidos

Windows 11, Versão 22H2, Compilação 10.0.22621.1778

Atualização 10.0.22621.1778. As funcionalidades realçadas incluem:

  • As APIs do WindowsTabManager permitem que as aplicações com interfaces com separadores forneçam informações sobre separadores abertos para a shell do Windows.
  • Atualizações às APIs HumanPresence para melhorar a facilidade de utilização e adicionar novas definições para sensores que suportam capacidades de presença humana.
  • As APIs RemoteDesktop permitem que as aplicações alternem entre um ambiente de trabalho remoto e local.
Windows SDK para Windows 11, versão 22H2
  • Atualização de manutenção 10.0.22621.755. Inclui suporte arm64 para o lançamento do VS 17.4
Windows 10 SDK, Versão 2104
  • Api-ms-win-net-isolation-l1-1-0.lib removido. As aplicações que estavam ligadas a api-ms-win-net-isolation-l1-1-0.lib podem mudar o oneCoreUAP.lib como substituto.

  • Irprops.lib removido. As aplicações que estavam ligadas a irprops.lib podem mudar para bthprops.lib como substituto.

  • Moveu eNUM tagServerSelection de wuapicommon.h para wupai.h e removeu o cabeçalho. Se quiser utilizar o tagServerSelection de ENUM, terá de incluir wuapi.h ou wuapi.idl.

  • O Windows 10 WinRT API Pack permite-lhe adicionar o suporte de APIs de Windows Runtime mais recente às bibliotecas e aplicações do .NET Framework 4.5+ e .NET Core 3.0+ Para aceder ao Windows 10 Pacote de API WinRT, consulte o pacote nuget Microsoft.Windows.SDK.Contracts.

  • A família de funções printf está agora em conformidade com as regras de arredondamento IEEE 754 ao imprimir números de vírgula flutuante exatamente representáveis e respeitará o modo de arredondamento pedido através de chamadas para fesetround. O comportamento legado está disponível ao ligar ao legacy_stdio_float_rounding.obj.

  • Kit de Certificação de Aplicações do Windows. Foram adicionadas várias APIs novas à lista de APIs Suportadas no App Certification Kit e na Loja Windows. Se existirem APIs na lista suportadas que aparecem a cinzento ou desativadas no Visual Studio, pode fazer uma pequena alteração ao ficheiro de origem para aceder às mesmas. Para obter mais detalhes, veja este problema conhecido. Encontre mais atualizações para os testes.

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

    • Agora, deteta a marca de ordem de bytes Unicode (BOM) nos ficheiros .mc. Se o ficheiro .mc começar com um UTF-8 BOM, será lido como um ficheiro UTF-8. Caso contrário, se começar com um UTF-16LE BOM, será lido como um ficheiro UTF-16LE. Se o parâmetro -u tiver sido especificado, será lido como um ficheiro UTF-16LE. Caso contrário, será lido com a página de código atual (CP_ACP).
    • Agora, evita problemas de uma regra de definição (ODR) nos programas auxiliares de C/C++ ETW gerados pelo MC causados por macros de configuração em conflito (por exemplo, quando dois ficheiros .cpp com definições de MCGEN_EVENTWRITETRANSFER em conflito estão ligados ao mesmo binário, os programadores etw gerados pelo MC irão agora respeitar a definição de MCGEN_EVENTWRITETRANSFER em cada ficheiro .cpp em vez de escolherem arbitrariamente um ou outro ficheiro).
  • Atualizações do Pré-processamento de Rastreio do Windows (tracewpp.exe):

    • Suporta ficheiros de entrada Unicode (.ini, .tpl e código fonte). Os ficheiros de entrada que comecem com uma marca de ordem de bytes UTF-8 ou UTF-16 (BOM) serão lidos como Unicode. Os ficheiros de entrada que não comecem com um BOM serão lidos com a página de código atual (CP_ACP). Para retrocompatibilidade, se o parâmetro da linha de comandos -UnicodeIgnore for especificado, os ficheiros que comecem com um UTF-16 BOM serão tratados como vazios.
    • Suporta ficheiros de saída Unicode (.tmh). Por predefinição, os ficheiros de saída serão codificados com a página de código atual (CP_ACP). Utilize os parâmetros da linha de comandos -cp:UTF-8 ou -cp:UTF-16 para gerar ficheiros de saída Unicode.
    • Alteração de comportamento: tracewpp converte agora todo o texto de entrada em Unicode, efetua o processamento no Unicode e converte o texto de saída para a codificação de saída especificada. Versões anteriores do tracewpp evitaram conversões Unicode e realizaram o processamento de texto assumindo um conjunto de carateres de byte único. Isto pode levar a alterações de comportamento nos casos em que os ficheiros de entrada não estão em conformidade com a página de código atual. Nos casos em que se trata de um problema, considere converter os ficheiros de entrada para UTF-8 (com BOM) e/ou utilizar o parâmetro da linha de comandos -cp:UTF-8 para evitar ambiguidade na codificação.
  • TraceLoggingProvider.h atualizações:

    • Evita problemas de uma regra de definição (ODR) causados por macros de configuração em conflito (por exemplo, quando dois ficheiros .cpp com definições em conflito de TLG_EVENT_WRITE_TRANSFER estão ligados ao mesmo binário, os programadores TraceLoggingProvider.h respeitarão agora a definição de TLG_EVENT_WRITE_TRANSFER em cada ficheiro .cpp em vez de escolher arbitrariamente um ou outro).
    • No código C++, a macro TraceLoggingWrite foi atualizada para permitir uma melhor partilha de código entre eventos semelhantes através de modelos variados.
  • Assinar as suas aplicações. A assinatura do Device Guard é uma funcionalidade do Device Guard que está disponível no Microsoft Store para Empresas e Educação, que permite às empresas garantir que todas as aplicações provêm de uma origem fidedigna. Veja a documentação sobre a Assinatura do Device Guard.

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

  • Corrigido: "GdiplusTypes.h não compila com NOMINMAX". Veja Comentários do Visual Studio.

  • Ao criar com /std:c11 ou /std:c17, obtém agora:

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

    • Como solução, utilize a versão anterior do SDK do Windows 10 (compilação 19041) ou clang/LLVM para Windows v10 ao direcionar as 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 ficheiros de cabeçalho foi alterado, para os normalizar para sistemas de ficheiros sensíveis a maiúsculas e minúsculas:

    • OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h e OleCtl.h foram todos feitos em minúsculas.
    • Para compilações Clang/LLVM para Windows, para suportar a versão mais antiga e o 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 (disponibilizada a 16/12/2020)

Esta versão contém os seguintes ficheiros. Se encontrar estes problemas, recomendamos que atualize a sua versão do SDK o mais rapidamente possível para os evitar:

  • Resolvemos falhas imprevisíveis e difíceis de diagnosticar ao ligar bibliotecas de guarda-chuvas e bibliotecas nativas do SO (por exemplo, onecoreuap.lib e kernel32.lib)
  • Foi resolvido um problema que impedia o AppVerifier de funcionar
  • Foi resolvido um problema que fazia com que a WACK falhasse com "A tarefa não conseguiu ativar o HighVersionLie"

Mais recursos