Windows sdk программа для чего

Windows SDK AddOn — что это за программа и нужна ли она?

Приветствую друзья! В Windows могут появиться программы, которые вы не устанавливали. Многих пользователей этим не удивишь, привыкли уже к такому беспределу)) Но откуда они берутся? Некоторые появились при установке других прог, некоторые установила сама Windows при обновлении, а третьи могут вообще быть вирусами или потенциально опасными, шпионскими там.. Но сегодня у нас пойдет речь про нормальную прогу для программистов))

Разбираемся

Windows SDK — пакет для создания приложений. В него входят новейшие заголовки, библиотеки, метаданные, и другие компоненты. Слово AddOn означает как дополнение, то есть дополнительный компонент. Версия для Windows 10 позволяет создавать как классические, так и универсальные приложения.

Как я понимаю, классические приложения — это обычные привычные нам проги, которые можно скачать из интернета и установить. А вот универсальные — это уже метро-приложения, те самые модные плиточные проги, которые есть в меню пуск Windows 10, да и в Windows 8 они вроде тоже есть. Их еще можно скачать с магазина приложений (Microsoft Store).

Что такое SDK. ДЛя чего они используются. В чём их разница с API.

1. Был скачан с офф сайта Майкрософт и установлен.
2. Был автоматически установлен как компонент Visual Studio (среда разработки для разработчиков).
3. Третий вариант — мое мнение. Если он вдруг появился сам по себе, то мог установиться как обновление. Второй вариант — появился после установки некоторой крупной программы.

Что интересно — разработка приложений UWP для десятки версии LTSB не поддерживается:

Инфа с офф сайта)

Версия для десятки, а точнее для билда 1809, содержит новые API-интерфейсы и обновленные средства для разработки приложений.

Вот картинка, видим что прога установлена среди остальных, но что главное — размер ее небольшой, всего 152 КБ:

Размер просто крохотный — поэтому можно оставить ее и не думать об удалении))

Тоже самое, но здесь прогу видим в списке окна Программы и компоненты:

Для вызова такого окна есть трюк — зажимаете Win + R, пишите команду appwiz.cpl, нажимаете ОК. В итоге откроется окно со списком установленного софта.

Установочное окно, где видим, то данная прога существовала еще во времена Windows XP:

Software Development Kit — набор средств разработки для программистов.

А вот и студия Visual Studio, где видим, что она при установке также может поставить Windows SDK:

Вывод — если вы программист — данный компонент у вас спокойно может быть.

Можно ли удалить данную программу?

Места на диске она занимает оч мало, но при этом является прогой от Майкрософт (значит точно безопасна). В процессах не висит, в автозагрузке ее тоже не должно быть.

API vs. SDK: What’s the difference?

Тем не менее, если вы хотите удалить прогу — лучше сначала сделать точку восстановления:

Зажимаете Win + R, пишите команду:

Команда откроет окошко Свойства системы.

Нажимаете ОК.
У вас откроется окно Свойства системы, здесь активируете вкладку Защита системы, где выбираете Системный диск и нажимаете Создать:
У меня кнопка неактивна, просто восстановление отключено. Но у вас — должна быть активна, в противном случае нажмите Настроить и включите восстановление.

Лично я советую удалять только при наличии точки восстановления! Это важно!

Вывод

1. Windows SDK AddOn — компонент для программистов.
2. Для обычных юзеров не представляет никакой ценности.
3. Теоритически можно удалить. Но возможно он нужен для работы каких-то программ, учитывая небольшой размер — советую оставить его.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Microsoft Windows SDK

Microsoft Windows Software Development Kit

Microsoft Windows SDK, Platform SDK, и Microsoft NET Framework SDK — комплекты разработки программного обеспечения от Microsoft , которые содержат файлы заголовков, библиотеки, примеры, документацию и инструменты, необходимые для разработки приложений для Microsoft Windows и Microsoft .NET Framework.

Разница между этими тремя SDK заключается в их области специализации:

• Platform SDK специализируется на разработке приложений для Microsoft Windows 2000, Microsoft Windows XP и Microsoft Windows Server 2003 R2
• .NET Framework SDK занимается разработкой приложений для Microsoft .NET Framework 1.1 и Microsoft NET Framework 2.0
• Windows SDK является преемником двух предыдущих и поддерживает разработку приложений для Microsoft Windows XP , Microsoft Windows Vista , Microsoft Windows 7 , Microsoft Windows Server 2008 , Microsoft .NET Framework 3.0, Microsoft NET Framework 3.5 и Microsoft NET Framework 4.0.

Platform SDK также содержит ресурсы (инструменты, документацию, образцы и т.д.) и компиляторы, необходимые для разработки 64-битных приложений на платформах x86, x64 и Itanium (IA-64).

Microsoft Windows SDK , и его предшественники Platform SDK и Microsoft NET Framework SDK, являются комплектами разработки программного обеспечения (SDK) от Microsoft , которые содержат документацию , файлы заголовков , библиотеки , примеры и инструменты , необходимые для разработки приложений для Microsoft Windows и .NET Framework . Platform SDK специализируется на разработке приложений для Microsoft Windows 2000 , Microsoft Windows XP и Microsoft Windows Server 2003 R2 . Microsoft NET Framework SDK предназначен для разработки приложений для Microsoft NET Framework 1.1 и Microsoft NET Framework 2.0 Microsoft. Windows SDK является преемником двух и поддерживает разработку приложений для Microsoft Windows XP] и более поздних версий, а также Microsoft NET Framework 3.0 и более поздних версий. [Источник 1]

Особенности

Platform SDK является преемником оригинального Microsoft Windows SDK для Microsoft Windows 3.1x и Microsoft Win32 SDK для Microsoft Windows 9x . Он был выпущен в 1999 году и является самым старым SDK (Software Development Kit). Platform SDK содержит компилятор, инструменты, документацию, файлы заголовков, библиотеку и образцы , необходимые для разработки программного обеспечения на IA-32 , 64 и IA-64 процессорных архитектурах Microsoft.NET Framework SDK, однако, пришли к тому , с Microsoft .NET Framework . Начиная с Microsoft Windows Vista , в Platform SDK. NET Framework SDK, Tablet PC SDK и Windows Media SDK заменены новый единый набор под названием Windows SDK. Тем не менее, 1,1 SDK NET Framework не входит , так как NET Framework 1.1 не поставляется с Microsoft Windows Vista. Windows Media Center SDK для Microsoft Windows Vista судов отдельно.) DirectX SDK был слит в Windows SDK с выходом Microsoft Windows 8.

Окна SDKs доступны бесплатно; они когда — то были доступны на Microsoft Download Center , но были перенесены в MSDN на 2012.

Разработчик может хотеть использовать старую SDK по определенной причине. Например, Microsoft Windows Server 2003 R2 Platform SDK выпущен в феврале 2003 года был последний SDK (Software Development Kit) , чтобы обеспечить полную поддержку Visual Studio 6.0. Некоторые старые версии PSDK еще можно загрузить из центра загрузки Майкрософт; другие можно заказать на CD / DVD. [Источник 2]

Получение пакета SDK

SDK для Windows доступны бесплатно на Microsoft Download Center Platform SDK февраля 2003 издание.

Документация

В документации Windows SDK включает в себя Инструкции задокументировать:

Пакет SDK для Windows 10

В состав пакета SDK для Windows 10 (10.0.19041.0) версии 2004 входят новейшие заголовки, библиотеки, метаданные и средства для создания приложений для Windows 10.

Этот пакет SDK поможет вам в создании приложений универсальной платформы Windows (UWP), а также приложений Win32 для Windows 10 версии 2004 и для предыдущих выпусков Windows.

Для разработки приложений для Windows 10 версии 2004 (или более поздней версии) требуется Visual Studio 2017 или более поздней версии. Этот пакет SDK не будет обнаруживаться в предыдущих версиях Visual Studio.

Начало работы

Получить пакет SDK для Windows 10 можно двумя способами: установить с этой страницы, щелкнув ссылку для скачивания, или выбрать эту версию пакета SDK для Windows 10 (10.0.19041.0) в дополнительных компонентах установщика Visual Studio 2019.

Перед установкой этого пакета SDK:

1. Изучите все системные требования, изложенные ниже.
2. Выйдите из Visual Studio 2019 перед установкой пакета.
3. Изучите приведенные ниже сведения об известных проблемах.

Системные требования

Минимальные системные требования этого пакета Windows SDK:

Поддерживаемые операционные системы

• Разработка приложений универсальной платформы Windows (UWP)

• Windows 10 1507 или более поздней версии: Домашняя, Профессиональная, для образовательных учреждений и Корпоративная (выпуски LTSB и S не поддерживаются)
• Windows Server 2019, Windows Server 2016 и Windows Server 2012 R2 (только для командной строки)

• Разработка приложений Win32

• Windows 10 версии 1507 или более поздняя версия
• Windows Server 2019, Windows Server 2016 и Windows Server 2012 R2 (только для командной строки);
• Windows 8.1
• Windows 7 с пакетом обновления 1 (SP1)

(Не все средства поддерживаются в среде операционных систем более ранних версий)

Требования к оборудованию

• Процессор с частотой 1,6 ГГц или более мощный
• 1 ГБ памяти (ОЗУ)
• 4 ГБ свободного пространства на жестком диске

Дополнительные требования для этого SDK

Для установки пакета в среде Windows 8.1 и операционных систем более ранних версий необходимо сначала установить обновление KB2999226. Чтобы выполнить установку Windows SDK через Центр обновления Windows, перед этим необходимо установить последние рекомендованные обновления и исправления из Центра обновления Майкрософт.

Что нового

В состав пакета SDK для Windows 10 версии 2004 входят новые API-интерфейсы и обновленные средства для разработки Windows-приложений. Узнайте больше о новых возможностях Windows 10 версии 2004.

Интерфейсы API

Сведения о новых API, появившихся в Windows 10 версии 2004, см. в статье о новых возможностях для разработчиков в Windows 10, сборка 19041.

Удаление api-ms-win-net-isolation-l1-1-0.lib

В этом выпуске библиотека api-ms-win-net-isolation-l1-1-0.lib удалена из пакета Windows SDK. Приложения, связанные с api-ms-win-net-isolation-l1-1-0.lib, в качестве замены можно перейти на OneCoreUAP.lib.

Удаление irprops.lib

В этом выпуске библиотека irprops.lib удалена из пакета Windows SDK. Приложения, связанные с irprops.lib, в качестве замены можно перейти на OneCoreUAP.lib.

Удаление wuapicommon.h и wuapicommon.idl

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

Пакет с новыми API-интерфейсами WinRT для Windows 10

Пакет API-интерфейсов WinRT для Windows 10 позволяет добавить поддержку новейших API среды выполнения Windows в библиотеки и приложения .NET Framework 4.5 или .NET Core 3.0 и более поздние версии этих платформ. Пакет API-интерфейсов WinRT для Windows 10 доступен здесь: пакет NuGet Microsoft.Windows.SDK.Contracts.

Универсальная среда выполнения C (UCRT)

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

Инструменты

Комплект сертификации приложений для Windows

В этом выпуске Windows SDK добавлено несколько поддерживаемых API-интерфейсов в комплекте сертификации приложений для Windows и Microsoft Store. Если в списке поддерживаемых есть неактивные или отключенные в Visual Studio интерфейсы API, для доступа к ним можно внести небольшое изменение в исходный файл. Дополнительные сведения см. в описании этой известной проблемы.

Помимо добавления API, в тесты были внесены указанные ниже изменения.

• ValidateContentUriRules будет выполнять только информационную функцию. О сбоях тестов будет сообщаться в предупреждениях.

• тест доступа WinRT WebView для веб-приложения;
• тест PackageSizeCheck для приложений UWP;
• тест SupportedApi для приложений моста для классических приложений;
• тест AppContainerCheck из BinScope для приложений UWP;
• проверка ServiceWorker для всех типов приложений.

• Тест High-DPI. Новый тест для приложений моста для классических приложений позволяет проверить, использует ли приложение функцию, учитывающую DPI. Если она не указана, поступает предупреждение. Этот тест позволит реализовать в приложениях учет DPI для каждого монитора. См. дополнительные сведение о разработке классических приложений с высоким DPI в Windows.

Компилятор сообщений (mc.exe)

Далее перечислены новые возможности:

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

Windows Trace Preprocessor (tracewpp.exe)

Далее перечислены новые возможности:

• Теперь поддерживаются входные файлы в кодировке Юникода (INI-файлы, TPL-файлы и исходный код). Входные файлы, начинающиеся с метки порядка байтов UTF-8 или UTF-16, будут читаться как файлы в кодировке Юникода. Входные файлы, которые не начинаются с BOM, будут читаться с использованием текущей кодовой страницы (CP_ACP). Для обеспечения обратной совместимости, если указан параметр командной строки -UnicodeIgnore, файлы, начинающиеся с BOM UTF-16, будут считаться пустыми.
• Теперь поддерживает выходные файлы в формате Юникода (ТМH-файлы). По умолчанию выходные файлы будут кодироваться с использованием текущей кодовой страницы (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

WPF, UWP, WinUI, MAUI, Windows App SDK

Человека далёкого от клиентской разработки на Windows все эти термины определённо путают. И даже среди MS-сообщества регулярно возникают споры жив UWP или мёртв. Причем главный вопрос в этом споре — а что же такое UWP?

Вот уже года 3 Microsoft проводит «рефакторинг» в своём «королевстве». Несколько устав видеть одни и те же споры в твиттере, и оставлять одни и те же комментарии на хабре, я решил расписать как же многочисленные UI-фреймворки MS соотносятся между собой. Кто из них больше мёртв. Возможно, кому-то это поможет в выборе технологии для будущего проекта.

Windows API и Windows Runtime

Прежде чем начать разбираться с UI-фреймворками стоит сначала опуститься на уровень ниже, впрочем, без особых подробностей. В современной винде 2 основных API для работы приложений. Windows API (обычно сокращается до Win32) и Windows Runtime (WinRT).

При разработке первый был ориентирован на язык С, и активно развивался вплоть до выхода Windows 8. Я не имею в виду, что этот API объявлен устаревшим, но все новые функции системы уже разрабатывются для WinRT. Хотя некоторые так же бекпортируются и в Win32. Приложения, которые работают через Win32 и используют его модель приложений и сервисов Microsoft называет классическими.

WinRT — вещь немного более сложная. Это даже не API, а способ взаимодействия с ним. Из вики:

WinRT has a rich object-oriented class-based type system that is built on the metadata. It supports constructs with corresponding constructs in the .NET framework: classes, methods, properties, delegates, and events.

Ключевое: есть объектно-ориентированные метаданные, которые описывают публичный интерфейс библиотеки: поддерживаются базовые классы (числа, строки), асинхронность (async/await), события. Начиная с Windows 8 весь новый API — это COM, с которым можно взаимодействовать через данный протокол. Любой язык, который реализует языковую проекцию в WinRT (C++/WinRT, Rust/WinRT, Python/WinRT, С#/WinRT) может взаимодействовать с этим API, будто это нативная для языка библиотека. Компоненты WinRT могут быть написаны на любом их этих языков. Сам виндовый API написан при этом на C++.

Помимо объектно-ориентированности, новый API имеет версионирование, больший контроль доступа к вызовам. Некоторые системные вызовы могут делать только приложения определённых разработчиков, некоторые доступны по специальному ключу. Некоторые сокрыты весьма условно: если приложение попало на комп, оно может ими пользоваться. Но вот в Microsoft Store могут и не пустить.

Application Models

Два вышеописанных системных API в данный момент подразумевают две разных модели жизненного цикла приложений. Классическая модель — приложению можно почти всё, оно может залезть почти куда угодно, читать что угодно, прятать окна и свою деятельность. С одной стороны — это позволяет делать различные удобные штуки вроде Punto Switcher, или сворачивание в трей по закрытию окна (вопреки ожиданиям, это не стандартное поведение в Windows). С другой стороны, это развязывает руки любым троянам.

И это было одной из причин, почему для приложений, работающих с WinRT, за основу была взята модель из мобильных платформ — изолированные приложения с контролируемым системой жизненным циклом. Другой из озвученных причин является большая энергоэффективность мобильного подхода. Всё же значительное количество ПК — ноутбуки.

Вылилось это в повсеместные ограничения, привязку времени жизни приложения и времени жизни его основного окна (пока-пока сворачивание в трей). А также сильные ограничения работы в фоновом режиме. На размен давались различные фоновые задачи, контролируемые системой, и легальные способы интеграции в систему (системные контракты, такие как Share UI). В Microsoft посчитали, что за неполные 9 лет за счет таких интеграций появилось около 40 возможных точек входа в приложение. В какой-то момент даже появилась возможность делать консольные приложения, работающие поверх WinRT.

Стоит так же отметить, что эти две модели не изолируют Win32 и WinRT API друг от друга. В UWP приложения всё так же можно подключать Win32-библотеки, пока это не открывает путь за пределы песочницы. Из Win32 можно дергать WinRT API, но для большей его части надо получить AppIdentity, до недавнего времени это означало, что приложение придётся запаковать и оно станет чуть более изолированным.

И, пожалуй, именно тут надо вспомнить про UWP (Universal Windows Platform). Технически это название для реализации Windows Runtime в Windows 10+. Дело в том, что Windows Runtime в телефонах и Windows Runtime в Windows 8 отличались настолько, что для них нужно было делать отдельные сборки приложений (даже для одной архитектуры процессора). С появлением Windows 10, ОС и рантайм допилили до того состояния, когда 1 сборка приложения может запускаться и на телефоне (тогда они ещё были), и на ПК. Так же к этому списку добавились XBox, IoT, Hololens и Teams (большая интерактивная «маркерная доска»)

На практике, под сокращением UWP часто понимают именно UWP-приложения.

UI-фреймворки

Наконец можно поговорить про UI-фреймворки. С Windows Forms и WPF многие знакомы. UI, работающий поверх Win32 API. Отличаются способом верстки UI (дизайнер или XAML) и способом отрисовки (GDI или DirectX). С появлением WinRT, эти фреймворки особо не развиваются, но из-за огромного количества легаси приложений, Microsoft вынуждена поддерживать их.

Например, в последних выпусках десятки значительно улучшена поддержка HDPI для WinForms.

Как такового маркетингового названия для UI-фреймворка в UWP нет. В зависимости от контекста используют понятия UWP-приложения и UWP XAML. Итак, UWP-приложения используют WinRT-модель приложений, XAML в качестве языка разметки и не требуют .NET. Фактически даже приложения, написанные на C#, собираются в нативный код, а не IL.

XAML так же отличается от того, что используется в WPF, так как является развитием телефонного Silverlight (подмножества WPF). В итоге, с точки зрения верстки у XAML в UWP есть как отсутствующие фишки (например, multibindings), так и новые полезные фичи (например, компилируемые x:Bind), по сравнению с WPF. Кроме того, в UWP появился Composition API для визуально богатых, но экономичных с точки зрения ресурсов анимаций. И сделано много наработок для того, чтобы поддержать все богатство способов взаимодействия в современной Windows. Например, пункты контекстного меню становятся больше, если вызывать меню через тач.

WinUI

WinUI достоин отдельного упоминания, так как он един в двух лицах.

WinUI 2.x — UI-библиотека для UWP-приложений, содержащая в себе новые, в том числе экспериментальные, контролы. А также, обеспечивающая совместимость со старыми версиями Windows 10 (аналог AndroidX)

WinUI 3.x — часть Windows App SDK. Фактически это и есть UI-фреймворк для UWP, только оторванный от жизненного цикла UWP-приложений.

Обе версии сейчас развиваются параллельно.

Project Reunion он же Windows App SDK

Собственно, посмотрев на это обилие фреймворков (ещё и ввязавшись зачем-то в ReactNative), и выслушав жалобы разработчиков, в мае 2020 Microsoft анонсировала объединение подходов. Разработчики Windows Forms и WPF хотят писать стильные/модные/молодёжные приложения, получить доступ к новому API (в том числе различным системным триггерам, которые бывают довольно удобны). UWP-разработчики хотят получить больший доступ к системе и более простые способы распространения приложения, так как сейчас мимо стора распространять приложение не просто.

Собственно, WinUI 3.x является частью решения. Берём графический фреймворк от UWP-приложений, насаживаем его на жизненный цикл классических приложений. И все счастливы.

На самом деле, все конечно сложнее. И что за монстр Франкенштейна в итоге получится мы узнаем уже в конце года. Впрочем начать знакомиться можно уже сегодня.

Так жив ли больной?

UWP, как подсистема винды, никуда не денется в ближайшее время. Это всё ещё основной вектор развития API системы. Для UWP-приложений, которые нацелены только на десктоп, уже настало время планировать портирование на Windows App SDK. Недавно выпущенная версия 0.8 уже допускается в Microsoft Store.

Если же приложение должно работать и на других платформах (Xbox, Hololens и т. д.), то тут придется ждать следующего года. Но рано или поздно, таки придется переехать на Windows App SDK.

Касательно классических приложений, покуда вам не нужны новые фичи платформы (пуши, возможность поделиться в ваше приложение, новый богатый UI и т. п.), то делать в общем-то тоже ничего не надо.

Если писать новое приложение, то стоит оценить Windows App SDK в текущем его состоянии. И возможно писать на нём.

А как же MAUI?

Всё что я писал до этого, касалось только Windows и никаких других ОС. Но у Microsoft есть Xamarin — .NET для мобилок (на самом деле mono для мобилок). Наработки xamarin вмерживаются в .NET 5 и 6. Собственно MAUI — .NET Multi-platform App UI — ничто иное как Xamarin.Forms, реализованные в .NET.

MAUI — абстракция над нативными UI-фреймворками.

Собственно, на винде это будет абстракцией над WinUI. У Xamarin.Forms есть поддерживаемая сообществом реализация поверх WPF.

Аналогичным образом ReactNative for Windows так же является абстракцией поверх WinUI. На нем, кстати, написан магазин на Xbox.

Подытожим

• UWP — название подмножества API Windows, но часто используется как сокращение для изолированных приложений, работающих на этом API.
• WinUI — современный графический фреймворк для Windows
• Windows App SDK — в перспективе, единый набор SDK для любых приложений на Windows, вне зависимости от языка, и с возможностью переключения между различными жизненными циклами приложений
• MAUI — привязанная к .NET кроссплатформенная абстракция над нативным UI

Источник: habr.com

Microsoft Windows SDK

9 июня, 2016 0

Microsoft Windows SDK – свободный пакет инструментов для разработчиков, содержащий компиляторы, заголовки, библиотеки, примеры программного кода, а также новую систему помощи, которую разработчики могут использовать для создания приложений, работающих на Microsoft Windows.

Ссылки

Похожие программы

zlib

Panda3D

FAT Disk Browser

Stockfish

NPE File Analyzer

Apache FOP

Adobe Spry

GameMaker

Apache Log4j

Adventure Game Studio

Источник: wikiprograms.org