Подробно о Windows 10X: контейнеры, работа UWP и Win32 приложений
11 февраля на конференции для разработчиков Microsoft 365 Developer Day компания Microsoft поделилась некоторыми деталями о работе новой операционной системы Windows 10X. Также был представлен эмулятор для разработчиков, позволяющий оптимизировать приложения для устройств с двумя экранами.
Главная особенность Windows 10X заключается в том, что приложения запускаются в контейнерах. Подробнее остановимся на данной технологии и рассмотрим, какие типы приложений можно будет запустить на устройствах под управлением Windows 10X, таких как Surface Neo.
Три типа контейнеров для максимальной совместимости
Контейнеры представляют собой изолированные среды, которые абстрагированы от операционной системы, что позволяет лучше контролировать их поведение.
В Windows 10X абсолютно все приложения выполняются в контейнерах, которые являются частью архитектуры ОС. Разработчикам не нужно реализовывать какие-либо дополнительные изменения на высоком уровне для запуска приложений в Windows 10X.
Разработчики самостоятельно могут выбирать архитектуру своих продуктов: Win32, прогрессивные веб-приложения или UWP. По понятным причинам UWP-приложения лучше всего оптимизированы для Windows 10X, но Microsoft приложила много усилий, чтобы классические настольные приложения корректно работали в новой системе.
Контейнеры позволяют оптимизировать энергопотребление и производительность
UWP-платформа имеет наилучшую оптимизацию для Windows 10X. Это вполне логично, ведь UWP-приложения первоначально разрабатывались с учетом мобильной платформы Windows Phone (Windows Mobile). Такие приложения повышают безопасность и производительность, снижают энергопотребление и соблюдают меры энергосбережения операционной системы (переход и выход из спящего режима).
Приложения Win32 создавались преимущественно для настольных компьютеров. Им недостает мобильной оптимизации, как у UWP. Классические приложения, как правило, являются более функциональными, чем UWP, но хуже влияют на время автономной работы и скорость работы системы. В любом случае, даже в 2020 году приложения Win32 играют важную роль в современных компьютерных вычислениях.
Microsoft решила «исправить слабые стороны» приложений Win32 (и MSIX) с помощью контейнеризации:
В свернутом состоянии приложения Win32 и MSIX не будут работать в фоновом режиме. Данная мера позволяет экономить системные ресурсы и заряд аккумулятора. И наоборот, когда приложения Win32 активно используется, они выделяют больше ресурсов для высокой производительности.
Существует два последствия такого поведения. Во-первых, классические приложения Win32 не смогут выполнять фоновые задачи. По крайней мере длительные задачи до приостановки контейнера. Во-вторых, приложения Win32 не смогут автоматически запускаться в Windows 10X. В Windows 10X нет системного трея, поэтому классические приложения не смогут непрерывно работать в фоновом режиме.
Примечательно, что Microsoft может позволить контролировать это поведение самому пользователю. В этом случае, контейнеры с Win32 приложениями смогут работать в фоне. Однако, окончательное решение еще не принято.
Наконец, из-за особенности архитектуры контейнеров Win32 и MSIX, антивирусные системы либо будут совсем не нужны, либо будут иметь множество ограничений, что опять же приведет к повышению производительности и увеличению времени автономной работы.
Все будет работать корректно
Интересно, что контейнеризация приложений Win32 не скажется на их функциональных возможностях. Microsoft заявляет, что эти классические приложения получат полный доступ к следующим компонентам:
Это означает, что старая модель «Plug and Play» сохранится, и на Surface Neo можно будет использовать все, что вы к нему подключите, включая внешние мониторы и периферийные устройства.
Так как в Windows 10 отсутствует системный трей, то классические приложения не смогут его использовать, что, тем не менее, не должно привести к проблемам стабильности. Microsoft сообщает, что Win32 приложения cмогут работать «как есть» (то есть без изменений в реестре), но из-за контейнеризации программные вызовы никогда не коснутся ОС. Компания заявляет, что ограничения, наложенных контейнером Win32, не должны приводить к сбоям.
Два Проводника
Приложения Win32 все еще могут использовать «классический» Проводник Windows и привычное диалоговое окно для выбора файлов в масштабе всей системы, включая доступ к системным папкам. Эта функция является ключевой для приложений Win32, которые предназначены для открытия, обработки и сохранения файлов.
Однако, при вызове диалогового окна работы с файлами в UWP-приложениях или в самой системе Windows 10X откроется «современный» Проводник Windows (Modern File Explorer), который ограничен необходимыми библиотеками, такими как Видео, Музыка, Избранное, Документы, Изображения и др.
Это значит, что пользователи получают базовый уровень доступа к основным системным библиотекам, но не смогут обращаться к основной файловой структуре на уровне ОС, как в любой настольной системе Windows. Опять же, приложения Win32 будут корректно работать без какого-либо изменения кода.
Приложения запускаются в развернутом режиме
Корпоративный вице-президент Microsoft Developer Platform, Кевин Галло (Kevin Gallo) рассказал, что в настоящее время все приложения в Windows 10X работают в полноэкранном режиме (т.е. развернуты на весь экран). Это похоже на то, как приложения запускаются в Windows 8 или в планшетном режиме в Windows 10.
Причиной такого выбора является размер экрана: чем меньше дисплей, тем больше «плотность» отображаемой информации. Запуск пяти приложений с маленькими окнами на одном 9-дюймовом дисплее вряд ли будет популярным сценарием.
Данная тема является спорной, и Microsoft открыта к диалогу по данному вопросу. Если разработчики захотят работать с мелкими окнами, то компания может разрешить это.
Итог: Windows 10X является технически сложной системой, но простой для пользователя
Microsoft спроектировала Windows 10X таким образом, чтобы она была нейтральной для приложений, независимо от архитектуры: Electron, UWP, Win32, WinForms, WPF. Все эти приложения уверенно запустятся на Windows 10X без существенных изменений в коде.
По сравнению с обычной Windows 10 Microsoft изменила не только дизайн, но и основный приоритет:
Конечно, это условная классификация, но Windows 10X построена так, чтобы быть быстрой, гибкой, мобильной и безопасной. Уже известно, что обновление ОС должно занимать не более 90 секунд. Данное преимущество связано с тем, что Windows 10X построена на замкнутой и ограниченной природе UWP, как и HoloLens.
В любом случае, владельцы Surface Neo смогут устанавливать любое приложение по желанию, и ожидаемое поведение будет соблюдено. У разработчиков также не нужно вносить существенные изменения в свои продукты.
Галло подчеркивает, что приложения, оптимизированные для работы с двумя экранами, также должны обеспечивать лучшее взаимодействие с настольными системами Windows 10. Это яркий пример преемственности Windows 10X и Windows 10.
Как все будет работать на практике, пока неизвестно. Microsoft утверждает, что разница в производительности между приложениями Win32 и UWP в Windows 10X не должна быть заметна для пользователей. Мы вступаем в новую эру мобильных ПК, где пользователям не придется идти на компромиссы.
Примечание: Большая часть данной информации основана на демонстрационном видео «How Windows 10X runs UWP and Win32 apps» показанном на Microsoft 365 Developer Day.
Приступая к работе с приложениями для Windows 10
Создавайте приложения, которые работают на всех устройствах с Windows 10, или улучшайте существующие приложения с помощью новых и обновленных функций.
Сведения о приложениях для Windows 10.
Windows 10 и универсальная платформа Windows позволяют создавать приложения, которые прекрасно работают и выглядят на всех типах устройств с Windows, или обновлять существующие приложения с помощью современных функций.
Подготовка
Visual Studio Community и пакет SDK для Windows 10 содержат все необходимые инструменты для разработки превосходных приложений, причем это абсолютно бесплатно!
Начало разработки
Независимо от того, являетесь ли вы опытным разработчиком или просто создаете свое первое приложение, вы можете получить помощь по платформе Windows 10 и доступ к учебной документации.
Учебники
Вам нужно пройти пошаговое обучение с практическими примерами? Эти руководства помогут вам.
Примеры
Научитесь на личном опыте работать с платформой Windows 10 и оцените возможности интерфейсов API в действии.
Новые возможности
Расширьте свои возможности и изучите последние изменения в Windows 10.
Почему Windows 10 UWP это будущее. Или зачем он нужен.
Чтобы программы могли корректно взаимодействовать с операционной системой, для этих программ нужна SDK, по которой они будут работать. UWP решает эту задачу, а также решает множество других проблем Windows.
Что сейчас в Windows?
В Windows сейчас хаос. Приложения можно писать на нескольких фреймворках:
По сути Win32Api не является фреймворком, а приложения написаны на «неуправляемом» коде, с максимально близким доступом к ОС. Win32Api это лишь набор функций + обертка для точки входа в приложение.
UWP приложения пошли дальше. Кроме расширенного SDK, с доступом к магазину Windows, такие приложения теоретически могут работать на всех платформах Windows и на архитектурах, как x86, так и ARM.
Что хотят в Microsoft?
По моему мнению, Microsoft проспала момент с продажей и рекламой приложений через интернет, но конкуренты в лице Apple и Google не дремлют. У macOS есть удобный магазин, такой же магазин есть и у Google Android. Представьте, если бы вам пришлось приложения для смартфона искать по разным сайтам. Удобно ли это? Вряд ли.
Microsoft хотят сделать тоже самое. Дать возможность людям скачивать приложения прямо из магазина Windows.
Но почему бы не сделать это для всех старых приложений? Я не знаю. Я думаю, все эти приложения не поддаются какому-либо контролю, имеют сотни инсталляторов и пишут свои файлы во все места ОС. С UWP все эти проблемы решаются. Хотя они могли бы попытаться это сделать. Тогда была бы полная победа Windows.
Правда Microsoft делают это крайне медленно. Даже в Windows 10 большая часть приложений не являются UWP. А те приложения, которые являются UWP, выглядят немного чужеродно. Все знают про две панели управления, два калькулятора и так далее.
Microsoft своими вялыми действиями не подталкивают серьезных разработчиков к созданию UWP приложений или портированию уже существующих. Результаты бездействия мы можем наблюдать в магазине:
В магазине Windows 10 в основном представлен один «шлак». Серьезные компании не стремятся переводить свои продукты на UWP.
Почему текущий подход к написанию приложений должен умереть?
1) Неконтролируемый доступ к железу.
UWP частично решает эту проблему, разграничивая права пользователей. Этот подход был полностью скопирован с Google Android и macOS/iPhone.
Если система может ограничивать доступ приложения к определенным компонентам железа или операционной системы, то мы можем увидеть список разрешений:
Тут я побуду адвокатом Windows 10, которую часто обвиняют в шпионаже. Как мне кажется, Windows 10 наоборот, пытается защитить ваши данные, разграничивая права приложений. Хотя тут можно сказать, что они просто не хотят с этими данными делиться 
И если вы установили приложение, а оно начнет рассылать СМСки, то уж сами виноваты. Магазин вас предупредил. Сейчас мы устанавливаем любое приложение Windows на свой страх и риск. Оно может собирать любые данные с компьютера, а мы даже не узнаем об этом. Но здесь Microsoft наступила на грабли, сделав пункт: разрешить полный доступ ко всем компонентам Windows. И разработчики ставят этот пункт, особо не разбираясь, что к чему. Например, этим страдает Telegram.
2) Приложения написаны с использованием разных технологий.
В нормальной системе приложения написаны с помощью единых инструментов. К примеру, для Android это Java + Android SDK. Нет, есть конечно ненормальные, которые пишут приложения на Qt / C# / HTML5 приложения для Android, но внутри они всё равно используют Android SDK. Без него никуда.
Что даст переход на UWP?
Переход на UWP даст более тесную интеграцию с системой, можно будет использовать уведомления на полную мощность, обмениваться данными между приложениями. Писать приложения под все платформы, при этом ядро приложения будет единым.
WPF, UWP, WinUI, MAUI, Windows App SDK
Вот уже года 3 Microsoft проводит «рефакторинг» в своём «королевстве». Несколько устав видеть одни и те же споры в твиттере, и оставлять одни и те же комментарии на хабре, я решил расписать как же многочисленные UI-фреймворки MS соотносятся между собой. Кто из них больше мёртв. Возможно, кому-то это поможет в выборе технологии для будущего проекта.
Windows API и Windows Runtime
Прежде чем начать разбираться с UI-фреймворками стоит сначала опуститься на уровень ниже, впрочем, без особых подробностей. В современной винде 2 основных API для работы приложений. Windows API (обычно сокращается до Win32) и Windows Runtime (WinRT). При разработке первый был ориентирован на язык С, и активно развивался вплоть до выхода Windows 8. Я не имею в виду, что этот API объявлен устаревшим, но все новые функции системы уже разрабатывются для WinRT. Хотя некоторые так же бекпортируются и в Win32. Приложения, которые работают через Win32 и используют его модель приложений и сервисов Microsoft называет классическими.
Ключевое: есть объектно-ориентированные метаданные, которые описывают публичный интерфейс библиотеки: поддерживаются базовые классы (числа, строки), асинхронность (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.
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?
MAUI — абстракция над нативными UI-фреймворками.
Собственно, на винде это будет абстракцией над WinUI. У Xamarin.Forms есть поддерживаемая сообществом реализация поверх WPF.
Аналогичным образом ReactNative for Windows так же является абстракцией поверх WinUI. На нем, кстати, написан магазин на Xbox.
Подытожим
UWP — название подмножества API Windows, но часто используется как сокращение для изолированных приложений, работающих на этом API.
WinUI — современный графический фреймворк для Windows
Windows App SDK — в перспективе, единый набор SDK для любых приложений на Windows, вне зависимости от языка, и с возможностью переключения между различными жизненными циклами приложений
Обзор приложений на Windows клиентских устройствах
Относится к:
Перед началом работы
По мере того, как организации становятся более глобальными, и для поддержки сотрудников, работающих из любого места, рекомендуется использовать поставщика управления мобильными устройствами (MDM). Поставщики MDM помогают управлять устройствами и помогают управлять приложениями на устройствах. Для Корпорации Майкрософт это включает использование Microsoft Endpoint Manager. Endpoint Manager включает Microsoft Intune, которая является облачной службой, и Configuration Manager, которая является локальной.
В этой статье мы упоминаем эти службы. Если вы не управляете устройствами с помощью поставщика MDM, вам могут помочь следующие ресурсы:
Типы приложений
Существуют различные типы приложений, которые могут работать на Windows клиентских устройствах. В этом разделе перечислены некоторые распространенные приложения, используемые на Windows устройствах.
Microsoft 365 приложения: эти приложения используются для бизнеса и производительности и включают Outlook, Word, Teams, OneNote и другие. В зависимости от лицензий, которые есть у организации, у вас уже могут быть эти приложения. С помощью поставщика MDM эти приложения также можно развернуть на мобильных устройствах, включая смартфоны.
Дополнительные сведения о параметрах Microsoft 365 лицензии и получаемой информации см. в Microsoft 365.
Power Apps: Эти приложения подключаются к бизнес-данным, доступным в Интернете и локально, и могут работать в веб-браузере и на мобильных устройствах. Они могут быть созданы бизнес-аналитиками и профессиональными разработчиками. Дополнительные сведения см. в Power Apps?.
Windows приложения:
Универсальные Windows платформы (UWP) приложения: эти приложения работают и могут быть установлены на многих платформах Windows, включая планшеты, Microsoft HoloLens, Xbox и многое другое. Все приложения UWP являются Windows приложениями. Не все Windows являются приложениями UWP.
Дополнительные сведения см. в дополнительных сведениях: Начало разработки приложений для настольных Windows и создание отличных приложений на Windows 11.
Системные приложения: приложения, установленные в C:\Windows\ каталоге. Эти приложения являются частью Windows ОС. Список некоторых распространенных системных приложений см. в списке системных приложений, установленных с Windows клиентской ОС.
Веб-приложения и прогрессивные веб-приложения (PWA): Эти приложения работают на сервере и не запускаются на устройстве пользователя. Чтобы использовать эти приложения, пользователи должны использовать веб-браузер и иметь доступ к Интернету. Прогрессивные веб-приложения предназначены для работы для всех пользователей, работы с любым браузером и работы на любой платформе.
Веб-приложения обычно создаются в Visual Studio и могут создаваться на разных языках. Дополнительные сведения см. в странице Create a Web App. Когда приложение создано и готово для использования, развертывание веб-приложения на веб-сервере. С помощью Azure можно использовать веб-приложения в облаке, а не локально. Дополнительные сведения см. в обзоре службы приложений.
С помощью поставщика MDM можно создавать ярлыки для веб-приложений и прогрессивных веб-приложений на устройствах.
Приложения ™️ Android
Начиная с Windows 11, пользователи программы Windows Insider могут использовать Microsoft Store для поиска, скачивания и установки приложений android™️. Эта функция использует Windows подсистему для Android и позволяет пользователям взаимодействовать с приложениями Android, как и другие приложения, установленные с Microsoft Store.
Дополнительные сведения см. в следующих разделах:
Добавление или развертывание приложений на устройствах
Когда приложения будут готовы, вы можете добавить или развернуть эти приложения на Windows устройствах. В этом разделе перечислены некоторые распространенные параметры.
Ручная установка. На ваших устройствах пользователи могут устанавливать приложения из Microsoft Store, из Интернета и с общего диска организации. Эти приложения и другие приложения перечислены в Параметры > Приложения > и функции.
Если вы хотите запретить пользователям скачивать приложения на устройствах, которые принадлежат организации, используйте поставщика MDM, например Microsoft Intune. Например, вы можете создать политику, которая позволяет пользователям или предотвращает загрузку приложений, разрешается только частный магазин и другие. Дополнительные сведения о возможности, которые можно ограничить, см. в Windows параметров клиентских устройств, позволяющих или ограничивающих функции с помощью Intune.
Общие сведения о различных типах политик устройств, которые можно создать, см. в примере Apply features and settings on your devices using device profiles in Microsoft Intune.
Управление мобильными устройствами (MDM): для развертывания приложений используйте поставщика MDM, например Microsoft Intune (облако) или Configuration Manager (локально). Например, можно создавать политики приложений, Microsoft 365 приложения, развертывать приложения Win32, создавать ярлыки для веб-приложений, добавлять приложения Store и другие.
Дополнительные сведения см. в следующих разделах:
Microsoft Store. С Microsoft Store приложением Windows пользователи могут загружать приложения из общего магазина. Кроме того, они могут загружать приложения, предоставляемые вашей организацией, которая называется «частный магазин». Если ваша организация создает собственные приложения, вы можете использовать Диспетчер пакетов Windows для добавления приложений в частный магазин.
Чтобы помочь управлять Microsoft Store устройствами, можно использовать политики:
Дополнительные сведения см. в следующих разделах:
Чтобы развернуть пакеты MSIX и их приложения, можно:
Дополнительные сведения см. в следующих разделах:
Диспетчер пакетов Windows: Диспетчер пакетов Windows — это средство командной строки, обычно используемая разработчиками для установки Windows приложений. С помощью командной строки можно получить приложения из Microsoft Store или GitHub (и более) и установить эти приложения на Windows устройствах. Это полезно, если вы хотите обойти пользовательские интерфейсы для получения приложений от организаций и от разработчиков.
Виртуальный рабочий стол Azure с присоединением к приложению MSIX. С помощью виртуального рабочего стола Azure можно виртуализировать Windows клиентской ОС и использовать виртуальные приложения на этом рабочем столе. С помощью приложения MSIX вы динамически доставляете пакетные приложения MSIX пользователям и группам пользователей.
Преимуществом является использование облака для доставки виртуальных приложений в режиме реального времени и по мере необходимости. Пользователи используют приложения так, как будто они установлены локально.
Если вы в настоящее время используете App-V и хотите уменьшить локальное присутствие, то для вашей организации может быть правильное развертывание рабочего стола Azure Virtual с присоединением к приложению MSIX.
Дополнительные сведения см. в следующих разделах:
Виртуализация приложений (App-V). Приложение-V позволяет использовать приложения Win32 в качестве виртуальных приложений.
Виртуализация приложений завершится в апреле 2026 г. Рекомендуем посмотреть на Azure Virtual Desktop с присоединением к приложению MSIX. Дополнительные сведения см. в дополнительных сведениях о том, что такое Виртуальный рабочий стол Azure? и настройка приложения MSIX с порталом Azure.
На локальном сервере устанавливаются и настраиваются компоненты сервера App-V, а затем устанавливаются приложения Win32. На Windows Enterprise клиентских устройствах для запуска виртуализированных приложений используются клиентские компоненты App-V. Они позволяют пользователям открывать виртуальные приложения с помощью знакомых им значков и имен файлов. Пользователи используют приложения так, как будто они установлены локально.
Преимуществом является доставка виртуальных приложений в режиме реального времени и по мере необходимости. Дополнительные сведения см. в обзоре виртуализации приложений (App-V) Windows.
Чтобы управлять App-V на устройствах, можно использовать политики: