Comprendre la façon dont les applications de bureau empaquetées s’exécutent sur Windows
Cet article explique de manière approfondie ce qu’il advient aux fichiers et aux entrées de Registre quand vous créez un package d’application Windows pour votre application de bureau.
L’un des principaux objectifs d’un package moderne est de séparer autant que possible l’état de l’application de l’état du système tout en conservant la compatibilité avec les autres applications. Windows 10 accomplit cela en plaçant l’application dans un package MSIX, puis en détectant et en redirigeant certaines modifications apportées au système de fichiers et au Registre au moment de l’exécution.
Les packages que vous créez pour vos applications de bureau sont des applications totalement approuvées, uniquement de bureau, qui ne sont pas virtualisées ni mises en mode Bac à sable. Ainsi, ils peuvent interagir avec d’autres applications comme le font les applications de bureau classiques.
Installation
Les packages de l’application sont installés par utilisateur plutôt qu’à l’échelle du système. Les packages d’application sont installés sous C:\Program Files\WindowsApps\nom_package, avec le fichier exécutable intitulé app_name.exe. Chaque dossier du package comporte un manifeste (nommé AppxManifest.xml) qui contient un espace de noms XML spécial pour les applications empaquetées. Ce fichier manifeste contient un élément <EntryPoint> qui fait référence à l’application totalement approuvée. Quand cette application est lancée, elle ne s’exécute pas à l’intérieur d’un conteneur d’applications, mais comme un utilisateur le ferait normalement.
Après le déploiement, les fichiers du package sont marqués en lecture seule et fortement verrouillés par le système d’exploitation. Windows empêche le lancement des applications si ces fichiers sont falsifiés.
Système de fichiers
Le système d’exploitation prend en charge différents niveaux d’opérations de système de fichiers pour les applications de bureau packagées, en fonction de l’emplacement du dossier.
Optimisation pour votre appareil
Afin d’éviter la duplication des fichiers pour optimiser l’espace de stockage sur disque et réduire la bande passante nécessaire lors du téléchargement de fichiers, le système d’exploitation tire parti du stockage unique et de l’établissement du lien physique des fichiers. Lorsqu’un utilisateur télécharge un package MSIX, AppxManifest.xml est utilisé pour déterminer si les données contenues dans le package existent déjà sur le disque depuis une installation de package antérieure. Si le même fichier existe dans plusieurs packages MSIX, le système d’exploitation ne stocke le fichier partagé sur le disque qu’une seule fois et crée des liens physiques entre les deux packages et le fichier partagé. Étant donné que les fichiers sont téléchargés dans des blocs de 64 Ko, même si un pourcentage d’un fichier en cours de téléchargement existe sur le disque, seul l’incrément qui est différent est téléchargé. Cela réduit la bande passante utilisée pour le téléchargement.
Opérations AppData sur Windows 10, version 1903 et ultérieures
Tous les fichiers et dossiers nouvellement créés dans le dossier AppData de l’utilisateur (par exemple, C:\Users\ nom_utilisateur\AppData) sont écrits dans un emplacement privé par utilisateur et par application, mais fusionnés au moment de l’exécution pour apparaître à l’emplacement AppData réel. Cela procure un certain degré de séparation des états pour les artefacts utilisés uniquement par l’application elle-même, et permet au système de nettoyer ces fichiers quand l’application est désinstallée. Les modifications apportées aux fichiers existants dans le dossier AppData de l’utilisateur sont autorisées afin de fournir un degré plus élevé de compatibilité et d’interactivité entre les applications et le système d’exploitation. Cela permet de réduire la « détérioration » du système de fichiers, car le système d’exploitation est conscient de chaque modification de fichier ou de répertoire effectuée par une application. La séparation des états permet également aux applications de bureau empaquetées de reprendre là où une version non empaquetée de la même application s’est arrêtée. Notez que le système d’exploitation ne prend pas en charge les dossiers de système de fichiers virtuel comme dossiers AppData de l’utilisateur.
Opérations AppData sur Windows 10, version 1809 et antérieures
Toutes les écritures effectuées dans le dossier AppData de l’utilisateur (par exemple, C:\Users\nom_utilisateur\AppData), y compris la création, la suppression et la mise à jour, sont copiées au moment de l’écriture dans un emplacement privé par utilisateur et par application. Cela crée l’illusion que l’application empaquetée modifie vraiment AppData, alors qu’elle modifie en fait une copie privée. En redirigeant les écritures de cette façon, le système peut suivre toutes les modifications de fichier effectuées par l’application. Ainsi, le système peut nettoyer ces fichiers quand l’application est désinstallée, réduisant la « détérioration » du système et fournissant une meilleure expérience de suppression d’application à l’utilisateur.
Répertoire de travail et fichiers d’application
En plus de rediriger AppData, les dossiers connus de Windows (System32, Program Files (x86), etc.) sont dynamiquement fusionnés avec les répertoires correspondants dans le package d’application. Chaque package contient un dossier nommé « VFS » à sa racine. Toutes les lectures de répertoires ou de fichiers dans le répertoire VFS sont fusionnées à l’exécution avec leurs équivalents natifs respectifs. Par exemple, une application peut contenir C:\Program Files\WindowsApps\package_name\VFS\SystemX86\vc10.dll dans son package d’application, tandis que le fichier semble être installé dans C:\Windows\System32\vc10.dll. Cela permet d’assurer la compatibilité avec les applications de bureau qui s’attendent à trouver les fichiers ailleurs que dans les packages.
Les écritures dans les fichiers/dossiers du package d’application ne sont pas autorisées. Les écritures dans les fichiers et dossiers qui ne font pas partie du package sont ignorées par le système d’exploitation, et sont autorisées si l’utilisateur a une autorisation.
Opérations courantes
Le petit tableau de référence suivant présente les opérations courantes du système de fichiers et la manière dont le système d’exploitation les gère.
| Opération | Résultat | Exemple |
|---|---|---|
| Lire ou énumérer un fichier ou un dossier Windows connu | Fusion dynamique de C:\Program Files\nom_package\VFS\dossier_connu avec l’équivalent du système local. | La lecture de C:\Windows\System32 renvoie le contenu de C:\Windows\System32 ainsi que le contenu de C:\Program Files\WindowsApps\nom_package\VFS\SystemX86. |
| Écrire sous AppData | Windows 10, versions 1903 et ultérieures : Les fichiers et dossiers créés sous les répertoires suivants sont redirigés vers un emplacement privé par utilisateur et par package :
|
AppData est généralement C:\Users\nom_utilisateur\AppData. |
| Écrire à l’intérieur du package | Non autorisé. Le package est en lecture seule. | Les écritures sous C:\Program Files\WindowsApps\nom_package ne sont pas autorisées. |
| Écrit en dehors du package | Autorisé si l’utilisateur a des autorisations. | Une écriture dans C:\Windows\System32\foo.dll est autorisée si le package ne contient pas C:\Program Files\WindowsApps\nom_package\VFS\SystemX86\foo.dll et si l’utilisateur a des autorisations. |
Emplacements de VFS empaquetés
Le tableau suivant montre où les fichiers intégrés à votre package sont superposés sur le système de l’application. Votre application détectera ces fichiers comme se trouvant aux emplacements système répertoriés, alors qu’en réalité ils se trouvent aux emplacements redirigés dans C:\Programmes\WindowsApps\nom_package\VFS. Les emplacements FOLDERID proviennent des constantes KNOWNFOLDERID.
| Emplacement système | Emplacement redirigé (sous [Racine du package] \VFS\) | Valide sur les architectures |
|---|---|---|
| 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 | Common 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 |
Registre
Les packages d’application contiennent un fichier registry.dat, qui est l’équivalent logique de HKLM\Software dans le vrai Registre. À l’exécution, ce Registre virtuel fusionne le contenu de cette ruche dans la ruche du système natif afin de fournir un affichage unique des deux. Par exemple, si registry.dat contient une seule clé « Foo », la lecture de HKLM\Software à l’exécution semble également contenir « Foo » (en plus de toutes les clés système natives).
Bien que les packages MSIX incluent des clés HKLM et HKCU, ils sont traités différemment. Seules les clés sous HKLM\Software font partie du package. Les touches sous HKCU ou d’autres parties du Registre n’en font pas partie. Les écritures dans les clés ou les valeurs du package ne sont pas autorisées. Les écritures dans les clés ou les valeurs qui ne font pas partie du package sont autorisées dans la mesure où l’utilisateur a une autorisation.
Toutes les écritures sous HKCU sont copiées à l’écriture dans un emplacement privé par utilisateur, par application. Traditionnellement, les programmes de désinstallation ne parviennent pas à nettoyer HKEY_CURRENT_USER car les données du Registre des utilisateurs déconnectées sont déchargées et inaccessibles.
Toutes les écritures sont conservées pendant la mise à niveau du package et supprimées seulement quand l’application est entièrement supprimée.
Opérations courantes
Le petit tableau de référence suivant présente les opérations courantes du Registre et la manière dont le système d’exploitation les gère.
| Opération | Résultat | Exemple |
|---|---|---|
| Lire ou énumérer HKLM\Software | Fusion dynamique de la ruche du package avec l’équivalent du système local. | Si registry.dat contient une seule clé « Foo », à l’exécution la lecture de HKLM\Software affiche le contenu de HKLM\Software et de HKLM\Software\Foo. |
| Écritures sous HKCU | Copie à l’écriture dans un emplacement privé par utilisateur, par application. | Identique à AppData pour les fichiers. |
| Écritures à l’intérieur du package. | Non autorisé. Le package est en lecture seule. | Les écritures sous HKLM\Software ne sont pas autorisées si un clé/valeur correspondante existe dans la ruche du package. |
| Écrit en dehors du package | Ignoré par le système d’exploitation. Autorisé si l’utilisateur a des autorisations. | Les écritures sous HKLM\Software sont autorisées dans la mesure où une clé/valeur correspondante n’existe pas dans la ruche du package et où l’utilisateur a les autorisations d’accès appropriées. |
Désinstallation
Quand un package est désinstallé par l’utilisateur, tous les fichiers et dossiers situés dans C:\Programmes\WindowsApps\nom_package sont supprimés, ainsi que les écritures redirigées vers AppData ou le Registre capturées durant le processus d’empaquetage.