Compartir a través de

Descripción de cómo se ejecutan las aplicaciones de escritorio empaquetadas en Windows

En este tema se describen los tipos de aplicaciones de escritorio para los que puedes crear un paquete de aplicaciones de Windows, junto con algunos comportamientos del sistema operativo (SO) y otros específicos, que son importantes para tener en cuenta. Veremos los detalles de los siguientes elementos (como veremos, el comportamiento específico depende del tipo de aplicación):

Tipos de aplicación de escritorio

Hay dos tipos de aplicaciones de escritorio que puede crear y empaquetar. El tipo de la aplicación se declara en el manifiesto del paquete de la aplicación mediante el atributo uap10:RuntimeBehavior del elemento Application :

  • Un tipo incluye las aplicaciones WinUI 3 (que usan el Windows App SDK) y las aplicaciones de puente para escritorio (Centennial). Declarado con uap10:RuntimeBehavior="packagedClassicApp".
  • El otro tipo representa otros tipos de aplicación Win32, incluidas las aplicaciones empaquetadas con ubicación externa. Declarado con uap10:RuntimeBehavior="win32App".

Las aplicaciones de la Plataforma universal de Windows (UWP) (uap10:RuntimeBehavior="windowsApp") también se empaquetan; pero este tema no se trata de ellas.

Y, a continuación, el atributo uap10:TrustLevel (del mismo elemento Application ) determina si el proceso de la aplicación empaquetada se ejecuta dentro de un contenedor de aplicaciones.

  • Una aplicación de plena confianza . Declarado con uap10:TrustLevel="mediumIL".
  • Una aplicación appContainer . Declarado con uap10:TrustLevel="appContainer". Se ejecuta en un contenedor ligero de aplicaciones (y, por tanto, se aísla mediante la virtualización del registro y el sistema de archivos). Para obtener más información, consulta Aplicaciones de contenedor de aplicaciones MSIX.

Importante

Para obtener más información, dependencias y requisitos de funcionalidad, consulte la documentación de esos dos atributos en Application. Vea también uap10 se introdujo en Windows 10, versión 2004 (10.0; Compilación 19041).

El propósito del empaquetado y los contenedores de aplicaciones

El propósito de empaquetar la aplicación es concederle la identidad del paquete en tiempo de ejecución. La identidad del paquete es necesaria para determinadas características de Windows (consulte Características que requieren la identidad del paquete). Puede empaquetar todas las combinaciones de tipos de aplicación descritos anteriormente (y, por tanto, beneficiarse de la identidad del paquete).

Pero un objetivo clave de una aplicación appContainer es separar el estado de la aplicación del estado del sistema tanto como sea posible, al tiempo que se mantiene la compatibilidad con otras aplicaciones. Windows logra que mediante la detección y redirección de determinados cambios que realice en el sistema de archivos y el registro en tiempo de ejecución (conocido como virtualizar). Avisaremos cuando una sección solo se aplique a las aplicaciones virtualizadas.

Instalación

Los paquetes de aplicaciones se instalan por usuario en lugar de en todo el sistema. La ubicación predeterminada de los nuevos paquetes de una máquina nueva está en C:\Program Files\WindowsApps\<package_full_name>, con el ejecutable denominado app_name.exe. Pero los paquetes se pueden instalar en otros lugares; por ejemplo, los comandos Start de Visual Studio usan el $(OutDir).

Después de la implementación, los archivos de paquete se marcan como de solo lectura y están bloqueados en gran medida por el sistema operativo (SO). Windows impide que las aplicaciones se inicien si esos archivos se manipulan.

La C:\Program Files\WindowsApps ubicación se conoce como PackageVolume. Esa ubicación es el PackageVolume predeterminado con el que Windows se distribuye; pero puede crear un PackageVolume en cualquier unidad de disco y en cualquier ruta de acceso. Además, no todos los paquetes se instalan en packageVolume (vea el ejemplo de Visual Studio anterior).

Sistema de archivos

El sistema operativo admite diferentes niveles de operaciones del sistema de archivos para aplicaciones de escritorio empaquetadas, en función de la ubicación de la carpeta.

Optimizado para el dispositivo

Para evitar la duplicación de archivos (para optimizar el espacio de almacenamiento en disco y reducir el ancho de banda necesario al descargar archivos), el sistema operativo aprovecha el almacenamiento único y la vinculación de archivos de forma dura. Cuando un usuario descarga un paquete MSIX, AppxManifest.xml se usa para determinar si los datos contenidos con el paquete ya existen en el disco desde una instalación de paquete anterior. Si el mismo archivo existe en varios paquetes MSIX, el sistema operativo almacena el archivo compartido en el disco una sola vez y crea vínculos físicos de ambos paquetes al archivo compartido. Dado que los archivos se descargan en bloques de 64 Kb, incluso si una parte del archivo que se está descargando ya existe en el disco, solo se descarga la parte que es diferente. Esto reduce el ancho de banda usado para la descarga.

Operaciones de AppData en Windows 10, versión 1903 y posteriores

Esta sección solo se aplica a las aplicaciones virtualizadas.

Todos los archivos y carpetas recién creados en la carpeta del AppData usuario (por ejemplo, C:\Users\<user_name>\AppData) se almacenan en una ubicación privada específica para cada usuario y aplicación, pero se combinan en tiempo de ejecución para que aparezcan en la ubicación real AppData. Esto permite cierto grado de separación de estado para artefactos que solo usan la propia aplicación; que permite al sistema limpiar esos archivos cuando se desinstala la aplicación.

Se permiten modificaciones en los archivos existentes en la carpeta del AppData usuario para proporcionar un mayor grado de compatibilidad e interactividad entre las aplicaciones y el sistema operativo. Esto reduce el "rot" del sistema porque el sistema operativo es consciente de cada cambio de archivo o directorio realizado por una aplicación. La separación de estado también permite a las aplicaciones de escritorio empaquetadas recoger dónde se dejó una versión desempaquetada de la misma aplicación. Tenga en cuenta que el sistema operativo no admite una carpeta del sistema de archivos virtual (VFS) para la carpeta del AppData usuario.

Operaciones de AppData en sistemas operativos anteriores a Windows 10, versión 1903

Esta sección solo se aplica a las aplicaciones virtualizadas.

Todas las escrituras en la carpeta del AppData usuario (por ejemplo, C:\Users\<user_name>\AppData), incluida la creación, eliminación y actualización, se copian en escritura en una ubicación privada por usuario y por aplicación. Esto crea la ilusión de que la aplicación empaquetada está editando el real AppData cuando realmente está modificando una copia privada. Al redirigir las escrituras de este modo, el sistema puede realizar un seguimiento de todas las modificaciones de archivos realizadas por la aplicación. Esto permite al sistema limpiar esos archivos cuando se desinstala la aplicación, lo que reduce el "rot" del sistema y proporciona una mejor experiencia de eliminación de aplicaciones para el usuario.

Directorio de trabajo y archivos de aplicación

Esta sección solo se aplica a las aplicaciones virtualizadas.

Además de redirigir AppData, las carpetas conocidas de Windows (System32, Program Files (x86), etc.) se combinan dinámicamente con los directorios correspondientes del paquete de la aplicación. Cada paquete contiene una carpeta denominada VFS en su raíz. Las lecturas de directorios o archivos del directorio VFS se combinan en tiempo de ejecución con sus respectivos homólogos nativos. Por ejemplo, una aplicación podría contener C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll como parte de su paquete de aplicación, pero el archivo parecería estar instalado en C:\Windows\System32\vc10.dll. Esto mantiene la compatibilidad con las aplicaciones de escritorio que esperan que los archivos se ubiquen en ubicaciones que no pertenecen a paquetes.

No se permiten escrituras en archivos o carpetas en el paquete de la aplicación. El sistema operativo omite las escrituras en archivos y carpetas que no forman parte del paquete y se permiten siempre y cuando el usuario tenga permiso.

Operaciones comunes del sistema de archivos

En esta tabla de referencia breve se muestran las operaciones comunes del sistema de archivos y cómo los controla el sistema operativo.

Operación Resultado Ejemplo
Leer o enumerar un archivo o carpeta de Windows conocido Combinación dinámica de C:\Program Files\<package_full_name>\VFS\<well_known_folder> con el homólogo del sistema local. La lectura C:\Windows\System32 devuelve el contenido de C:\Windows\System32 más el contenido de C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86.
Escribir en AppData Windows 10, versión 1903 y posteriores: los nuevos archivos y carpetas creados en los directorios siguientes se redirigen a una ubicación privada por usuario y por paquete:
  • Local
  • Local\Microsoft
  • Movilidad
  • Roaming\Microsoft
  • Roaming\Microsoft\Windows\Menú de inicio\Programas
En respuesta a un comando de apertura de archivo, el sistema operativo abrirá primero el archivo desde la ubicación por usuario y por paquete. Si esa ubicación no existe, el sistema operativo intentará abrir el archivo desde la ubicación real AppData . Si el archivo se abre desde la ubicación real AppData , no se produce ninguna virtualización para ese archivo. Se permiten eliminaciones de archivos en AppData si el usuario tiene permisos.

Anterior a Windows 10, versión 1903: copiar en escritura en una ubicación por usuario y por aplicación.

 AppData es típicamente C:\Users\<user_name>\AppData.
Escribir dentro del paquete No permitido. El paquete es de solo lectura. No se permiten escrituras en C:\Program Files\WindowsApps\<package_full_name>.
Escribir en el exterior del paquete Se permite si el usuario tiene permisos. Se permite una escritura en C:\Windows\System32\foo.dll si el paquete no contiene C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dlly el usuario tiene permisos.

Ubicaciones de VFS empaquetadas

Esta sección solo se aplica a las aplicaciones virtualizadas.

En esta tabla se muestra dónde se superponen los archivos como parte del paquete en el sistema para la aplicación. La aplicación percibirá estos archivos como si estuvieran en las ubicaciones del sistema enumeradas cuando, de hecho, están en las ubicaciones redirigidas dentro de C:\Program Files\WindowsApps\<package_full_name>\VFS. Las ubicaciones FOLDERID proceden de las constantes KNOWNFOLDERID .

Ubicación del sistema Ubicación redirigida (en [<package_root>]\VFS) Válido en arquitecturas
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 Común 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

Registro

Esta sección (y sus subsecciones) solo se aplican a las aplicaciones virtualizadas.

Los paquetes de aplicación contienen un registry.dat archivo, que actúa como equivalente lógico (virtual) de HKLM\Software en el registro real. En tiempo de ejecución, el registro virtual combina el contenido de ese subárbol en el subárbol del sistema nativo para proporcionar una sola vista de ambos. Por ejemplo, si registry.dat contiene una sola clave Foo, una lectura de HKLM\Software en tiempo de ejecución también parecerá contener Foo (además de todas las claves del sistema nativas).

Aunque los paquetes MSIX incluyen claves HKLM y HKCU , se tratan de forma diferente. Solo las claves de HKLM\Software forman parte del paquete; las claves de HKCU u otras partes del Registro no lo son. No se permiten escrituras en claves o valores del paquete. Las escrituras en claves o valores que no forman parte del paquete se permiten siempre y cuando el usuario tenga permiso.

Todas las escrituras en HKCU se copian en escritura en una ubicación privada por usuario y por aplicación. Tradicionalmente, los desinstaladores no pueden limpiar HKEY_CURRENT_USER porque los datos del Registro para los usuarios que han cerrado sesión están desmontados y no están disponibles.

Todas las escrituras se conservan durante la actualización del paquete y solo se eliminan cuando la aplicación se quita por completo.

Operaciones comunes del Registro

La mayoría de esta sección solo se aplica a las aplicaciones virtualizadas.

En esta tabla de referencia breve se muestran las operaciones comunes del Registro y cómo los controla el sistema operativo.

Operación Resultado Ejemplo
Leer o enumerar HKLM\Software Combinación dinámica del subárbol del paquete con el homólogo del sistema local. Si registry.dat contiene una sola clave Foo, en tiempo de ejecución, una lectura de HKLM\Software muestra el contenido de HKLM\Software y HKLM\Software\Foo.
Escrituras en HKCU Copiado en escritura en una ubicación privada por usuario y por aplicación. Igual que AppData para los archivos.
Escribe dentro del paquete. No permitido. El paquete es de solo lectura. No se permiten escrituras en HKLM\Software si existe una clave o valor correspondiente en el subárbol del paquete.
Escrituras fuera del paquete Ignorado por el sistema operativo. Se permite si el usuario tiene permisos. Las escrituras en HKLM\Software se permiten siempre y cuando no exista una clave o valor correspondiente en el subárbol del paquete y el usuario tenga los permisos de acceso correctos.

Desinstalación

Esta sección solo se aplica a las aplicaciones virtualizadas.

Cuando el usuario desinstala un paquete, se quitan todos los archivos y carpetas ubicados en C:\Program Files\WindowsApps\<package_full_name> , así como las escrituras redirigidas a AppData o al registro que se capturaron durante el proceso de empaquetado.