Windows SDK

Versão para corresponder à versão pública do Windows 11, versão 24h2.

Versão inicial da série 10.0.26100, para corresponder à versão prévia do Windows 11, versão 24h2.

Atualização de manutenção 10.0.22621.3235.

Atualização de manutenção 10.0.22621.2428.

Atualização 10.0.22621.1778. Os recursos realçados incluem:

• As APIs WindowTabManager permitem que aplicativos com interfaces com guias com guias abertas forneçam informações sobre guias abertas para o shell do Windows.
• Atualizações para APIs do HumanPresence para melhorar a facilidade de uso e adicionar novas configurações para sensores que dão suporte a recursos de presença humana.
• As APIs RemoteDesktop permitem que os aplicativos mudem entre uma área de trabalho remota e local.

• Atualização de manutenção 10.0.22621.755. Inclui suporte do ARM64 para a versão do VS 17.4

• Removido api-ms-win-net-isolation-l1-1-0.lib. Os aplicativos que estavam vinculando a api-ms-win-net-isolation-l1-1-0.lib podem alternar para OneCoreUAP.lib como um substituto.

• Removido irprops.lib. Os aplicativos que estavam vinculando a irprops.lib podem alternar para bthprops.lib como uma substituição suspensa.

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

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

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

• Kit de Certificação de Aplicativos do Windows. 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 no 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 ODR (regra de definição) 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 são vinculados ao mesmo binário, os auxiliares 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 do Windows (tracewpp.exe):

  • Dá suporte a arquivos de entrada Unicode (.ini, .tpl e código-fonte). Arquivos de entrada começando 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 evitavam conversões Unicode e realizavam o processamento de texto supondo um conjunto de caracteres de byte único. Isso pode levar a alterações de comportamento em 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) 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 na Microsoft Store para Empresas e Educação, que permite que as empresas garantam que cada aplicativo venha de uma fonte confiável. Consulte a documentação do sobre ode 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 do MSVC cl.exe (/Zc:preprocessor, introduzido no VS 2019 v16.6).

• Corrigido: "GdiplusTypes.h não é compilado com NOMINMAX". consultede comentários do Visual Studio.

• Ao compilar 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 alternativa, use a versão anterior do SDK do 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.

  • Como alternativa, use a versão mais recente do DirectXMath, disponível no NuGet, vcpkg ou GitHub. Essas versões incluem as correções frequentes necessárias (versão 3.16b).
    • //www.nuget.org/packages/directxmath
    • //github.com/microsoft/vcpkg/tree/master/ports/directxmath
    • //github.com/microsoft/DirectXMath

• 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 letras minúsculas.
  • Para builds do Clang/LLVM para Windows, para dar suporte à versão mais antiga e ao SDK mais recente do Windows 10 sem avisos, adicione -Wno-nonportable-system-include-path à CLI ou os seguintes #pragma na origem:

  #ifdef __clang__

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

  #endif

Esta versão contém os seguintes arquivos. Se você encontrar esses problemas, recomendamos que você atualize sua versão do SDK assim que 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 impedia o AppVerifier de funcionar
• Problema resolvido que causou falha do WACK com "Falha na tarefa ao habilitar HighVersionLie"