Windows SDK

Lançamento para corresponder ao Windows 11, versão 24h2 lançamento público.

Lançamento inicial da série 10.0.26100, para corresponder ao Windows 11, versão 24h2 preview.

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 destacados incluem:

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

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

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

• Removido irprops.lib. Os aplicativos que estavam vinculando irprops.lib podem alternar para bthprops.lib como um substituto drop-in.

• Movido ENUM tagServerSelection de wuapicommon.h para wupai.h e removido o cabeçalho. Se você gostaria de usar o ENUM tagServerSelection, você precisará incluir wuapi.h ou wuapi.idl.

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

• A família de funções printf agora está em conformidade com as regras de arredondamento IEEE 754 ao imprimir números de vírgula 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 Windows. Várias novas APIs foram adicionadas à lista APIs Suportadas no Kit de Certificação de Aplicações e na Loja Windows. Se houver APIs na lista com suporte que aparecem acinzentadas ou desabilitadas no Visual Studio, você pode 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 Message Compiler (mc.exe):

  • Agora deteta a marca de ordem de bytes Unicode (BOM) em arquivos .mc. Se o arquivo .mc começar com uma lista técnica UTF-8, ele será lido como um arquivo UTF-8. Caso contrário, se ele começar com uma lista técnica UTF-16LE, ele será lido como um arquivo UTF-16LE. Se o parâmetro -u foi 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 uma regra de definição (ODR) em auxiliares 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 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):

  • Suporta arquivos de entrada Unicode (.ini, .tpl e código-fonte). Os arquivos de entrada que começam com uma marca de ordem de bytes (BOM) UTF-8 ou UTF-16 serão lidos como Unicode. Os arquivos de entrada que não começam com uma lista técnica 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 uma lista técnica UTF-16 serão tratados como vazios.
  • Suporta 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.
  • Mudança de comportamento: tracewpp agora converte todo o texto de entrada em Unicode, executa o processamento em Unicode e converte o texto de saída para a codificação de saída especificada. Versões anteriores do tracewpp evitavam conversões Unicode e executavam 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 isso for um problema, considere converter os arquivos de entrada para UTF-8 (com BOM) e/ou usar o parâmetro de linha de comando -cp:UTF-8 para evitar ambiguidade de codificação.

• Atualizações do TraceLoggingProvider.h:

  • Evita problemas de uma regra de definição (ODR) 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 do 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 permitir um melhor compartilhamento de código entre eventos semelhantes usando modelos variádicos.

• Assinar as suas aplicações. A assinatura do Device Guard é um recurso do Device Guard disponível na Microsoft Store para Empresas e Educação, que permite que as empresas garantam que todos os aplicativos vêm de uma fonte confiável. Consulte a documentação do sobre o Device Guard Signing.

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

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

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

  • C99 tgmath.h
  • C11 static_assert em assert.h
  • C11 stdalign.h
  • C11 stdnoreturn.h

• Clang/LLVM para Windows v11 visando ARM64 não é compatível com o winnt.h mais recente

  • Como solução alternativa, use a versão anterior do SDK do Windows 10 (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.

  • Como solução alternativa, use a versão mais recente do DirectXMath, disponível no NuGet, vcpkg ou GitHub. Essas versões incluem os hot fixes necessários (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 minúsculas.
  • Para compilações do Clang/LLVM para Windows, para oferecer suporte à versão mais antiga e ao SDK mais recente do Windows 10 sem avisos, adicione -Wno-nonportable-system-include-path à CLI ou aos seguintes #pragma na origem:

  #ifdef __clang__

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

  #endif

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

• Resolvidas falhas imprevisíveis e difíceis de diagnosticar ao vincular bibliotecas guarda-chuva e bibliotecas nativas do sistema operacional (por exemplo, onecoreuap.lib e kernel32.lib)
• Resolvido o problema que impedia o AppVerifier de funcionar
• Resolvido o problema que fazia com que o WACK falhasse com "Falha na tarefa ao ativar HighVersionLie"