Windows SDK

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

Introdução

Pode obter o Windows SDK 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.22000)" nos componentes opcionais do Instalador do Visual Studio 2019.

Antes de instalar este SDK:

  1. Reveja todos os requisitos de sistema
  2. Saia do Visual Studio antes da instalação.
  3. Reveja as Notas de versão e problemas conhecidos.

Requisitos de sistema

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

Sistemas operativos suportados

  • Desenvolvimento de aplicações da Plataforma Universal do Windows (UWP)
    • Windows 10 versão 1507 ou superior: Home, Professional, Education e Enterprise (LTSB e S não são suportados)
    • Windows Server 2019, Windows Server 2016 e Windows Server 2012 R2 (Linha de comandos apenas)
  • Desenvolvimento de aplicações Win32
    • Windows 10 versão 1507 ou superior
    • Windows Server 2019, Windows Server 2016 e Windows Server 2012 R2 (Linha de comandos apenas)
    • Windows 8.1
    • Windows 7 SP1

(Nem todas as ferramentas são suportadas por 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 de SDK adicionais

A instalação no Windows 8.1 e em sistemas operativos anteriores necessita do KB2999226. Para instalar através do Windows Update, certifique-se de que instala as correções e as atualizações mais recentes recomendadas a partir do Microsoft Update antes de instalar o Windows SDK.

Novidades

O Windows SDK para Windows 11 permite-lhe atualizar as suas aplicações para a versão mais recente do SO Windows. Saiba mais sobre as novas funcionalidades do Windows 11.

Para ver as novas APIs introduzidas com o Windows 11, veja: Novas APIs na compilação 22000 do Windows 11.

Recompile os binários do próprio sistema operativo Windows 11 no ARM com o ARM64EC para que qualquer código do sistema carregado por aplicações x64 seja executado com velocidade nativa. Tire partido do ARM64EC para fazer a transição incremental da sua aplicação para ser executada com velocidade nativa no ARM, mesmo se tiver dependências ou plug-ins que ainda não suportam o ARM. Leia o anúncio.

Exemplos

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 do Git ou transferir um arquivo zipado de todos os exemplos. Agradecemos os seus comentários. Assim sendo, se tiver um problema ou questão, fique à vontade para os expor no repositório. Estes exemplos foram concebidos para serem executados em ambiente de trabalho, móvel e futuros dispositivos que suportam a Plataforma Universal do Windows (UWP).

Versões anteriores do SDK

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

API Light Up

Quando utilizar as novas APIs, considere escrever a sua aplicação de modo a ser adaptável para permitir a sua correta execução no maior número possível de dispositivos Windows. Uma aplicação adaptável "põe em destaque" novas funcionalidades sempre que os dispositivos e a versão do Windows as suportem, mas, por outro lado, oferece apenas a funcionalidade disponível na versão da plataforma detetada. Para obter os detalhes de implementação, veja o Artigo do código adaptativo da versão.

Notas de versão e problemas conhecidos

Windows 10 SDK, Versão 2104

  • api-ms-win-net-isolation-l1-1-0.lib removido. As aplicações que estavam associadas a api-ms-win-net-isolation-l1-1-0.lib podem mudar para OneCoreUAP.lib como substituição.
  • irprops.lib removido. As aplicações que estavam associadas a irprops.lib podem mudar para bthprops.lib como substituição de drop-in.
  • Movemos a ENUM tagServerSelection de wuapicommon.h para wupai.h e removemos o cabeçalho. Se quiser utilizar ENUM tagServerSelection, terá de incluir wuapi.h ou wuapi.idl.
  • O Pacote de API WinRT do Windows 10 permite-lhe adicionar o mais recente suporte das APIs do Windows Runtime às suas bibliotecas e aplicações do .NET Framework 4.5+ e .NET Core 3.0+. Para aceder ao Pacote de API WinRT do Windows 10, veja o Pacote NuGet Microsoft.Windows.SDK.Contracts.
  • A família de funções printf já está em conformidade com as regras de arredondamento IEEE 754 ao imprimir números de vírgula flutuante exatamente representáveis e irá cumprir o modo de arredondamento pedido através de chamadas para fesetround. O comportamento legado está disponível quando se liga a legacy_stdio_float_rounding.obj.
  • Windows App Certification Kit. Adicionámos várias novas APIs à lista de APIs Suportadas no App Certification Kit e na Windows Store. Se houver APIs na lista suportada apresentadas a cinzento ou desativadas no Visual Studio, pode fazer uma pequena alteração ao ficheiro de origem para aceder às mesmas. Para mais detalhes, veja este problema conhecido. Encontre mais atualizações a testes.
  • Atualizações do Compilador de Mensagens (mc.exe):
    • Deteta agora a marca de ordem de bytes (BOM) Unicode em ficheiros .mc. Se o ficheiro .mc começar com um BOM UTF-8, será lido como um ficheiro UTF-8. Caso contrário, se começar com um BOM UTF-16LE, será lido como um ficheiro UTF-16LE. Se o parâmetro -u estiver especificado, será lido como um ficheiro UTF-16LE. Caso contrário, será lido através da página de código atual (CP_ACP).
    • Evita agora problemas de regras de definição única (ODR) nos programas auxiliares ETWC C/C++ gerados por MC causados por macros de configuração em conflito (por exemplo, quando dois ficheiros .cpp com definições em conflito de MCGEN_EVENTWRITETRANSFER estão associados ao mesmo binário, os programas auxiliares ETW gerados por MC vão passar a respeitar a definição de MCGEN_EVENTWRITETRANSFER em cada ficheiro .cpp, em vez de escolher arbitrariamente um ou outro).
  • Atualizações do Pré-processador de Rastreio do Windows (tracewpp.exe):
    • Suporta ficheiros de entrada Unicode (.ini, .tpl e código fonte). Os ficheiros de entrada com uma marca de ordem de bytes (BOM) UTF-8 ou UTF-16 serão lidos como Unicode. Os ficheiros de entrada que não comecem com um BOM serão lidos através da página de código atual (CP_ACP). Para retrocompatibilidade, se for especificado o parâmetro de linha de comandos -UnicodeIgnore, os ficheiros começados com um BOM UTF-16 serão tratados como vazios.
    • Suporta ficheiros de saída Unicode (.tmh). Por predefinição, os ficheiros de saída serão codificados através da página de código atual (CP_ACP). Utilize parâmetros de 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 para Unicode, executa o processamento em Unicode e converte o texto de saída para a codificação de saída especificada. As versões anteriores de tracewpp evitaram conversões Unicode e realizaram o processamento de texto ao assumir um conjunto de carateres de um único byte. Isto pode levar a alterações de comportamento nos casos em que os ficheiros de entrada não estejam em conformidade com a página de código atual. Nos casos em que isto constitui um problema, considere converter os ficheiros de entrada em UTF-8 (com BOM) e/ou utilizar o parâmetro de linha de comandos -cp:UTF-8 para evitar codificar a ambiguidade.
  • Atualizações do TraceLoggingProvider.h:
    • Evita problemas de regras de definição única (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 associados ao mesmo binário, os programas auxiliares do TraceLoggingProvider.h vão passar a respeitar 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 com modelos variados.
  • Assinar as suas aplicações. A Assinatura Device Guard é uma funcionalidade do Device Guard que está disponível na Microsoft Store para Empresas e Educação, que permite às empresas garantir que todas as aplicações são provenientes de uma origem fidedigna. Veja a documentação sobre a Assinatura Device Guard.
  • Os cabeçalhos do SDK foram atualizados para lidar com erros ao compilar com o pré-processador C padrão e conforme no compilador MSVC cl.exe (/Zc:preprocessor, introduzido no VS 2019 v16.6).
  • Corrigido: “GdiplusTypes.h não compila com NOMINMAX”. Veja o feedback do Visual Studio.
  • Ao compilar com /std:c11 or /std:c17, agora recebe:
    • 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 mais recente winnt.h
    • Como alternativa, utilize a versão anterior do Windows 10 SDK (compilação 19041) ou clang/LLVM para Windows v10 ao direcionar plataformas ARM64
  • DirectXMath (incluindo a versão 3.16 nesta versão) não é compatível com Clang/LLVM para Windows no ARM64.
  • A utilização de maiúsculas e minúsculas em alguns ficheiros de cabeçalho foi alterada, 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 alterados para minúsculas.
    • Para compilações Clang/LLVM para Windows, para suportar tanto a versão antiga como a mais recente do Windows 10 SDK sem avisos, adicione "-Wno-nonportable-system-include-path" à CLI ou o #pragma seguinte na fonte:

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

Atualização de manutenção do Windows 10 SDK, versão 2004 (lançada a 16/12/2020)

    Esta versão contém os ficheiros seguintes. Se encontrar estes problemas, recomendamos que atualize a versão do SDK assim que possível para os evitar:
  • Foram resolvidas falhas imprevisíveis e difíceis de diagnosticar ao associar as bibliotecas adicionais e nativas do SO (por exemplo, onecoreuap.lib e kernel32.lib)
  • Foi resolvido o problema que impedia o funcionamento do AppVerifier
  • Foi resolvido o problema que causava a falha do WACK com "Falha da tarefa ao ativar HighVersionLie"

Forneça-nos comentários

Para conhecer os problemas conhecidos, veja as Perguntas e respostas do winapi-sdk.

Para novos pedidos de funcionalidades para programadores, submeta através da aplicação Hub de Comentários na categoria "Plataforma de Desenvolvimento/API".

Mais recursos

Transferências e ferramentas

Obtenha edições as mais recentes do Visual Studio e das ferramentas de desenvolvimento do Windows 10.

SAIBA MAIS

Arquivo de SDKs

Encontre versões anteriores do Windows SDK e outras ferramentas.

VER ARQUIVO

Blogue do Windows

Subscreva o nosso blogue para ficar a par dos pilotos SDK mais recentes.

OBTER NOVIDADES DE PILOTOS SDK

Folha de factos sobre o ciclo de vida do Windows

Encontre as datas chave das atualizações de versão do Windows e fim do suporte.

VER A FOLHA DE FACTOS