Microsoft не будет делать Lindows

Портирован.

Есть есть, только чет без winapi и наверное ещё чегой-то: https://docs.microsoft.com/en-us/windows/iot-core/windows-iot

Нет такого продукта на рынке как NT Kernel.

И WinAPI тоже нет на рынке.

Криворукие маркетологи.

Криворукие маркетологи распорядились перенести часть графики внутрь NT Kernel и инженеры Microsoft, разрабатывающие Windows, тут же подхватили и реализовали эту идею? Серьёзно?

А я-то думал это какие-то проблемы у них были с быстродействием и производительностью этой самой графики на слабом потребительском железе тех лет.

Вопрос лишь в том, почему сейчас графика всё ещё в ядре.

И WinAPI тоже нет на рынке.

Есть документация на API, SDK и много реализаций, включая Wine. Полная документация и SDK для ядра NT публично не доступна. Есть только ограниченная документация для написания драйверов.

Ну так мухи отдельно, котлеты отдельно.

Я стараюсь добиться какой-нибудь внятной аргументации по вопросу: почему NT Kernel могут заменить в пользу Linux? Пока все аргументы выглядят довольно странно.

А можно пруфец, просто про windows 10 core я слышал, и это слегка маркетинговый булшитец в плане того, что это та же платформа, как раз тот случай когда только UI и часть рантайма реализована, при этом как раз в этом случае подмену ядра - вообще никто бы не заметил, и не факт что там не бсд который обозвали NT, т.к. можно. Хотя ход то конечно весьма грамотный, анально огороженный более актуальным зондец, аля андроид.

А вот про сервер - как-то мимо меня прошло, что есть непорядок.

Windows Server портанут на ARM и используется Microsoft в Azure, так просто его не выкладывали.

Есть только ограниченная документация для написания драйверов.

Но она есть. И на её основе построен огромный рынок PC-железа.

А что там с графикой в ядре-то? Какой смысл держать это там сейчас? Внятная аргументация от MS была какая-то по этому вопросу?

Серьёзно?

Да, серьёзно. Если бы не было криворуких маркетологов, все серверы бы давно работали на ядре NT, а Linux был бы маргинальной поделкой.

А я-то думал это какие-то проблемы у них были с быстродействием и производительностью этой самой графики на слабом потребительском железе тех лет.

Для слабого железа была линейка Windows 9x. Никто не мешал продолжаться ей пользоваться на слабом железе, а когда выпустят подходящее железо, перейти на Windows NT с нормальной архитектурой графической подсистемы. Но криворукие маркетологи спешили продавать Windows NT повсюду и по их требованию испоганили архитектуру с которой живём по сей день.

Да, серьёзно. Если бы не было криворуких маркетологов, все серверы бы давно работали на ядре NT, а Linux был бы маргинальной поделкой.

Для этого им пришлось бы стать вторым линуксом, иначе его место заняла бы FreeBSD.

Мне конечно как до марса до cto, тем более таких компаний, но давай подытожим:

• есть эксперимент, где используются только портабельные на другие ядра рантаймы(windows10 iot core), тут явно никто бы не заметил подмены ядра
• нет смысла поддерживать ядро, когда можно не поддерживать, даже если пара банков и крупных вендоров глючного легаси поплачет по этому поводу (простых смертных не рассматриваем от слова совсем, тут баги закрываются очень просто - закончился срок поддержки)
• куча инженеров и маркетологов кукарекают какой виндоус говно, а линукс няшка, особенно в облаках и на серверах, да и на архмах - ну чего бы не съехать с дорогостоящих работ, да ещё и сказать - смотрите, теперь мы тоже няшка, но ещё и работает всё, что до этого было написано по нашим гайдлайнам и портированно в срок с устаревших технологий типа WinAPI

Типа того, я думаю это как раз POC и эксперимент, как много типовых пользователей вообще будут возмущенны. Под пользователями тут я понимаю скорее поставщиков и разработчиков ПО.

Какой смысл держать это там сейчас?

Скорее всего требуется слишком много работы для переноса win32k.sys в пользовательский процесс. Там скорее всего полно старого кода, авторы которого давно уволились и никто не знает как от работает и боятся сломать. Проще на Wine перейти.

Ага. И чем шире и доступнее становится пингвин, тем более вероятна для него такая же судьба. Особенно если за разработку возьмутся ради бабла.

Кратко почему такого не будет: линукс до сих пор неработоспособен на среднестатическом пк/ноуте младше трёх лет

Всё так.

То есть уже лет 20 как?

А вот про сервер - как-то мимо меня прошло, что есть непорядок.

Например:

https://pureinfotech.com/windows-server-arm-processors/

Но что-то ARM не особо на серверах приживаются, так что MS пока временит выкатывать эти порты в релиз.

Есть есть, только чет без winapi

По ссылке, которую я привёл, Windows 10 с графикой и WinApi на Raspberry Pi 4. Есть скриншоты. Можно запускать сторонние Win32 программы, перекомпилированные под ARM. Образ можно бесплатно скачать отсюда (насколько я понимаю легально).

А чё где подробности про потроха, доступные рантаймы и прочее? Не удивлюсь, если там тоже только .net core + UWP будут доступны в качестве среды исполнения. Допускаю, что там внутре - будет как-то портированное NT, но тут же вопрос - схавает ли пипл, если пипл схвает - то смысл NT встаёт под вопрос: начинаем активно чмырить x86_64 и всячески поддерживать armv8(вследом за Apple кстати), и профит - все сидят на дотнетах, кроме древних энтерпрайзов, которые на lts ещё мильён лет и так будут сидеть, оракль плачет в углу или пишет джаву на дотнетах. Но, развивать NT - больше не нужно, проще любить linux и быть няшей. Не зря MS говорит, что они любят linux а не gnu/linux ;)

Блин, такую красивую теорию обломал своими мерзкими фактами.

есть эксперимент, где используются только портабельные на другие ядра рантаймы(windows10 iot core), тут явно никто бы не заметил подмены ядра

И Microsoft для этих целей делает порт NT Kernel на эти IoT, продвигает его, а не стряпает Microsoft GNU/Linux distro. Это не похоже на аргумент в пользу предстоящей замены NT Kernel на Linux.

нет смысла поддерживать ядро, когда можно не поддерживать

Microsoft’у точно так же придётся поддерживать ядро Linux, к тому же ещё платить за портирование и аккуратное натягивание WinAPI на него, а ещё на тестирование и причёсывание всего этого добра. И стоит заметить, что Windows развивается в несколько другую сторону (рабочие, игровые, офисные станции) и «тырить» серверные наработки RedHat (как это делает тот же Oracle, например), не получится. То бишь на поддержку Linux они будут тратить сопостовимые средства, а может и более. И это ещё не учитывая ГИГАНТСКИХ затрат на перенос и портирование того, без чего Windows никому нафиг не нужен.

даже если пара банков и крупных вендоров глючного легаси поплачет по этому поводу

Им пофиг. А плакать будут внезапно те, кто клепает PC-железо. И им такой подарок от Microsoft не особо впёрся.

куча инженеров и маркетологов кукарекают какой виндоус говно, а линукс няшка

Это на ЛОРе что ли?

смотрите, теперь мы тоже няшка, но ещё и работает всё, что до этого было написано по нашим гайдлайнам и портированно в срок с устаревших технологий типа WinAPI

Ну это вообще no comments.

Почему тогда в спеке MS написано, что uwp only:

App architecture supported UWP UI only Full Windows UI support (e.g. UWP, WinForms, etc)

И ещё ряд всяких ограничений имеется? Всё-таки, я бы глянул какой нить пруфец, где что-то типа 7z запускается на этой платформе.

Ядро NT имеет около 400 задокументированных системных вызовов

Вопрос сколько не задокументированных. Причём таких о которых не знает тот чел что написал ту статью по ссылке.

Microsoft не нужно переходить на Linux, чтобы оставаться актуальной… есть много ОС и платформ (Android, Ubuntu, iOS, macOS, Alexa, Chrome OS) + не только x86, но и ARM.

Ну и почему тогда WSL ? Где среда эмуляции ведроида или хром-ос ? У них, что, меньше пользователей чем у линукса ? Сделали-бы хотя-бы среду с freebsd уж тогда, сразу с поддержкой джейлов, во была-бы офигенная тема.

Но нет. У них опенсурс всё больше завязывается именно на линукс. .NET уже под линуксом работает не хуже (не считая, WPF, конечно), скоро, глядишь, HYPERV увидим нативный в ядре. На фоне других новостей о венде, логично думать что своё будущее в долгосрочной перспективе M$ связывает не с ней уж точно.

Допускаю, что там внутре - будет как-то портированное NT

Лол. То есть ты уже можешь допустить, что в Windows Server будет Linux или FreeBSD Kernel?

Какие-то детские аргументы, вот уж прости. Зачем всё это, если достаточно выпустить Microsoft Linux с уже портированным .NET Core, PS и т. д.

P.S. UWP это же про прикладные приложения. Для чего они в порте Windows Server на ARM не совсем понятно.

WinForms под капотом использует WinAPI

Всё-таки, я бы глянул какой нить пруфец, где что-то типа 7z запускается на этой платформе.

IoT это не про 7z, а вот WinRT – пожалуйста

https://www.reddit.com/r/Surface/comments/dx1vmz/7zip_compiles_easily_on_arm_for_use_on_surface/

Всё-таки, я бы глянул какой нить пруфец, где что-то типа 7z запускается на этой платформе.

Вот например.

Так конечно это нельзя разом сделать. Надо сначала на старом ядре проверить, что если оставить только наиболее портабельные рантаймы, большинство пользователей не почувствует разницы, собрать обратную связь так сказать.

Что дороже поддерживать порты NT или нужные патчи в апстрим linux пропихивать, вопрос сложный, но в случае linux ещё как минимум какое-то время это будет с теми же гуглами пошарено как минимум не?

У меня видимо ложная предпосылка в самом начале моих рассуждений, я чет был уверен, что на десятке под IoT - нет winapi. Если это и правда не так - то план и правда уже менее правдоподобен, т.к. из мотивации остаётся только удешевление поддержки, за счёт отказа от своего закрытого ядра.

В общем вы сэры меня заставили усомниться, хотя я пока всё равно не могу сопоставить допилку открытого shim и поддержку 2+ закрытых версий ядра ОС. Кажется что первое - ощутимо прям дешевле, чем второе, да ещё и более прогнозируемо в случае всяких рисков типа «а теперь модно на mips».

Так зачем кому-то нужен Microsft Gnu/Linux, ну по крайней мере на десктопе, если ты про это? Вот Microsoft Linux лично я бы потыкал например, но это не в пример сложнее если оставлять [полную] совместимость.

IoT это не про 7z, а вот WinRT – пожалуйста

Окак, т.е. плюсы и совместимое подмножество C можно собрать под новую реинкарнацию managed C++, т.к. оно совместимо на уровне сорцов, или я не так понял?

… большинство пользователей не почувствует разницы в смене ядра …

Пользователи не почувствуют разницы, а вот рынок PC-железа, один из столпов популярности Windows, почувствует и покрутит пальцем у виска.

Так зачем кому-то нужен Microsft Gnu/Linux, ну по крайней мере на десктопе, если ты про это?

Я как раз про то, что на десктопе Microsoft Linux не нужен, а вот на серверах и IoT это бы имело какой-либо смысл, учитывая что все ключевые технологии уже портированы.

Но видно следующую ситуацию: Microsoft довольно активно разрабатывает, поддерживает и продвигает сборочки с NT Kernel под ARM. Все эти IoT, WinRT и пр. Microsoft ведёт переговоры с главным вендором и паровозом ARM – Qualcomm по поводу портирования Windows Server (на NT Kernel конечно же) на будущие ARM-сервера, если они выстрелят. Всё это никак и никоим образом не похоже на предпосылки по замене NT Kernel на Linux.

можно собрать под новую реинкарнацию managed C++, т.к. оно совместимо на уровне сорцов, или я не так понял?

7z, насколько я знаю, чистое WinAPI-приложение. Может быть чуть MFC-шное. WinAPI в портах Windows на ARM представлен в полном объёме.

Точно так же, как было и в прошлом тысячелетии, когда семейство операционных систем Windows NT работало на PowerPC, MIPS, Alpha AXP, Itanium, Intel i860

В не полном объёме WinAPI может быть представлен разве что в Windows IoT и Windows Server, по вполне понятным и разумным причинам.

Да WinRT крайне интересная штука, дающая много степеней свободы для MS если удастся всех разработчиков пересадить с winapi. А всякие проекты типа boost - уже совместимы?

Так там же было не NT а CE?

если удастся всех разработчиков пересадить с winapi

Зачем пересаживать, если WinApi прекрасно работает на ARM?

А всякие проекты типа boost - уже совместимы?

Почему им не быть совместимыми? Компилятор C++ от Microsoft и clang умеют компилировать под Windows ARM.

Под совместимостью я тут понимаю что вместо какого нить waitforsingleobject используется какой нить system.semaphor.wait прямо в кодовой базе boost.

Если нет - то boost совместим с winapi а не с winrt, и если winrt уйдёт в своём бэкэнде от связки winapi + com, то на платформе только с winrt - boost не соберётся.

Зачем пересаживать, если WinApi прекрасно работает на ARM?

А зачем поддерживать два рантайма, если со временем можно начать поддерживать только один?

Под совместимостью я тут понимаю что вместо какого нить waitforsingleobject

WaitForSingleObject никто не убирал в Windows ARM.

Minimum supported client: Windows XP [desktop apps | UWP apps]

используется какой нить system.semaphor.wait прямо в кодовой базе boost.

Это всё обёртки над WinApi.

Так вот почему у тебя такая странная аргументация. Ты видимо совсем не в курсе про историю Windows NT. Смотри, под какие архитектуры она была доступна:

Windows NT 3.x

https://winworldpc.com/product/windows-nt-3x/351

m68k, x86, PowerPC, MIPS, Alpha AXP

Windows NT 4.0

https://winworldpc.com/product/windows-nt-40/40

x86, PowerPC, MIPS, Alpha AXP

Ну и ещё был Itanium и i860.

CE

Это вообще отдельная песня. И WinCE тоже поддерживал огромное количество архитектур, со ставкой на те, что используются в Embedded: x86, 32-bit ARM, SuperH, MIPS and PowerPC.

А зачем поддерживать два рантайма, если со временем можно начать поддерживать только один?

UWP работает поверх WinApi. Оно не является независимым.

Синонимом стала ветка Win95+ (линейка никак не защищенных графических оболочек над DOSом). NT — совсем другая система. И то что привычки из «винDOSа» юзеры принесли с собой на хрюшу — и взяли моду сидеть под админом — немножко не инженерная, а социальная проблема.

графических оболочек над DOSом

Хватит уже эту дезинформацию распространять.

NT — совсем другая система.

Ничего принципиально другого там нет.

Я уже понял, что не убирали winapi, да. И что сейчас winrt это обёртка над winapi. Вопрос - зачем нужен winapi, если есть winrt? Кроме, поддержки легаси разумеется. Если плавно давать по рукам (например публиковать версии приложений не под winrt с задержкой в сторе), то можно со временем от одного из рантаймов избавиться, оставить более продуманный и портабельный рантайм, и забыть наконец-то COM, первые версии которого всякие OLE32 и т.п. вообще были тем ещё позорным позором.

Ядро NT имеет около 400 задокументированных системных вызовов плюс около 1700 задокументированных вызовов API Win32, есть сомнения в том что это все можно будет перенести без проблем с совместимостью.

Я, как опытный быдлокодер, заявляю, что это фигня. Переписывается всё на раз. Отвлекают народ, а потом скажут, что «Времени то много прошло, мы попробовали и у нас получилось...».

Вопрос - зачем нужен winapi, если есть winrt?

Мне скорее интересно зачем нужен WinRT/UWP, если есть WinApi? Программ на WinApi полно, а под UWP практически никто не пишет а магазин приложений полупустой. Никаких преимуществ UWP я не вижу, кривая тормозная поделка, жрущая ресурсы, слизанная с iOS/Android. На десктопе не нужно.

Если плавно давать по рукам

…то настанет вендекапец и все перейдут на Wine.

и забыть наконец-то COM

WinRT/UWP вообще-то на COM основан.

Так вот почему у тебя такая странная аргументация. Ты видимо совсем не в курсе про историю Windows NT. Смотри, под какие архитектуры она была доступна:

Поучительно, на самом деле - был не в курсе. Единственное, что меня смущает тут это «была». Если поддержка под разные архитектуры была, но потом пропала, значит было дорого однако, ну или супер просто её реинкарнировать, либо она просто из публично заявленных фич была исключенна. В том же онтопике те ещё калькуляторы доисторические поддерживают насколько я знаю(тут тоже плохо ориентируюсь на самом деле), потому-что недорого и условно пофик - нашёл проблему в поддержке экзотической платформы - ну это, друг, неси патчи.

Ничего принципиально другого там нет.

Кроме ядра.

Кроме ядра.

В Windows 9x было ядро VMM.VXD, которое умело всё тоже самое, даже драйверы от NT работали.

Я тебе про фому, а ты мне про ерёму:)

Да winrt основан на com, это значит, что если оставить интерфейс winrt но заменить com, да даже просто убрать из публичных API/ABI, приложения которые не используют com, но полностью совместимы с winrt продолжат работать. То же самое с winapi.

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

Если поддержка под разные архитектуры была, но потом пропала, значит было дорого однако,

Это не дорого было, а все эти архитектуры обосрались и ушли с десктопного рынка. За этим ушла и их поддержка в Windows NT. А когда снова что-то такое потребовалось, Windows NT без проблем спортировали на сегодняшние современные ARM’ы.

Да winrt основан на com, это значит, что если оставить интерфейс winrt но заменить com

Нельзя заменить COM, он является неотъемлемой частью публичных интерфейсов. Само API во многом объявлено через COM. Убирать COM Microsoft не планирует. А реализация COM привязана к невидимым Win32 окнам для обработки сообщений. DirectX и DXGI, которые необходимы для UWP, тоже основаны на COM и предоставляют публичные COM-интерфейсы.

Но почему бы не попробовать если ресурсы позволяют?

Уже давно пробуют, а толку мало. Видимо ресурсы не позволяют.

Но почему бы не попробовать если ресурсы позволяют?

Зачем? Зачем нужно избавляться от столпа WinAPI? Зачем нужно избавляться от довольно неплохого NT Kernel, который поддерживает кучу железа? Потому что какой-то хипсто-инженер посмотрел и сказал «не модно, закапывайте, вот у нас в Linux’е няшки»?