Windows SDK

Atualização de manutenção 10.0.22621.2428.

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.

• Atualização de manutenção 10.0.22621.755. Inclui suporte arm64 para o lançamento do VS 17.4

• 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 quando segmentar 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 solução, utilize a versão mais recente do DirectXMath, disponível no NuGet, vcpkg ou GitHub. Estas 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

• As maiúsculas e minúsculas de alguns ficheiros de cabeçalho foram alteradas para normalizá-los 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 os seguintes #pragma na origem:

  #ifdef __clang__

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

  #endif

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 de SO nativas (por exemplo, onecoreuap.lib e kernel32.lib)
• Foi resolvido um problema que impedia o AppVerifier de funcionar
• Foi resolvido o problema que fazia com que a WACK falhasse com "A tarefa não conseguiu ativar HighVersionLie"