Travis_Macrif29 мар в 07:35

Microsoft планирует создавать полностью нативные приложения для Windows 11

2 мин

9.7K

СофтWindows * Управление продуктом * Операционные системы

+10

Комментарии 16

natan555 29 мар в 07:41

Может в их подведомственном ЗАГСе, что то поправить, и начать со смены концепции присвоения имён переменным, а то с именами спикеров-руководителей беда какая-то

DanielKross 29 мар в 07:48

Скоро виндоус сама станет вэб-приложением 8)

Pascal1990 29 мар в 07:50

Ого, микрософт изобрёл нативное приложение. Новости, которые мы заслужили.

А теперь представьте, как эта новость читалась-бы году эдак в 2000. Мир с каждым годом становится всё более **анутым.

Mike-M 30 мар в 12:06

Поддерживаю. Действительно нативное приложение должно быть полностью построено не на WinUI, а на С++.
К слову, Калькулятор — единственное UWP-приложение, которым я пользуюсь.

ic10 29 мар в 07:59

полностью нативные приложения для Windows 11

Подразумеваются приложения на C#?

VBDUnit 29 мар в 10:00

Раньше под этим подразумевалось что‑то типа WinAPI/C++/MFC. Что сейчас подразумевается непонятно, но есть шанс что нужно будет две RTX 5090 чтобы панель задач меньше тормозила.

MrB4el 29 мар в 08:04

А у MS остались еще те, кто способен в это? Сложилось впечатление, что там превалирует большинство ребят из Индии, могущим только в ~~формашлёпство~~ JavaScript. Или они просто свой сосай-алот обучили шарпам адекватным?

V1tol 29 мар в 18:31

Подписку на ИИшенку купили - она за них напишет.

Black_Spirit 29 мар в 08:31

То есть, опять outlook перепишут

ImagineTables 29 мар в 08:38

Действительно нативное приложение должно быть полностью построено на фреймворке WinUI

Действительно нативное приложение должно быть полностью построено на вызовах WinAPI. Тогда оно будет запускаться на чём угодно¹. Но поскольку так новый Windows не продашь, «старые нативные приложения» были объявлены устаревшими, а затем придуманы «новые нативные приложения» (которые, кстати говоря, как и веб-приложения, тоже построены вокруг разметки). Тем самым Майкрософт преподал разработчикам важный урок: рано или поздно придёт пора впаривать новый Windows, и в этот момент появятся ещё более новые «нативные приложения», а инвестиции в старые сгорят. Если же писать неудобно, на WinAPI (вариант: писать на чём-то высокоуровневом, что потом транслируется в вызовы WinAPI), такие приложения, скрипя зубами, Майкрософт будет запускать ещё долго. (Когда перестанет, это испортит совместимость: многие корпоративные юзеры до сих пор сидят на MS Office 2003 и сопутствующем софте из тех времён, сам на днях видел. И если их толкнуть, изрядная часть упадёт не в сторону более новых версий Windows).

Идеально было бы устранить недостатки браузеров, из-за которых тормозят приложения на их основе. Например, избавиться от межпроцессного маршалинга. В нём нет абсолютно никакой технической необходимости: браузерам изоляция помогает защищать одни веб-страницы от других, а в приложениях один диалог не представляет² собой угрозы для другого. А вот тормозит это всё изрядно, поскольку каждый вызов, пересекающий границы процессов, очень дорогой. Можно убрать все нейро- и медиа-компоненты, грузить модули из файлов (не требуя наличия веб-сервера), оптимизировать потребление памяти под сценарий «загрузили и отрендерили окно». Проблема в том, что это никому не надо. Майкрософту это не надо потому, что так новый Windows не продашь, а создателю the браузерного движка это не надо потому, что он не хочет, чтобы вы писали приложения под Windows вместо веб-приложений, которые запускаются с сервера Гугл. Так и живём.

¹ Это, конечно же, мешает продавать новый Windows, поэтому Майкрософт поступает хитро: каждые несколько лет она выпускает новый компилятор C++, который поддерживает более новую (и фичастую) версию языка. Но он собирает код только под более новую версию Windows.

² У некоторых разработчиков представляет.