Что бы в долгосрочной перспективе не поддерживать в одно лицо своё ядро. Хотя я 100% согласен что альтернатив уйма, начиная от открытия NT, заканчивая простым фактом, что иметь закрытое ядро просто полезней для бизнеса. Вот как прикинуть, что выгодней уверен достоверно не сможем ни ты, ни я.

// main.cpp
#include <winrt/Windows.Foundation.h>

using namespace winrt;
using namespace Windows::Foundation;

int main()
{
    winrt::init_apartment();
    Uri contosoUri{ L"http://www.contoso.com" };
    Uri combinedUri = contosoUri.CombineUri(L"products");
}

Вот где тут COM? Уверен, в managed коде всё примерно так же.

Вот где тут COM?

Оно хоть компилируется? Тут явно виден COM.

Вот где тут COM?

Под всем WinRT, рядом с WinAPI.

Что бы в долгосрочной перспективе не поддерживать в одно лицо своё ядро.

Так они с этим весьма успешно справляются. А уж с поддержкой железа так вообще у них ситуация лучше, чем в Linux. Я не вижу предпосылок в будущем для того, чтобы вендоры, внезапно, начали воротить нос от NT Kernel и DDK.

Под всем WinRT, рядом с WinAPI.

Под - да. Чего будет если поменять реализацию, код это же не перестанет работать?

А в куда смотреть?

Все интерфейсы типа IAsyncAction это всё ещё часть foundation из winrt.

В отличии от IUnknown например.

И обрати внимание на Minimum supported client, в разных этих двух случаях. Конечно революций не будет, никто в здравом уме от MS этого и не ждёт.

Посмотрите исходник какой-нибудь UWP программы, например Calculator. Там COM сплошной.

Много буков, в куда смотреть?

А, ну, вижу. Но, то что поделка написана непортабельно, не говорит о том, что так надо делать.

WinRT никак не противопоставляется WinAPI. WinRT это просто новые API.

WinAPI противопоставляется UWP.

UWP - каждое приложение запускается в контейнере. Есть система прав похожая на IOS/Android.

Изначально WinRT был доступен только под UWP. Но рыночку плевать на Security, и рыночек пользовался старыми технологиями. Поэтому Microsoft в 2020 решил согласиться с рыночком, и в презентации сказал, что WinRT API будет доступно, и для обычных WinAPI приложений(не sandboxed UWP).

Вот тут подробнее: https://github.com/microsoft/ProjectReunion

Хоть проект и написан, что «Воссоединение», но большинство это поняли как смерть UWP. AKA «Зачем писать UWP, если новые API доступны для обычных программ?»

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

Всё тут: https://github.com/microsoft/ProjectReunion

Все интерфейсы типа IAsyncAction это всё ещё часть foundation из winrt.

IAsyncAction: IInspectable: IUnknown.

windows.foundation.h:IAsyncAction.

Потому что между ними общего вообще ничего нет.

Это ещё более бессмысленное занятие, чем замена NT Kernel на Linux.

WinAPI это столп и вендорлок, на котором держится популярность Windows. Один из.

Забавно, а ссылочку в доке не проставили, ай яй яй.

а ссылочку в доке не проставили, ай яй яй

Видимо маркетологи писали, а вы повелись.

Тем не менее, в таком не маленьком приложении как калькулятор - 2.5 точки где используется COM, и то в основном для коммуникации с DirectX насколько я понял из беглого осмотра, притом, возможно тоже не самым корректным способом. Это примерно как в boost приложении для задания какого-нить SO_BUSY_POLL вызвать setsockopt или просто подключить хидер с объявлением значения этой опции.

Кстати движок этого калькулятора тянется со времён Windows 3.x, если не раньше. Я сравнивал с утечкой.

http://esxi.z-lab.me:666/~exl_lab/screens/windows_calc_old_vs_new.png
http://esxi.z-lab.me:666/~exl_lab/screens/WinCalcXp.jpg
http://esxi.z-lab.me:666/~exl_lab/screens/WinCalc10.jpg

Вот чего меня окончательно убедило бы, это передача на вход API из foundation IUnknown или IDispatch.

Получается - уже, попробовали - не прокатилло. Нате вам жуйте ещё один набор интерфейсов, в нагрузку к mfc, atl и wtl.

Кстати, калькулятор это конечно UWP приложение, но явно не чисто C++ /WinRT приложение, если я правильно понял посыл M$. В том плане, что там c++ clr во все поля используется.

Блин, когда бы после треда на лоре столько msdn читать, тьфу на вас всех.

Для компании типа микрософт писать свое ядро проще и дешевле чем адаптировать чужое.

Старые приложения не должны пострадать при этом конечно же. Были рассказы как они мучались с cmd, типа нельзя было ускорять или замедлять выполнение, иначе могли скрипты у кого нибудь сломаться.

Конечно-конечно. Свое «ядро»  — это повод приравнять ее к NT. Прям «Пару ключиков реестра поменять» (с) Может ее еще и Катлер разработал и по сравнению с VMS они прям одно и то же, только это «ядро» не может одновременно ходить и дышать? :) или ее разрабы в щелочку подсматривали, когда Катлер от компа отходил, дергали по частям чо видели, потому получался все огрызок с «ядром» аж до ME и потому «принципиально» похожей она стала не раньше выхода XP?

Невозможно. Будут конфликты с Линусом, если майки захотят внести какие-нибудь радикальные изменения в ядро. Придётся делать форк. Фанатики будут копротивлятся и умышленно делать изменения в ядре, мешающие майкам. Линус не печётся за стабильность внутриядерного API. В итоге стоимость поддержки форка сравняется со стоимостью поддержки свое ядра.

Вот, кстати, да, рыночек UWP порешал. Не ни одной серьёзной UWP программы, за пределами тех, что написала сама MS. 100500 полузаброшенных клиентов для Твиттера – не в счёт.

Вот где тут COM?

https://yizhang82.dev/what-is-winrt#winrt-is-strongly-typed-com

Изначально WinRT был доступен только под UWP

UWP это переименованный после выпуска Windows10 WinRT. Ни для чего, кроме десятой винды и ее разновидностей, не существует.

Хорошее описание, понятней чем в доке.

Тем более это чужое ядро никогда не станет своим.

Но у одной конторки ведь получилось сделать чужое ядро, своим, правда ведь?😁

У Apple? Просто они правильное ядро взяли.

Все кроме пункта номер 2 звучит как рафинированный буллшит.

оффтоп

привет. у тебя сервачек прилег. Надолго? Хотел почитать кое-чего.

Не облаками, а мобилками скорее всего. Сейчас нужды типичного домашнего пользователя в интернете и развлечениях покрывает мобилка и телек с андроид/эппл тв приставкой(если встроенного нет). На крайняк планшет. Пк мало кому нужен на самом деле

Вроде ожил. Видимо домашний провайдер чудит.

WinApi - это один из самых грамотно спроектированных GUI API из существующих. Он был спроектирован сразу правильно и существует уже почти 35 лет практически без изменений

Я был о вас лучшего мнения.

Я был о вас лучшего мнения.

Предлагайте свой вариант. Только не надо предлагать GTK, там сплошной ужас.

почти 35 лет

1985й год.

Winapi.

Я ничего не перепутал?

В 1985 вышла Windows 1.0, и её приложения использовали WinAPI.

Вот жеж! Действительно, win16 датируется 1985 годом. Не подозревал что это гуано настолько окаменевшее.

Не буду съезжать на то,что Win64 != Win16, легаси там всегда было полные карманы. Так что «был неправ, выспылил» (с)

Не подозревал что это гуано настолько окаменевшее.

Настолько окаменевшее, что ни один тулкит Линукса не умеет многопоточный GUI, а Win32 (1993, Windows NT 3.1) умеет. В X11 нет синхронизации отрисовки, а в Win32 есть (BeginPaint/EndPaint).

Не буду съезжать на то,что Win64 != Win16, легаси там всегда было полные карманы.

Не бывает Win64, есть только Win16 и Win32. Они отличаются моделью памяти (в Win16 сегментная память общая для всей системы, а в Win32 линейная память своя для каждого процесса) и многозадачности (в Win16 кооперативная многозадачность, а в Win32 полноценные потоки). Для 32 и 64 бит используется один и тот же код Win32. Существует возможность писать код, который будет компилироваться под Win16 и Win32. В 64 битах ничего принципиально нового нет, просто размер указателя увеличили и регистров добавили.

Win16 программы 1985 года до сих пор можно запустить даже на 64 битной системе с помощью winevdm. А в Линуксе постоянно что-то ломают.

Что вы делаете на Лоре? Линукс плохой, Окна хорошие.

Вас послушать, так надо бежать венду ставить, там такое шикарное апи.

с чего он взял, что Microsoft будет что-то портировать? просто навернут свою сборочку Debian (они так уже делали для своих «умных» свитчей) и будут продавать поддержку.