AppData\Local\Packages что это за папка в Windows 10?

AppData\Local\Packages — папка, которая возможно используется для работы метро-приложений. То есть не обычные программы, там Хром, Офис, Блокнот, а именно метро-приложения, которые запускаются из меню Пуск и которые еще можно назвать плиточными. Если вы собрались очистить папку Packages, то будьте готовы к глюкам с этими метро-приложениями.

Юзеры в сети пишут — папка AppData\Local\Packages много весит, оказывается, что в этой папке могут быть всякие непонятные.. папки.. файлы.. но среди этого всего возможно что есть папка кэша — cache. И вероятно что именно она и может прилично занимать места. У одного юзера так и было — в Packages внутри была папка AVG Web TuneUp, а в ней — cache, которая и весила десятки гигабайт.

То есть уже делаем вывод — просто так взять и удалить AppData\Local\Packages нельзя. Почистить — можно попробовать. Не исключено что в чистилке CCleaner уже учтено то, что может быть такая папка Packages, которой можно почистить файлы кэша.

Может стоит удалить некоторые метро-приложения, но гарантирует ли это и удаление кэша этих приложений?

Один юзер пишет — у него начало пропадать место на системном диске. Начал смотреть. Оказалось папка Packages. Но он узнал кто виновник — приложение Microsoft.BingNews. Юзер уточнил — новости читает часто и один визит, предположительно, сьедает около 50 мегов на диске. Господа, это абсурд. Мне кажется что обычный браузер вроде Хрома и то так не беспредельничает. Юзер папку очистил, но как — непонятно.

У меня этой папки нет. Но есть предположение, что в папке Packages могут быть файлы или папки, которые в своем названии как-то намекают к какому приложению они имеют отношение. Например я нашел такие пути:

konstantin — это просто имя учетной записи. Пользователя так звали видимо. Так вот — есть папка C6965DD5.VK_v422avzh127ra, по на названию папка и ее содержимое вроде как имеет отношение к приложению ВКонтакте. В теории остальные папки также могут иметь подсказки в названиях к чему они относятся. Если в папке приложения есть LocalCache и она много занимает места — переименуйте ее в LocalCache_temp и посмотрите, если не будет проблем вообще, значит можно удалять. Наблюдать советую день-два.

И снова я натыкаюсь на комментарий чела — он пишет что нельзя удалять папку Packages иначе будут удалены метро-приложения. Даже после удаления папка будет восстановлена. Но с другой стороны — сами приложения никак не могут весить десятки гигов. Это какие-то другие данные, в большой вероятностью что временные, которые можно удалить. Как я уже писал выше — скорее всего это кэш приложений (нужно разбираться и смотреть в папке Packages).

Так, а почему вы вам не поэкспериментировать? Удалять Packages — нет, не нужно. Зайдите в эту папку и переименуйте то, что кажется можно будет удалить. То есть папки кэша или просто те, которые оч много весят. Будут ли проблемы? Да, могут. Что делать? Все просто — нужно создать точку восстановления. Зажмите Win + R, далее укажите команду:

control /name microsoft.system

В свойствах выбираете системный диск и нажимаете Создать:

Указываете имя точки и создаете:

После создания точки можете попробовать удалить какие-то тяжелые папки в Packages.

Выяснилось, что удаление папок в Packages может быть проблемным из-за отсутствие прав. Просто будет выкидывать ошибку. Что делать? Есть выход — использование утилиты Unlocker. Она создана спецом для удаления неудаляемых файлов и папок. Бесплатная, я пользуюсь версией 1.9.2. Если будете устанавливать — осторожно, при установке хочет установится какой-то Дельта Тулбар, поэтому внимательно смотрите и снимите необходимые галочки.

Удивительно, но мне удалось найти команду очистки кэша папки AppData\Local\Packages, о такой команде даже и не слышал:

Зажмите кнопки Win + Q и вставьте эту команду потом выберите в результате о очистите кэш.

Еще одно небольшой открытие — оказывается в антивирусе Касперский есть функция очистки папки Packages.

Уже второй юзер пишет — AVG TuneUp может быть причиной большого веса папки.

Ребята, снова важная информация. Один пользователь на форуме Microsoft говорит следующее: если вы удалили все метро-приложения при помощи PowerShell или вообще не пользуетесь метро-приложения, тогда вы можете безопасно удалить папку Packages. Из чего делаем вывод — папка нужна только для метро-приложений. То есть на обычные программы и на работу системы папка влияния не оказывает.

Один юзер тоже очистил папку Packages и причиной было приложение AVG Web TuneUp. Я заинтересовался, узнал:

На этом все. Искренне надеюсь информация помогла. Удачи.

Диспетчер пакетов Windows (предварительная версия) Windows Package Manager (preview)

Сейчас предоставляется общедоступная предварительная версия Диспетчера пакетов Windows и средства winget. Перед выпуском общедоступной версии в решения могут быть внесены значительные изменения. Windows Package Manager and the winget tool are in public preview and may be substantially modified before they are generally available. Майкрософт не дает никаких гарантий, явных или подразумеваемых, в отношении предоставленной здесь информации. Microsoft makes no warranties, express or implied, with respect to the information provided here.

Диспетчер пакетов Windows — это комплексное решение для управления пакетами, которое состоит из программы командной строки и набора служб для установки приложений в Windows 10. Windows Package Manager is a comprehensive package manager solution that consists of a command line tool and set of services for installing applications on Windows 10.

Диспетчер пакетов Windows для разработчиков Windows Package Manager for developers

Разработчики используют программу командной строки winget для обнаружения, установки, обновления, удаления и настройки проверенного набора приложений. Developers use the winget command line tool to discover, install, upgrade, remove and configure a curated set of applications. После установки разработчики могут получить доступ к winget с помощью терминала Windows, PowerShell или командной строки. After it is installed, developers can access winget via the Windows Terminal, PowerShell, or the Command Prompt.

Диспетчер пакетов Windows для независимых поставщиков программного обеспечения Windows Package Manager for ISVs

Независимые поставщики программного обеспечения могут использовать Диспетчер пакетов Windows в качестве канала распространения пакетов программного обеспечения, содержащих их средства и приложения. Independent Software Vendors (ISVs) can use Windows Package Manager as a distribution channel for software packages containing their tools and applications. Для отправки пакетов программного обеспечения (содержащих установщики MSIX, MSI или EXE) в Диспетчер пакетов Windows мы предоставляем на сайте GitHub репозиторий манифестов пакетов сообщества Майкрософт с открытым исходным кодом. Независимые поставщики программного обеспечения могут передавать в него манифесты пакетов, которые затем могут быть включены в Диспетчер пакетов Windows. To submit software packages (containing .msix, .msi, or .exe installers) to Windows Package Manager, we provide the open source Microsoft Community Package Manifest Repository on GitHub where ISVs can upload package manifests to have their software packages considered for inclusion with Windows Package Manager. Манифесты проверяются автоматически, однако они также могут просматриваться вручную. Manifests are automatically validated and may also be reviewed manually.

Основные сведения о диспетчерах пакетов Understanding package managers

Диспетчер пакетов — это система или набор средств, используемых для автоматизации установки, обновления, настройки и использования программного обеспечения. A package manager is a system or set of tools used to automate installing, upgrading, configuring and using software. Большинство диспетчеров пакетов предназначены для обнаружения и установки средств для разработчиков. Most package managers are designed for discovering and installing developer tools.

В идеале разработчики используют диспетчер пакетов, чтобы задать компоненты, необходимых им для разработки решений под конкретный проект. Ideally, developers use a package manager to specify the prerequisites for the tools they need to develop solutions for a given project. Затем диспетчер пакетов выполняет декларативные инструкции по установке и настройке средств. The package manager then follows the declarative instructions to install and configure the tools. Диспетчер пакетов сокращает время, затрачиваемое на подготовку среды, и помогает обеспечить установку на компьютеры одних и тех же версий пакетов. The package manager reduces the time spent getting an environment ready, and it helps ensure the same versions of packages are installed on their machine.

Диспетчеры пакетов сторонних разработчиков могут использовать репозиторий манифестов пакетов сообщества Майкрософт для пополнения своего каталога программного обеспечения. Third party package managers can leverage the Microsoft Community Package Manifest Repository to increase the size of their software catalog.

Обслуживание на основе компонентов

Наверняка уже ни для кого не секрет, что как и в любом (без исключения) программном обеспечении, в коде операционных систем присутствуют ошибки. Периодически тем или иным образом их удается обнаружить, о чем рано или поздно узнает разработчик, в чьих интересах производить оперативное устранение найденных проблем. Но мало выпустить исправление (заплатку/патч), изменения эти требуется еще как-то доставить до пользовательских операционных систем, функционирующих по всему миру. Помимо ошибок, на всем протяжении цикла поддержки операционной системы, в неё добавляются и новые функциональные возможности. Все перечисленные виды вносимых в систему изменений (исправления, обновления, дополнения) на данный момент принято обобщать в огромный комплекс задач под названием обслуживание операционной системы.
С появлением и развитием сети Интернет, методы доставки контента обслуживания до географически-удаленных операционных систем претерпели существенные изменения: сперва в виде доступных на сайте Microsoft для скачивания файлов, затем, по мере развития архитектуры операционных систем и, в частности, алгоритмов обновления, трансформировались в сложные многоуровневые сервисы, производящие автоматическую загрузку и обновление. В последнее время Microsoft запустила уже непрерывный цикл обновлений настольных операционных систем, который подразумевает под собой не только (отдельные) текущие обновления, но так же и глобальные доработки, приводящие к (прозрачному) переходу к следующим редакциям ОС.

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

Обслуживание на основе файлов

В операционных системах, предшествующих Windows Vista (Windows XP и ранее), применялся метод обслуживания, носящий название обслуживание на основе файлов (File-Based Servicing, FBS). Процесс обслуживания был организован достаточно незатейливо: на основе .inf -файла описания изменений, обновляемые системные файлы перезаписывались новыми версиями непосредственно по пути основного размещения (в основном это: %WinDir%\System32 ), при этом копия свежей версии помещалась еще и в кеш защищенных системных файлов ( %WinDir%\System32\DLLcache ). Если в момент обновления задействованные системные файлы кем-то использовались (были заняты/заблокированы), то замена их производилась позже, на этапе очередной загрузки операционной системы простым копированием уже новой версии из директории кеша в директорию основного размещения. А как же старые версии, спросите вы? А старые версии обновляемых библиотек удалялись безвозвратно, но в некоторых случаях (с включенной опцией rollback) их все же можно было сохранять в системе (в каталогах вида %WinDir%\$NTUninstallKBxxxxxxxx$ ). Эта особенность создавала проблему совместимости и позже, для её решения был добавлен каталог WinSxS , в который сохранялись старые (предыдущие) версии некоторых библиотек для совместимости с Windows95-приложениями. Как вы видите, механизм обслуживания на основе файлов был довольно прост, поэтому с него и начали, тем не менее он имел существенные недостатки:

• Основная проблема: обновление единственных экземпляров системных файлов (библиотек), что неизменно вело к сбоям в работе приложений, оптимизированных (их авторами) на использование определенной версии общих DLL . Данная категория проблем получила название проблем совместимости библиотек и исполняемых модулей.
• Обновления (update) или исправления (hotfix) содержали полноценный инсталлятор (исполняемые модули с именами update.exe / hotfix.exe ), который непосредственно производил обновление файлов (библиотек) в системе. Сами понимаете, что подобная избыточность делала каждое обновление фактически автономным пакетом [установки], что вело к отсутствию унификации/контроля установки.
• Все файлы были как бы «свалены в кучу», то есть размещались в общей для всех директории.
• В системе отсутствовал менеджер пакетов, что делало контроль за процессом обновления менее гибким, не было единой базы установленных компонентов, невозможно было контролировать и производить возврат к предыдущему состоянию («откат») и прочие, ставшие уже привычными для других операционных систем, виды обслуживания.

Очевидно, что назревало решение по интеграции в линейку операционных систем Windows собственной подсистемы управления пакетами.

Обслуживание на основе компонентов

Начиная с Windows Vista была разработана и внедрена принципиально новая модель обслуживания, которая получила название обслуживание на основе компонентов (Component-Based Servicing, CBS). В противоположность обслуживанию на основе файлов, в котором файлы обновлялись прямо в системных директориях, в CBS появилась аж целая иерархия директорий и целое семейство (стек) модулей/библиотек обслуживания. Было введено понятие компонента, представляющего собой (небольшой) набор файлов, сгруппированных по назначению, функциональности и возможности многократного использования (активации/деактивации). В компонент входили: библиотеки/исполняемые, манифесты, каталог безопасности и некоторые другие. Появились статусы компонентов/обновлений, в связи с чем появилась возможность активировать или отключить различные возможности (features) в операционной системе по мере необходимости. Статус означает, что сам по себе компонент может быть установлен в ОС, но не активирован. Это вводит понятие состояния, которое помимо компонентов так же затрагивает обновления и исправления. Характерный пример — средство удаленного администрирования сервера (RSAT) в Windows 7, при инсталляции которого устанавливаются все компоненты средства администрирования, но ни один из установленных элементов не активен после инсталляции. Все что делает установщик в данном случае, так это просто добавляет компоненты в систему, а вот позже необходимо самостоятельно задействовать оснастку Программы и компоненты (или действовать через dism) для включения требуемых возможностей.
Как вы уже поняли, обслуживание на основе компонентов (компонентная модель) в очередной раз перевернуло все с ног на голову и принесло множество «счастливых» моментов в жизнь простого технического специалиста, существенно изменив сложившийся годами привычный подход к принципам обслуживания операционной системы.

Причины внедрения, отличительные черты и преимущества компонентной модели:

1. обеспечивает полный цикл сопровождения (установка/удаление/предоставление/восстановление) всех версий общих модулей/библиотек.
2. является более надежным (стабильным) и безопасным механизмом, в отличии от автономных инсталляторов ( update.exe / hotfix.exe ), хорошо знакомых по предшествующим версиям операционной системы Windows.
3. обеспечивает более управляемый (контролируемый) процесс установки, позволяющий добавлять обновления, драйверы и дополнительные компоненты, решая проблемы нестабильности, вызванные неправильной/частичной установкой.
4. позволяет упаковывать любые компоненты и возможности в виде небольших модулей, которые обеспечивают весь функционал компонента.
5. обеспечивает хранение множества версий объектов (файлов) при помощи механизма WinSxS (Side-by-side assemblies);
6. извечная проблема Windows – отсутствие на протяжении очень продолжительного времени собственной системы управления пакетами (менеджера пакетов), наконец-то решена, встречайте CBS! 🙂

По информации разработчиков, компонентная модель состоит из следующих условных слоев (упрощенно — уровней):

Уровень	Предназначение
CBS (Component Based Servicing)	Обслуживание на основе компонентов. Так же широко известен в узких кругах под разными именами: доверенный установщик , установщик модулей Windows или попросту Trusted Installer ( TrustedInstaller.exe ), который функционирует на уровне пакета/обновления.
CSI (Component Servicing Infrastructure)	Инфраструктура обслуживания компонентов. Функционирует на уровне компонента/развертывания. Выполняет действия с файлами и реестром.
DMI (Driver Management and Install)	Управление и установка драйверов. Процессы обеспечения расширенной (продвинутой) установки драйверов.
CMI (Component Management Infrastructure)	Инфраструктура управления компонентами. Обеспечивает расширенный функционал установщиков.
SMI (Systems Management Infrastructure)	Инфраструктура управления подсистемами. Используется для управления различными параметрами реестра.
KTM (Kernel Transaction Manager)	Менеджер транзакций в ядре. Позволяет клиентам использовать транзакции операций с реестром и файловой системой.

Компонентная модель призвана обеспечить поддержку следующих системных задач:

• Включение/отключение компонентов Windows (оснастка Программы и компоненты — Включение и отключение компонентов Windows );
• Управление ролями посредством оснастки Server Manager в серверных версиях ОС;
• Восстановление работоспособности системы после сбоев и разнообразных проблем загрузки;
• Удаление/установка (проблемных) обновлений;
• Поддержка функционирования приложений, использующих технологию Бок-о-бок ( Side-by-Side );
• Использование Центром обновления Windows при установке новых компонентов;
• Перенос системы между различными редакциями Windows;

Хранилище компонентов (и пакетов)

Очевидно что информация о компонентах должна где-то физически размещаться. А то при выключении питания вся наша хваленая конструкция улетит в цифровой рай 🙂 Во многих источниках фигурирует информация, что имеются два основных хранилища, относящихся к компонентной модели:

1. Хранилище компонентов;
2. Хранилище пакетов;

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

А поскольку единственный механизм для постоянного хранения данных — это (любой) носитель информации и размещаемая на нем файловая система, то в контексте компонентной модели была создана иерархия каталогов под названием хранилище компонентов (каталог компонентов), располагающееся в дереве директорий с корнем в %WinDir%\WinSxS (традиционно: C:\Windows\WinSxS ). Разработчики уверяют что папка WinSxS является хранилищем разных версий общих библиотек и представляет собой «установочное и обслуживаемое состояние» всех системных компонентов.

Именование каталога WinSxS выбрано не случайно, оно является акронимом названия Side-by-Side (Бок о бок), которое подразумевает одновременное существование в системе множества версий определенной библиотеки.

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

Ничего необычного не видите? А что это за многоточие прямо по центру имени? А вот это вот такое своеобразное соглашение об именовании в хранилище компонентов, по которому некоторые, особенно размашистые имена, усекаются. Но стоит отметить, что у большинства компонентов имена все же полные.
Теперь обратим внимание на часть структуры компонентной модели, размещенной в файловой системе:

Путь	Назначение
%WinDir%\WinSxS\	Основной (корневой) каталог компонентной модели. Каталог полезной нагрузки, в котором (в поддиректориях), размещаются бинарные файлы компонентов. В некотором смысле это именно та папка, где на самом деле размещаются все библиотеки DLL системы. Образы DLL, которые вы видите в других местоположениях, на самом деле являются жесткими ссылками NTFS на те, что находятся в этом каталоге (и его подкаталогах).
%WinDir%\WinSxS\Backup	содержит эталонные образы защищаемых WRP системных файлов: библиотек и компонентов. Разнообразные сервисные утилиты производят восстановление файлов как раз из этой директории.
%WinDir%\WinSxS\Manifests	Каталог для хранения манифестов компонентов.
%WinDir%\WinSxS\Catalogs	.cat -файлы компонентов. Данные файлы содержат цифровые подписи каталогов и играют роль сигнатуры для файлов пакета, с помощью которой пользователь может определить происхождение пакета и проверить целостность файлов пакета драйвера.
%WinDir%\WinSxS\FileMaps	.cdf-ms -файлы. Это скомпилированные версии манифестов, позволяющие быстрее обрабатывать конфигурационные параметры, содержащиеся в манифестах. Содержат такие параметры как: имя компонента, версия, описание, опции развертывания, зависимости.
%WinDir%\WinSXS\Pending.xml	Файл формата XML, содержащий список действий (команд), исполняемых на этапе перезагрузки системы с целью выполнения тех задач (обновлений), которые не могут быть выполнены в момент работы ОС (поскольку во время штатной работы операционной системы могут присутствовать файлы, заблокированные другими процессами).
%WinDir%\WinSXS\Reboot.xml	Файл формата XML, содержащий опции/параметры перезагрузки операционной системы (для проведения процедуры обновления).
%WinDir%\Servicing\Packages	Хранилище пакетов. Директория, находящаяся вне иерархии хранилища компонентов, но логически к ней относящаяся. Содержит файлы каталогов безопасности ( .cat ) и манифестов ( .mum ) пакетов, установленных в системе.

Реестр

По факту данные реестра тоже хранятся в виде файлов, тем не менее все же принято выделять его в самостоятельную сущность. Хранилище компонентов имеет часть конфигурации в реестре, в следующих ключах:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing ;
• HKEY_LOCAL_MACHINE\Schema ;
• HKEY_LOCAL_MACHINE\COMPONENTS — временный, подключаемый на время обслуживания, ключ реестра. Импортируется из файла C:\Windows\system32\config\COMPONENTS ;

соответственно, в ключе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages перечисляются все установленные в системе пакеты.

Для того, что бы была возможность работать со списком пакетов, необходимо назначить правильные права на весь раздел Component Based Services со всем вложенным содержимым (подразделами → подключами). Как можно увидеть по снимку экрана, у каждого пакета имеется параметр с именем Visibility , который ответственен за видимость пользовательскими утилитами обслуживания, и если он имеет значение 1 — пакет виден, если 2 — то это скрытый пакет. У пакета может иметься подключ Owners , в котором (в качестве параметров) перечислены родительские пакеты, в этом случае отдельно удалить сам пакет не представляется возможным. Если вы самостоятельно проинспектируете подключ Owners , то увидите, что значительная часть системных пакетов входит в состав неких родительских глобальных пакетов с именами вроде Microsoft-Windows-EnterpriseEdition

* . Соответственно, чтобы иметь возможность удалить пакет, его нужно исключить из всех родительских пакетов (сделать автономным), попросту удалив находящиеся в подключе Owners параметры.

Компоненты (Components)

Самое время рассмотреть компонент повнимательнее:

Упрощенно компоненты состоят из полезной нагрузки (библиотеки, исполняемые файлы, локальные файлы конфигурации и прочие файлы) и манифеста (определяет зависимости). Каждый такой набор содержит все необходимые файлы, параметры реестра, и методы, требуемые для полной установки/удаления компонента. В компонентной модели атомарной единицей при обновлении является не файл (как ранее при файловом методе обслуживания), а компонент, и при обновлении единственного файла выпускается новая версия всего компонента, в состав которого входит обновляемый (пропатчеваемый) файл. Таким образом:

Это порождает довольно интересный, ранее не встречаемый, алгоритм обновления: в процессе установки библиотеки, уже имеющейся в системе, факт наличия обнаруживается, однако файл библиотеки DLL не перезаписывается, вместо этого новая версия помешается в папку WinSxS , при этом сохраняются соответствующие записи реестра, данных и прочее. Таким образом, наряду с новой версией компонента, в системе со временем накапливаются и все «старые» его версии, призванные обеспечить штатное функционирование программного обеспечения, нуждающегося в строго определенной версии компонента. Даже если исправление найденной ошибки вносится в один единственный файл, если этот файл относится к компоненту, содержащему и другие файлы, то обновление будет так же содержать все файлы этого компонента. Все эти файлы, вне зависимости от того, внесены в них изменения или нет, будут собраны (скомпилированы), номера их версий будут увеличены (изменены), далее все они будут упакованы (помещены) в пакет исправления.

Все отключаемые компоненты, видимые в оснастке Удаление компонентов Windows , можно получить командой:

dism /Online /Get-Features

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

Возможность (feature)

В русскоязычной версии Windows раздел Feature почему-то представлен переводчиками интерфейса как Компонент . Интересно, но разве дословно Feature переводится не как Возможность , в то время как компонент имеет соответствие в виде Component ? Казалось бы мелочь, тем не менее эта неточность порождает неразбериху в терминологии относительно разницы компонентов и возможностей. Мало того, что пользователь (да и специалист) путается во всех этих нововведениях компонентной модели, так тут еще происходит откровенная подмена понятий. К примеру, хорошо знакомая всем оснастка Programs and Features выглядит в русской версии как Программы и компоненты . Если мы откроем её, то увидим, что с её помощью мы можем:

• Удалять установленные в системе программы;
• Включать/отключать компоненты операционной системы;

Вроде все привычно, не так ли? Тем не менее, если мы открываем оснастку Включение или отключение компонентов Windows мы видим там модули вроде «Internet Explorer 11», «Microsoft .NET Framework 3.5.1» и некоторые другие. Как вы думаете, являются все эти программы компонентами, то есть в классическом понимании атомарными неделимыми установочными единицами компонентной модели? Очевидно что нет, поскольку под компонентами в Windows подразумеваются значительно более низкоуровневые сущности, например в том же Internet Explorer 11 более 20 компонентов. Так что же это тогда такое? Давайте разбираться.

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

Пакеты (Packages)

Помимо компонентов, в системе присутствуют так называемые пакеты, которые могут представлять собой как отдельные автономные инсталляции (например: Internet Explorer Optional Package , Remote Desktop Service WinIP и тому подобные), содержащие системные приложения, так и исправления операционной системы (которые отдельно могут поставляться в виде KBnnnnnnn) и комплекты драйверов.
Пакеты, по аналогии с компонентами, имеют собственное хранилище (хранилище пакетов), которое состоит из двух основных частей:

• одна часть пакета располагается в хранилище пакетов, то есть дереве директорий с корнем в %WinDir%\servicing\Packages . В нем содержатся конфигурационные файлы пакета, тут каждый установленный пакет/обновление представлен двумя файлами: файлом каталога безопасности ( .cat ) и манифеста ( .mum ), определяется собственным уникальным именем, которое включает в себя архитектуру процессора, имя пакета, уникальный идентификатор, версию пакета, язык локализации, для которых он был собран.
• другая часть (основные файлы) пакета размещается в хранилище компонентов, директории %WinDir%\WinSxS .

Манифест пакета описывает полезную нагрузку и статус: установлен и задействован (активирован), установлен, не установлен. Статусы пакетов:

• Installed (Установлен) — пакет установлен и присутствует в каталоге WinSxS . Полезная нагрузка пакета размещена в файловой системе и активна;
• Superseded (Заменён) — пакет представляет собой полную замену более ранней версии пакета(ов);
• Not Present (Отсутствует) — ?;
• Staged (Промежуточное, подготовленное) — пакет не установлен однако присутствует в каталоге WinSxS . В этом состоянии находятся многие роли/возможности в системе (сразу после установки). Когда какая-либо роль/возможность не активна, то данная роль находится как раз в промежуточном состоянии. В графическом интерфейсе состояние видно в качестве флажка напротив роли, который не активен (не установлен). Активация чекбокса компонента запускает процесс перемещения его бинарных файлов из промежуточного состояния в установленное;
• Absent (Отсутствует) — пакет не установлен и отсутствует в каталоге WinSxS . Иногда это означает, что пакет «отключен и его полезная нагрузка удалена»;

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

dism /Online /Get-Packages

Обновление (KBnnnnnnn)

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

• .cab-файлы (Cabinet) — архивы. Предназначены для распространения и установки при помощи модулей Центра обновлений Windows в автоматизированном режиме. В архиве (наряду с другими файлами) содержатся двоичные данные для обновления системных файлов. Они могут быть в неупакованном (нормальном) виде, либо в упакованном (тип PA30 ). Так же, эти двоичные данные могут быть в виде файлов для непосредственной полной замены или в виде бинарных патчей (через MSDelta/PatchAPI);
• .msu-файлы (Microsoft Update Standalone Package) — исполняемые файлы. Предназначены для распространения и установки самими пользователями в ручном режиме через каталог обновлений Microsoft. Фактически представляют собой упакованный набор, состоящий из .cab-, .xml, .txt-файлов;

Манифесты (Manifests)

С манифестами у многих возникает постоянная путаница, поскольку по задумке разработчиков они обеспечивают выполнение сразу целого ряда задач. Но надо помнить, что:

Манифест хранит следующие данные:

• Информация о сборке: имя, версия, контрольная сумма, открытый криптографический ключ.
• Список имен файлов, входящих в сборку (в случае если она является многофайловой).
• Список зависимостей: перечисление сборок, необходимых для функционирования данной [сборки].
• Связи типов (экспортируемых сборкой) с их внутренней реализацией.

Фактически манифест является паспортом приложения. Тем не менее можно дать условное псевдоделение типов манифестов применительно к хранилищу компонентов и пакетов:

• Манифест компонента (файл с расширением .manifest ) – паспорт компонента Windows. Манифест компонента задает его зависимости от имен, версий, ресурсов и других компонентов, в нем указываются различные параметры компонента, такие как наименование, каталог установки, параметры (ключи) реестра, исполняемые файлы, наименования служб и прочие. Манифест определяет как именно файлы группируются по компонентам. Имя файла манифеста включает имя соответствующей сборки, размещаемой в каталоге %WinDir%\WinSxS . Размещается в каталоге %WinDir%\WinSxS\Manifests ;
• Манифест пакета или обновления (файл с расширением .mum ) — паспорт пакета/обновления Windows. В нем указываются различные параметры пакета: наименование, идентификатор, язык установки, зависимости. Этот типа манифеста используется в качестве идентификатора (символического имени) сервиса обслуживания, для выполнения над пакетом операций включения/отключения/удаления посредством различных сервисных утилит ( DISM , pkgmgr ). Имя файла манифеста включает имя соответствующего пакета, размещаемого в каталоге %WinDir%\WinSxS . Размещается в каталоге %WinDir%\servicing\Packages ;
• Манифест приложения (файл с именем основного приложения, двойным расширением .exe.manifest , или секция ресурсов с именем Manifest ) — паспорт приложения Windows. В нем определены зависимости, которые приложение использует и связывает его со строго определенной версией компонента (сборки), библиотеки. Желающие использовать строго определенные версии библиотек, должны непосредственно указывать идентификаторы сборок в собственном манифесте.

Обслуживание

Стек обслуживания в операционных системах Windows Vista и новее состоит из трех основных уровней:

1. Верхний: работают такие клиенты как: Windows Update, Programs and Features, и MSI, которые доставляют пакеты в систему. Программные клиенты верхнего уровня в дополнение отвечают за взаимодействие с пользователем, обеспечивают сбор/хранение пользовательских настроек на всем протяжении обслуживания.
2. Средний: На среднем уровне стека обслуживания функционирует Trusted Installer (trustedinstaller.exe), CBS. Клиенты верхнего уровня спускают скачанные пакеты к CBS, которая оценивает каждый пакет для определения, применимы ли они к данной операционной системе. Для применяемых обновлений CBS предоставляет компоненты CSI, генерирует соответствующие события установки и регистрирует пакеты в оснастке Программы и компоненты , в случае необходимости. Наконец, CBS предоставляет интерфейсы для индексации и инвентаризации обновлений.
3. Нижний: На нижнем уровне стека обслуживания располагается CSI, которая использует Kernel Transaction Manager (KTM) для выполнения работы.

Как мы уже говорили, обслуживание системы в новых реалиях происходит уже на уровне компонентов. Файлы поддержки технологии расположены в каталоге %SystemRoot%\servicing . Например, в Windows 7 в данном каталоге размещаются:

Наименование	Описание
CbsApi.dll	Основная библиотека поддержки технологии CBS.
CbsMsg.dll	Дополнительная библиотека поддержки CBS.
TrustedInstaller.exe	интерфейс между стеком обслуживания и разнообразными пользовательскими программами по обслуживанию, такими как sfc, dism, pkgmgr, оснасткой «Программы и компоненты», инсталляторами MSI, компонентом «Обновление Windows». Фактически, теперь только модуль TrustedInstaller.exe может модифицировать критические системные файлы. Использует модули уровня CSI для выполнения всей работы.
wrpinitapi.dll	Библиотека поддержки технологии Windows File Protection (WFP).
\Packages	Подкаталог-хранилище пакетов. Содержит файлы каталогов безопасности ( .cat ) и манифестов ( .mum ) установленных пакетов/обновлений. Сами пакеты/обновления, скорее всего, содержатся в директории %WinDir%\WinSxS ;

В стеке обслуживания реализован давно уже знакомый специалистам системный механизм под названием Защита Ресурсов Windows (Windows Resource Protection (WRP)), в операционных системах до Windows Vista более известный под именем Защита Файлов Windows (Windows File Protection (WFP)).

Сам принцип защиты критических файлов так же поменялся со времен WFP, теперь отсутствует системный процесс, который в режиме реального времени отслеживает попытки модификации критических файлов, а система ограничивает доступ к важным системным файлам при помощи списков контроля доступа (ACL/DACL), то есть WRP контролирует только определенные местоположения в операционной системе.

Некоторые сервисные утилиты, например sfc, в своей работе активно эксплуатирует стек обслуживания и, соответственно, функции библиотеки wrpinitapi.dll , которая предоставляет поддержку функций работы с WRP. В процессе работы утилиты sfc, WRP посредством процесса TrustedInstaller.exe производит обход всех критических системных компонентов, которые важны для поддержки функционирования операционной системы. В процессе обхода файл, размещенный в системном каталоге, сравнивается с эталонным файлом, размещенным в хранилище %WinDir%\WinSxS . Если обнаруживаются какие-либо модификации системного файла, WRP восстанавливает оригинальную копию данного файла из директории %WinDir%\WinSxS\Backup , которая содержит эталоны всех защищаемых системных файлов.

Поскольку слой CSI является самым низкоуровневым в компонентной модели, он то и ответственен за фактическую инсталляцию компонентов в систему. Для инсталляции компонентов CSI активно использует хранилище компонентов. Когда добавляется новый компонент, CSI помещает его в хранилище компонентов, и определяет статус, который должен получить компонент. Назначение статуса (стадии) определяет текущее состояние пакета в хранилище компонентов. В процессе установки пакета происходит изменение промежуточных состояний пакета:

• Составить список файлов, отсутствующих в пакете. Для устанавливаемого файла, первое стадия должна быть промежуточной (staged). Некоторые из этих файлов могут уже присутствовать в хранилище компонентов, отсутствующие же требуется скачать с установочного носителя или же загрузить по Сети.
• Определить какие из файлов необходимы для установки пакета и определить файлы других пакетов, которые так же могут потребоваться во время инсталляции.
• Разрешить найденные зависимости и быть уверенным что все необходимые файлы присутствуют перед началом процесса установки.
• Выполнить установку.

Когда пакет удаляется, процесс реверсируется:

• Инсталлятор создает список всех используемых файлов, и другие действия которые необходимы для перезагрузки ОС.
• Удалить файлы или зависимости – файлы могут быть удалены из системы или могут остаться в хранилище компонентов для будущего использования.
• Неиспользуемые файлы могут быть удалены из системы, затем система может быть перезагружена для выполнения освобождения места и удаления файлов, которые были заняты (использовались) на предыдущих шагах.

Когда новая версия компонента установлена в систему, слой CSI опрашивает хранилище компонентов с целью определить, какие именно компоненты обновлены. В процессе установки компонента, CSI использует модуль Очереди простых операций (Primitive Operations Queue, POQ), который считывает список всех файлов и ключей реестра, подлежащих установке/обновлению. Продвинутые установщики или универсальные команды затем запускаются для завершения установки. Расширенные установщики запускаются в контексте процессов с использованием CMI. Если в процессе инсталляции компонента имеет место какой-либо сбой, CSI откатывает всю цепочку изменений, сделанных текущей инсталляцией. Если файл или процесс во время инсталляции компонента используется каким-либо источником и не может быть заменен, действия универсальных команд и продвинутых установщиков заносятся в файл %WinDir%\WinSXS\Pending.xml , и затем эти операции над файлами выполняются уже во время последующей перезагрузки. Если несколько пакетов устанавливаются в одно и то же время, каждый последующий (кроме первого) пакет добавляется к pending.xml . Логгирование на протяжении процесса обновления производится в файл %windir%\Logs\CBS\CBS.log .

Заключение

Зачем нам нужна подобная избыточная компонентная модель, в которой хранятся все версии всех компонентов и пакетов? Действительно, вся эта структура, в которой хранится содержимое компонентов и пакетов предыдущих версий может показаться на первый взгляд абсурдной, тем не менее этот механизм может поддерживать систему в актуальном состоянии при любых обстоятельствах. При любых откатах или удалениях вам нужно всего-лишь перепроецировать компоненты, которые находятся в хранилище в промежуточном статусе. Проекция производится по последнему имеющемуся в хранилище компоненту, надо всего-лишь перестроить зависимости.
В релизы Windows Vista и 7, обслуживание на основе компонентов (компонентная модели) были внедрены в недоработанном, «сыром» виде, что повлекло за собой большое количество проблем у пользователей, выражавшихся в возникновении разнородных ошибок обновлений.
Избыточная сложность компонентной модели, разнообразные уровни/виды составляющих её сущностей, скорее говорят нам о том, что модель явно находится в промежуточном (разрабатываемом) состоянии, и с большой вероятностью будет кардинально меняться в очередных версиях операционных систем.