Поделиться через

Основные сведения о работе упакованных классических приложений в Windows

  • Статья

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

Типы классического приложения

Существует два типа классических приложений, которые можно создать и упаковить. Тип приложения объявляется в манифесте пакета приложения с помощью атрибута uap10:RuntimeBehavior элемента Application:

  • Один тип включает оба приложения WinUI 3 (которые используют пакет SDK для приложений Windows) и мост для классических приложений приложения (Centennial). Объявлен с uap10:RuntimeBehavior="packagedClassicApp".
  • Другой тип представляет другие типы приложений Win32, включая приложения , упакованные с внешним расположением. Объявлен с uap10:RuntimeBehavior="win32App".

универсальная платформа Windows (UWP) приложения (uap10:RuntimeBehavior="windowsApp") также упаковываются; но этот раздел не относится к ним.

А затем атрибут uap10:TrustLevel (одного элемента application ) определяет, выполняется ли процесс упаковаемого приложения в контейнере приложения.

  • Приложение с полным доверием. Объявлен с uap10:TrustLevel="mediumIL".
  • Приложение appContainer. Объявлен с uap10:TrustLevel="appContainer". Выполняется в упрощенном контейнере приложений (поэтому изолируется с помощью файловой системы и виртуализации реестра). Дополнительные сведения см. в приложениях MSIX appContainer.

Важно!

Дополнительные сведения, зависимости и требования к возможностям см. в документации по этим двум атрибутам в Приложении. Также см . раздел uap10, представленный в Windows 10 версии 2004 (10.0; Сборка 19041).

Назначение упаковки и контейнеров приложений

Цель упаковки приложения — предоставить ему удостоверение пакета во время выполнения. Удостоверение пакета необходимо для некоторых функций Windows (см. сведения о функциях, требующих удостоверения пакета). Вы можете упаковыть все сочетания типов приложений, описанных выше (и тем самым воспользоваться удостоверением пакета).

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

Установка

Пакеты приложений устанавливаются на основе каждого пользователя вместо системного уровня. Расположение по умолчанию для новых пакетов на новом компьютере находится в разделе C:\Program Files\WindowsApps\<package_full_name>с исполняемым файлом с именем app_name.exe. Но пакеты могут быть установлены в других местах; Например, команды запуска Visual Studio используют команды проекта$(OutDir).

После развертывания файлы пакетов помечены только для чтения и сильно заблокированы операционной системой (ОС). Windows запрещает запуск приложений, если эти файлы были изменены.

Расположение C:\Program Files\WindowsApps — это то, что называется PackageVolume. Это расположение по умолчанию PackageVolume, с которым поставляется Windows; но вы можете создать PackageVolume на любом диске и по любому пути. Кроме того, не все пакеты устанавливаются в PackageVolume (см. приведенный выше пример Visual Studio).

Файловая система

ОС поддерживает различные уровни операций файловой системы для упакованных классических приложений в зависимости от расположения папки.

Оптимизировано для вашего устройства

Чтобы избежать дублирования файлов (для оптимизации дискового пространства и уменьшения пропускной способности, необходимой при скачивании файлов), ОС использует одно хранилище и жесткое связывание файлов. Когда пользователь загружает пакет MSIX, он используется для определения того, существуют ли данные, AppxManifest.xml содержащиеся в пакете, уже существуют на диске из более ранней установки пакета. Если один и тот же файл существует в нескольких пакетах MSIX, ОС сохраняет общий файл только один раз и создает жесткие ссылки из обоих пакетов в общий файл. Так как файлы скачиваются в блоках 64 Кб, даже если процент скачиваемого файла существует на диске, скачиваются только приращение, которое отличается. Это сокращает пропускную способность, используемую для скачивания.

Операции AppData в Windows 10 версии 1903 и более поздних версий

Этот раздел относится только к виртуализированным приложениям.

Все только что созданные файлы и папки в папке пользователя AppData (например, C:\Users\<user_name>\AppData) записываются в частное расположение для каждого пользователя, для каждого приложения, но объединяются во время выполнения, чтобы отображаться в реальном AppData расположении. Это обеспечивает некоторое разделение состояния для артефактов, которые используются только самим приложением; что позволяет системе очищать эти файлы при удалении приложения.

Изменения существующих файлов в папке пользователя AppData разрешены для обеспечения более высокой степени совместимости и взаимодействия между приложениями и ОС. Это уменьшает системный "гниль", так как ОС знает о каждом изменении файла или каталога, внесенных приложением. Разделение состояния также позволяет упакованным классическим приложениям выбирать, где распаковывается версия одного и того же приложения. Обратите внимание, что ОС не поддерживает папку виртуальной файловой системы (VFS) для папки пользователя AppData .

Операции AppData с OS до Windows 10 версии 1903

Этот раздел относится только к виртуализированным приложениям.

Все записи в папку пользователя AppData (например, C:\Users\<user_name>\AppData), включая создание, удаление и обновление, копируются при записи в частное расположение для каждого пользователя. Это создает иллюзию того, что упаковаемое приложение редактирует реальное AppData , когда он фактически изменяет частную копию. Перенаправляя запись таким образом, система может отслеживать все изменения файлов, внесенные приложением. Это позволяет системе очищать эти файлы при удалении приложения, уменьшая системный "гниль" и обеспечивая более удобный интерфейс удаления приложений для пользователя.

Рабочий каталог и файлы приложений

Этот раздел относится только к виртуализированным приложениям.

Помимо перенаправления AppDataизвестные папки Windows (System32и Program Files (x86)т. д.) динамически объединяются с соответствующими каталогами в пакете приложения. Каждый пакет содержит папку с именем VFS в корневом каталоге. Все операции чтения каталогов или файлов в VFS каталоге объединяются во время выполнения со своими собственными коллегами. Например, приложение может содержаться C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll в составе пакета приложения, но файл, как представляется, установлен в C:\Windows\System32\vc10.dll. Это обеспечивает совместимость с классическими приложениями, которые ожидают, что файлы будут жить в расположениях, отличных от пакетов.

Операции записи в файлы и папки в пакете приложения не допускаются. Операции записи в файлы и папки, которые не входят в пакет, игнорируются и допускаются ОС при условии, что у пользователя есть на них разрешение.

Распространенные операции файловой системы

В этой краткой справочной таблице приведены типичные операции с файловой системой с указанием того, как они обрабатываются ОС.

Операция Результат Пример
Чтение или перечисление известного файла или папки Windows Динамическое слияние C:\Program Files\<package_full_name>\VFS\<well_known_folder> с локальным аналогом системы. Чтение C:\Windows\System32 возвращает содержимое C:\Windows\System32 плюс содержимое C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86.
Запись в разделе AppData Windows 10, версия 1903 и более поздние версии. Новые файлы и папки, созданные в следующих каталогах, перенаправляются в частное расположение для каждого пользователя и пакета:
  • Local
  • Local\Microsoft
  • Роуминг
  • Roaming\Microsoft
  • Roaming\Microsoft\Windows\Start Menu\Programs
В ответ на команду открытия файла ОС сначала открывает файл из расположения для каждого пользователя и пакета. Если это расположение не существует, ОС попытается открыть файл из реального AppData расположения. Если файл открыт из реального AppData расположения, виртуализация для этого файла не выполняется. Удаление файлов разрешено AppData , если у пользователя есть разрешения.

Ранее, чем Windows 10 версии 1903: скопируйте запись в расположение для каждого пользователя.

 AppData обычно C:\Users\<user_name>\AppDataявляется .
Запись внутри пакета Запрещено. Пакет доступен только для чтения. Записи в разделе C:\Program Files\WindowsApps\<package_full_name> не допускаются.
Запись за пределами пакета Разрешено, если у пользователя есть разрешения. C:\Windows\System32\foo.dll Запись разрешена, если пакет не содержитC:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dll, и у пользователя есть разрешения.

Упакованные расположения VFS

Этот раздел относится только к виртуализированным приложениям.

В этой таблице показано, где доставка файлов в составе пакета накладывается на систему для приложения. Ваше приложение будет воспринимать эти файлы в перечисленных системных расположениях, когда они на самом деле в перенаправленных расположениях внутри C:\Program Files\WindowsApps\<package_full_name>\VFS. Расположения FOLDERID находятся из констант KNOWNFOLDERID.

Расположение системы Перенаправленное расположение (в разделе [<package_root>]\VFS) Допустимо для архитектур
FOLDERID_SystemX86 SystemX86 x86, amd64
FOLDERID_System SystemX64 amd64
FOLDERID_ProgramFilesX86 ProgramFilesX86 x86, amd6
FOLDERID_ProgramFilesX64 ProgramFilesX64 amd64
FOLDERID_ProgramFilesCommonX86 ProgramFilesCommonX86 x86, amd64
FOLDERID_ProgramFilesCommonX64 ProgramFilesCommonX64 amd64
FOLDERID_Windows Windows x86, amd64
FOLDERID_ProgramData Общие AppData x86, amd64
FOLDERID_System\catroot AppVSystem32Catroot x86, amd64
FOLDERID_System\catroot2 AppVSystem32Catroot2 x86, amd64
FOLDERID_System\drivers\etc AppVSystem32DriversEtc x86, amd64
FOLDERID_System\driverstore AppVSystem32Driverstore x86, amd64
FOLDERID_System\logfiles AppVSystem32Logfiles x86, amd64
FOLDERID_System\spool AppVSystem32Spool x86, amd64

Реестр

Этот раздел (и его подразделы) применяется только к виртуализированным приложениям.

Пакеты приложений содержат registry.dat файл, который служит логическим (виртуальным) эквивалентом HKLM\Software в реальном реестре. Во время выполнения виртуальный реестр объединяет содержимое этого куста в собственный системный куст, чтобы предоставить одно представление обоих. Например, если registry.dat содержит один ключ Foo, то чтение HKLM\Software во время выполнения также будет содержать Foo (помимо всех собственных системных ключей).

Хотя пакеты MSIX включают ключи HKLM и HKCU , они обрабатываются по-разному. Только ключи в HKLM\Software являются частью пакета; ключи в HKCU или других частях реестра не являются. Запись в ключи или значения в пакете не разрешена. Операции записи в разделы или значения, которые не входят в пакет, допускаются, если у пользователя есть на них разрешение.

Все записи в HKCU копируются при записи в частное расположение для каждого пользователя. Традиционно удаление не может очистить HKEY_CURRENT_USER , так как данные реестра для пользователей, зарегистрированных в журнале, отключены и недоступны.

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

Общие операции реестра

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

В этой краткой справочной таблице приведены типичные операции с реестром с указанием того, как они обрабатываются ОС.

Операция Результат Пример
Чтение или перечисление HKLM\Software Динамическое слияние hive пакета с локальным аналогом системы. Если registry.dat содержит один ключ Foo, то во время выполнения чтение HKLM\Software отображает содержимое HKLM\Software\HKLM\Software\HKLM\Software\Foo.
Записи в HKCU Скопировано на запись в частное расположение для каждого пользователя. То же самое, что AppData и для файлов.
Записывает внутри пакета. Запрещено. Пакет доступен только для чтения. Записи в HKLM\Software не допускаются, если соответствующий ключ/значение существует в кусте пакета.
Записывает за пределы пакета Игнорируется ОС. Разрешено, если у пользователя есть разрешения. Записи в HKLM\Software разрешены, если соответствующий ключ/значение не существует в кусте пакета, а пользователь имеет правильные разрешения на доступ.

Удаление

Этот раздел относится только к виртуализированным приложениям.

При удалении пакета пользователем все файлы и папки, расположенные C:\Program Files\WindowsApps\<package_full_name> под ним, удаляются, а также все перенаправленные записи AppData в или реестр, которые были записаны во время процесса упаковки.