SDK do Windows

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 forneçam informações sobre guias abertas para o shell do Windows.
• Atualizações às 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 alternem 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. Aplicativos que estavam se vinculando a api-ms-win-net-isolation-l1-1-0.lib podem alternar t OneCoreUAP.lib como uma substituição.

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

• Moveu a marca ENUMServerSelection 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 do Windows 10 WinRT permite adicionar o suporte mais recente Windows Runtime APIs às bibliotecas e aplicativos do .NET Framework 4.5+ e do .NET Core 3.0+. Para acessar o pacote de API 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 respeitará 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 APIs com suporte no Kit de Certificação de Aplicativos e na Windows Store. Se houver APIs na lista com suporte que aparecem esmaeçadas ou desabilitadas no Visual Studio, você pode fazer uma pequena alteração no arquivo de origem para acessá-las. Para obter mais detalhes, consulte esse 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 uma 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 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 do 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. Os arquivos de entrada que não começam com uma 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 uma 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: tracewpp agora converte todo o texto de entrada em Unicode, executa o processamento em 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 executavam 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 sã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 variádicos.

• 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 cada aplicativo venha de uma fonte confiável. Consulte a documentação sobre a Assinatura do Device Guard.

• Os cabeçalhos do SDK foram atualizados para resolver 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". Confira 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 de acesso 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 foi alterado 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 do Windows 10 mais recente 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 arquivos a seguir. Se você encontrar esses problemas, recomendamos que 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 impedia o trabalho do AppVerifier
• Resolvido o problema que fazia com que o WACK falhasse com "Falha na tarefa ao habilitar o HighVersionLie"