За последние пару недель Microsoft сделала несколько объявлений, которые частично полностью изменили прошлые направления разработки Windows. Короче говоря, Microsoft преуменьшает (если не полностью отказывается от поддержки) модель универсальной платформы Windows.

Вот несколько соответствующих ссылок:

• Microsoft публикует сведения о миграции с UWP на Win32, но, вероятно, это не то, что вы думаете  https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details
• UWP больше не в моде, поскольку Microsoft выпускает руководство по миграции приложений на Windows App SDK  https://www.neowin.net/news/uwp-no-longer-fashionable-as-microsoft-releases-guidance-for-migrating-apps-to -windows-app-sdk /
• Microsoft официально прекращает поддержку UWP  https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp

UWP была центром разработки приложений для Microsoft с момента выпуска Windows 8 и сменила акцент на архитектуре .NET как платформе разработки Windows.

Это очень интересная эволюция с точки зрения разработчиков (и поставщиков средств разработки, таких как Embarcadero), которые по-прежнему сосредоточены на классической нативной модели разработки Windows, поскольку мы снова стали первоклассными гражданами спустя очень долгое время.

От собственного к .NET и UWP

В течение многих лет собственная модель разработки, основанная на использовании классического Windows API и использовании трех основных библиотек Kernel / User / GDI и всех их расширений, считалась устаревшим подходом, от которого вскоре отказались. Это классическая модель, используемая Delphi и C ++ Builder (с библиотекой VCL), но также и Visual C ++ (с библиотекой MFC).

Разработчикам Windows сначала было предложено перейти на .NET (с мыслью, что API-интерфейсы будущих платформ потребуют .NET, а классические приложения в какой-то момент перестанут работать в Windows). Со временем стало ясно, что этого не произойдет.

По мере того, как фокус на .NET снизился, Microsoft начала продвигать следующую идею: универсальную платформу Windows. В первую очередь это было вызвано двумя идеями: во-первых, возможность запускать одно и то же приложение на настольном ПК, а также на телефоне с Windows, игровой консоли и технологии визора; во-вторых, более безопасная платформа с ограниченным доступом к базовой операционной системе. На уровне API поддержка UWP подразумевала использование API платформы WinRT, которые отличались от классических API и несовместимы с ними.

UWP не успела наверстать упущенное. Для Delphi и RAD Studio не было возможности, но также миграция с Visual C ++, .NET и C # потребовала бы использования разных библиотек времени выполнения и различных элементов управления пользовательского интерфейса, что потребовало бы большого переписывания существующего приложения. Когда Windows 8 впервые вышла (все еще позволяла классические приложения API), было очень мало приложений UWP, в том числе от Microsoft. Однако некоторые из новых функций платформы были доступны только через WinRT API, поэтому разработчики и инструменты (включая RAD Studio) придумали варианты для вызова WinRT API из классического приложения. Так, например, реализована поддержка уведомлений Windows в RAD Studio.

В то время как Microsoft продолжала настаивать на UWP, указывая на то, что классические приложения будут устаревшими, разработчики особо не прислушались. Следующим шагом было продвижение так называемого «моста рабочего стола», то есть возможности для собственных приложений использовать больше API-интерфейсов WinRT и быть «упакованными» в легкий контейнер для дополнительной безопасности. Эта последняя функция была достигнута путем упаковки приложения как APPX, а затем MSIX. Опять же, RAD Studio уже давно предлагает эту поддержку прямо в IDE.

Изначально Microsoft описала мост как способ помочь перенести приложения на UWP, что по-прежнему было целью компании. Разработчики могли перемещать свои приложения по одной форме за раз. Быстро стало очевидно, что у разработчиков нет реального интереса к преобразованию своих больших кодовых баз, но они заинтересованы в использовании всех функций платформы. APPX и MSIX также открыли двери Microsoft Store для традиционных приложений.

Перенесемся в прошлый год или около того. Microsoft анонсировала Project Reunion (теперь переименованный в Windows App SDK) с целью предложить полную совместимость приложений UWP для вызова собственных API-интерфейсов и собственных приложений для вызова любого API-интерфейса UWP, но в итоге предоставила поддержке собственных приложений гораздо более высокий приоритет с помощью UWP. теперь осталось позади — на что указывают объявления выше.

Вернуться к родному

Другими словами, по прошествии более 15 лет, в течение которых Microsoft рассматривала нативные приложения Windows как приложения второго класса, которые вскоре должны стать гражданами, мы теперь полностью изменили эту позицию. Нативные приложения или классические приложения API никуда не денутся, и им будет отдан приоритет в контексте модернизации, поддержки новых API, поддержки Windows 11 и т. Д. Microsoft планирует принести согласия и API UWP в родной мир.

Это все чаще происходит, например, с элементом управления WebView 2 (встроенный Chromium Edge, который Delphi и C ++ Builder обертывает и поддерживает), компонент COM. Другие новые API-интерфейсы также используют COM, в то время как другие являются собственными, а некоторые основаны на WinRT, но доступны из собственных приложений.

Если собственная модель API останется, это отличная новость для Delphi и C ++ Builder. Этой модели Embarcadero всегда уделял первостепенное внимание (ну, за исключением короткой эры Delphi .NET), но это также модель, которую мы расширяли и расширяли с течением времени намного больше, чем наши конкуренты. свои библиотеки.

Если вы рассмотрите альтернативные инфраструктуры пользовательского интерфейса, которые используют классический API, такие как библиотека MFC или библиотека WinForms, они получили гораздо меньше внимания и улучшений со стороны Microsoft, чем библиотека VCL. От дополнительных элементов управления пользовательского интерфейса до встроенных элементов управления WinRT и Reunion, от поддержки высокого разрешения до стиля пользовательского интерфейса — библиотека VCL продолжает расширяться с гораздо большей скоростью, чем конкурирующие собственные библиотеки.

Вот почему сегодня RAD Studio снова позиционируется как лучшее доступное решение для создания собственных клиентских приложений Windows. Более того, он предлагает удивительно простую миграцию для кодовых баз возрастом 10 или 20 лет, не имеющую аналогов в других предложениях.

Приятно быть разработчиком Delphi и C ++ Builder и создавать первоклассные приложения для Windows, теперь даже не опасаясь, что Microsoft откажется от модели приложения в следующей версии Windows.