Windows SDK

Выпуск, соответствующий общедоступному выпуску Windows 11 версии 24h2.

Первоначальный выпуск серии 10.0.26100, соответствующий предварительной версии Windows 11 версии 24h2.

Обновление обслуживания 10.0.22621.3235.

Обновление обслуживания 10.0.22621.2428.

Обновление 10.0.22621.1778. Выделенные функции включают:

• API WindowTabManager позволяет приложениям с помощью интерфейсов с вкладками предоставлять информацию на открытых вкладках оболочке Windows.
• Обновления API HumanPresence для повышения удобства использования и добавления новых параметров для датчиков, поддерживающих возможности присутствия человека.
• ИНТЕРФЕЙСы API RemoteDesktop позволяют приложениям переключаться между удаленным и локальным рабочим столом.

• Обновление обслуживания 10.0.22621.755. Включает поддержку ARM64 для выпуска VS 17.4

• Удален api-ms-win-net-isolation-l1-1-0.lib. Приложения, которые ссылались на api-ms-win-net-isolation-l1-1-0.lib, могут переключить t OneCoreUAP.lib в качестве замены.

• Удален irprops.lib. Приложения, которые ссылались на irprops.lib, могут переключаться на bthprops.lib в качестве замены.

• Перемещен тег ENUM TagServerSelection из wuapicommon.h в wupai.h и удален заголовок. Если вы хотите использовать тег ENUM tagServerSelection, необходимо включить wuapi.h или wuapi.idl.

• Пакет API WinRT для Windows 10 позволяет добавить последнюю поддержку API среды выполнения Windows в библиотеки и приложения .NET Framework 4.5+ и .NET Core 3.0+ . Чтобы получить доступ к пакету API WinRT для Windows 10, см. пакет nuget Microsoft.Windows.SDK.Contracts.

• Семейство функций printf теперь соответствует правилам округления IEEE 754 при печати точно представленных чисел с плавающей запятой и будет учитывать режим округления, запрошенный через вызовы fesetround. Устаревшее поведение доступно при связывании с legacy_stdio_float_rounding.obj.

• Комплект сертификации приложений Для Windows. Несколько новых API были добавлены в список поддерживаемых API в комплекте сертификации приложений и Магазине Windows. Если в списке поддерживаемых API отображаются серым или отключенным в Visual Studio, вы можете внести небольшое изменение в исходный файл, чтобы получить к ним доступ. Дополнительные сведения см. в этой известных проблем. Найти дополнительные обновления для тестов.

• Обновления компилятора сообщений (mc.exe):

  • Теперь обнаруживает метку порядка байтов Юникода (BOM) в MC-файлах. Если MC-файл начинается с BOM UTF-8, он будет считываться как файл UTF-8. В противном случае, если он начинается с BOM UTF-16LE, он будет считываться как файл UTF-16LE. Если был указан параметр -u, он будет считываться как файл UTF-16LE. В противном случае оно будет считываться с помощью текущей кодовой страницы (CP_ACP).
  • Теперь избегает проблем с одноопределенным правилом (ODR) в вспомогательных компонентах, созданных MC/C++ ETW, вызванных конфликтующими макросами конфигурации (например, если два .cpp файлы с конфликтующими определениями MCGEN_EVENTWRITETRANSFER связаны с одним и тем же двоичным файлом, вспомогательные средства, созданные MCW, теперь уважают определение MCGEN_EVENTWRITETRANSFER в каждом .cpp файле вместо произвольного выбора одного или другого).

• Обновления препроцессора трассировки Windows (tracewpp.exe)

  • Поддерживает входные файлы Юникода (.ini, TPL и исходный код). Входные файлы, начиная с метки порядка байтов UTF-8 или UTF-16, будут считываться как Юникод. Входные файлы, которые не начинаются с BOM, будут считываться с помощью текущей кодовой страницы (CP_ACP). Если указан параметр командной строки -UnicodeIgnore обратной совместимости, файлы, начиная с UTF-16, будут рассматриваться как пустые.
  • Поддерживает файлы выходных данных Юникода (.tmh). По умолчанию выходные файлы будут закодированы с помощью текущей кодовой страницы (CP_ACP). Используйте параметры командной строки -cp:UTF-8 или -cp:UTF-16 для создания выходных файлов Юникода.
  • Изменение поведения: tracewpp теперь преобразует весь входной текст в Юникод, выполняет обработку в Юникоде и преобразует выходной текст в указанную кодировку выходных данных. Более ранние версии tracewpp избегали преобразования Юникода и выполняли обработку текста при условии, что набор символов с одним байтом. Это может привести к изменениям поведения в случаях, когда входные файлы не соответствуют текущей кодовой странице. В случаях, когда это проблема, рекомендуется преобразовать входные файлы в UTF-8 (с BOM) и (или) с помощью параметра командной строки -cp:UTF-8, чтобы избежать неоднозначности кодирования.

• Обновления TraceLoggingProvider.h:

  • Избегает проблем с одним определением правил (ODR), вызванных конфликтующими макросами конфигурации (например, если два .cpp файла с конфликтующими определениями TLG_EVENT_WRITE_TRANSFER связаны с одним двоичным файлом, вспомогательные средства TraceLoggingProvider.h теперь уважают определение TLG_EVENT_WRITE_TRANSFER в каждом файле .cpp вместо произвольного выбора одного или другого).
  • В коде C++ макрос TraceLoggingWrite был обновлен, чтобы повысить общий доступ к коду между аналогичными событиями с помощью шаблонов variadic.

• Подписывание приложений. Подпись Device Guard — это функция Device Guard, доступная в Microsoft Store для бизнеса и образования, которая позволяет предприятиям гарантировать, что каждое приложение поставляется из надежного источника. См. документацию поподписывания Device Guard.

• Заголовки ПАКЕТА SDK были обновлены для устранения ошибок при компиляции с помощью препроцессора C, соответствующего стандарту, в cl.exe компилятора MSVC (/Zc:preprocessor, представленного в VS 2019 версии 16.6).

• Исправлено: "GdiplusTypes.h не компилируется с NOMINMAX". см.отзывов Visual Studio.

• При сборке с помощью /std:c11 или /std:c17 теперь вы получите:

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

• Clang/LLVM для Windows версии 11, предназначенный для ARM64, несовместим с последней версией winnt.h

  • В качестве обходного решения используйте предыдущую версию пакета SDK для Windows 10 (сборка 19041) или clang/LLVM для Windows версии 10 при нацеливание на платформы ARM64

• DirectXMath (включая версию 3.16 в этом выпуске) несовместим с Clang/LLVM для Windows в ARM64.

  • В качестве обходного решения используйте последнюю версию DirectXMath, доступную из NuGet, vcpkg или GitHub. Эти версии включают необходимые исправления горячего исправления (версия 3.16b).
    • //www.nuget.org/packages/directxmath
    • //github.com/microsoft/vcpkg/tree/master/ports/directxmath
    • //github.com/microsoft/DirectXMath

• В случае некоторых файлов заголовков было изменено, чтобы нормализовать их для файловых систем с учетом регистра:

  • OAIdl.h, ObjIdl.h, ObjIdlbase.h, OCIdl.h, Ole2.h, OleAuto.h и OleCtl.h были сделаны нижним регистром.
  • Для сборок Clang/LLVM для Windows для поддержки старой версии и последней версии пакета SDK для Windows 10 без предупреждений добавьте -Wno-nonportable-system-include-path в CLI или следующую #pragma в источнике:

  #ifdef __clang__

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

  #endif

Этот выпуск содержит следующие файлы. Если вы столкнулись с этими проблемами, рекомендуется обновить версию пакета SDK как можно скорее, чтобы избежать следующих проблем:

• Устранены непредсказуемые и трудно диагностировать сбои при связывании как зонтичных библиотек, так и собственных библиотек ОС (например, onecoreuap.lib и kernel32.lib)
• Устранена проблема, из-за которой не удалось работать AppVerifier
• Устранена проблема, из-за которая приводила к сбою WACK с сообщением "Задача не удалось включить HighVersionLie"