Informazioni sull'esecuzione in Windows di app desktop in pacchetto

Questo articolo fornisce un approfondimento su cosa accade ai file e alle voci del Registro di sistema quando si crea un pacchetto dell Windows app per l'applicazione desktop.

Un obiettivo chiave di un pacchetto moderno è quello di separare il più possibile lo stato dell'applicazione dallo stato del sistema mantenendo la compatibilità con altre app. Windows 10 a questo scopo, posizionare l'applicazione all'interno di un pacchetto MSIX e quindi rilevare e reindirizzare alcune modifiche apportate al registro file system e al Registro di sistema in fase di esecuzione.

I pacchetti creati per l'applicazione desktop sono applicazioni con attendibilità totale solo desktop e non sono virtualizzati o sandbox. In questo modo, possono interagire con altre app in modo analogo alle applicazioni desktop classiche.

Installazione

I pacchetti delle app vengono installati in C:\Programmi\WindowsApps\nome_pacchetto e il nome del file eseguibile è nome_app.exe. Ogni cartella del pacchetto contiene un manifesto (denominato AppxManifest.xml) che contiene uno spazio dei nomi XML speciale per le app in pacchetto. All'interno di tale file manifesto c'è un elemento <EntryPoint> che fa riferimento all'app con attendibilità totale. Quando viene avviata, l'applicazione non viene eseguita all'interno di un contenitore di app, ma viene eseguita come l'utente normalmente.

Dopo la distribuzione, i file di pacchetto vengono contrassegnati come di sola lettura e bloccati dal sistema operativo. Se questi file vengono manomessi, Windows impedisce l'avvio delle app.

File system

Il sistema operativo supporta diversi livelli di operazioni file system per le applicazioni desktop in pacchetto, a seconda del percorso della cartella.

Ottimizzato per il dispositivo

Per evitare la duplicazione dei file per ottimizzare lo spazio di archiviazione su disco e ridurre la larghezza di banda necessaria durante il download dei file, il sistema operativo sfrutta l'archiviazione singola e il collegamento diretto dei file. Quando un utente scarica un pacchetto MSIX, il AppxManifest.xml viene usato per determinare se i dati contenuti nel pacchetto esistono già su disco da un'installazione precedente del pacchetto. Se lo stesso file esiste in più pacchetti MSIX, il sistema operativo archivia il file condiviso su disco una sola volta e crea collegamenti rigidi da entrambi i pacchetti al file condiviso. Poiché i file vengono scaricati in blocchi di 64.000, anche se una percentuale di un file scaricato esiste su disco, viene scaricato solo l'incremento diverso. In questo modo si riduce la larghezza di banda usata per il download.

Operazioni AppData in Windows 10, versione 1903 e successive

Tutti i file e le cartelle appena creati nella cartella AppData dell'utente (ad esempio, C:\Users\user_name\AppData) vengono scritti in un percorso privato per utente e per app, ma uniti in fase di esecuzione per essere visualizzati nel percorso AppData reale. Ciò consente un certo grado di separazione dello stato per gli elementi usati solo dall'applicazione stessa e ciò consente al sistema di pulire tali file quando l'applicazione viene disinstallata. Le modifiche ai file esistenti nella cartella AppData dell'utente possono offrire un livello più elevato di compatibilità e interattività tra le applicazioni e il sistema operativo. In questo modo si riduce la "rot" del file system perché il sistema operativo è a conoscenza di ogni modifica di file o directory apportata da un'applicazione. La separazione dello stato consente anche alle applicazioni desktop in pacchetto di riprendere il punto in cui una versione non in pacchetto della stessa applicazione è stata erta. Si noti che il sistema operativo non supporta una cartella file system virtuale (VFS) per la cartella AppData dell'utente.

Operazioni AppData in Windows 10, versione 1809 e versioni precedenti

Tutte le scritture nella cartella AppData dell'utente (ad esempio, C:\Users\user_name\AppData), incluse le operazioni di creazione, eliminazione e aggiornamento, vengono copiate in scrittura in un percorso privato per utente e per app. In questo modo si crea l'avaria del fatto che l'applicazione in pacchetto sta modificando il vero AppData quando sta effettivamente modificando una copia privata. Reindirizzando in questo modo le scritture, il sistema può tenere traccia di tutte le modifiche ai file effettuate dall'app. In questo modo il sistema può pulire tali file quando l'applicazione viene disinstallata, riducendo in tal modo la "rot" del sistema e offrendo una migliore esperienza di rimozione dell'applicazione per l'utente.

Altre cartelle

Oltre al reindirizzamento di AppData, le cartelle note di Windows (System32, Programmi (x86) e così via vengono unite dinamicamente alle directory corrispondenti nel pacchetto dell'app. Ogni pacchetto contiene una cartella denominata "VFS" nella radice. Le letture delle directory o dei file nella directory VFS vengono unite in fase di esecuzione con le rispettive controparti native. Ad esempio, un'applicazione potrebbe contenere C:\Program Files\WindowsApps\package_name\VFS\SystemX86\vc10.dll come parte del pacchetto dell'app, ma il file sembra essere installato inC:\Windows\System32\vc10.dll. Questo consente di mantenere la compatibilità con le applicazioni desktop che potrebbero aspettarsi che i file si trovino in percorsi esterni al pacchetto.

Le scritture in file/cartelle nel pacchetto dell'app non sono consentite. Le scritture nei file e nelle cartelle che non fanno parte del pacchetto vengono ignorate dal sistema operativo e sono consentite purché l'utente abbia l'autorizzazione.

Operazioni comuni

Questa breve tabella di riferimento illustra le operazioni file system e il modo in cui il sistema operativo le gestisce.

Operazione Risultato Esempio
Lettura o enumerazione di una cartella o un file noto di Windows Unione dinamica di C:\Programmi\nome_pacchetto\VFS\cartella_nota con l'equivalente di sistema locale. La lettura di C:\Windows\System32 restituisce i contenuti di C:\Windows\System32 più i contenuti di C:\Programmi\WindowsApps\nome_pacchetto\VFS\SystemX86.
Scrittura in AppData Windows 10 versione 1903 e successive: I nuovi file e cartelle creati nelle directory seguenti vengono reindirizzati a un percorso privato per utente e per pacchetto:
  • Locale
  • Local\Microsoft
  • Roaming
  • Roaming\Microsoft
  • Roaming\Microsoft\Windows\Menu Start\Programmi
In risposta a un comando di apertura file, il sistema operativo aprirà prima il file dal percorso per utente e per pacchetto. Se questo percorso non esiste, il sistema operativo tenterà di aprire il file dal percorso AppData reale. Se il file viene aperto dal percorso AppData reale, non viene eseguita alcuna virtualizzazione per tale file. Le eliminazioni di file in AppData sono consentite se l'utente dispone delle autorizzazioni.

Windows 10, versione 1809 e versioni precedenti: Copia su scrittura in una posizione per utente e per app.

AppData si trova in genere in C:\Utenti\nome_utente\AppData.
Scrittura all'interno del pacchetto Non consentiti. Il pacchetto è di sola lettura. Le scritture in C:\Programmi\WindowsApps\nome_pacchetto non sono consentite.
Scritture all'esterno del pacchetto Consentite se l'utente dispone delle autorizzazioni. Un'operazione di scrittura in C:\Windows\System32\foo.dll è consentita se il pacchetto non contiene C:\Programmi\WindowsApps\nome_pacchetto\VFS\SystemX86\foo.dll e l'utente ha le autorizzazioni.

Percorsi dei pacchetti VSF

La tabella seguente illustra i percorsi in cui i file inclusi nel pacchetto vengono sovrapposti nel sistema per l'app. L'applicazione percepirà questi file nei percorsi di sistema elencati, quando in realtà si trova nei percorsi reindirizzati all'interno di C:\Programmi\WindowsApps\package_name\VFS. I percorsi FOLDERID derivano dalle costanti KNOWNFOLDERID.

Percorso di sistema Percorso reindirizzato (in [PackageRoot]\VFS) Architetture interessate
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 Dati applicazioni comuni 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

I pacchetti dell'app contengono un file registry.dat, che funge da equivalente logico di HKLM\Software nel registro reale. In fase di esecuzione, questo Registro di sistema virtuale unisce il contenuto di questo hive con l'hive di sistema nativo per fornire una vista singola di entrambi. Se, ad esempio, registry.dat contiene una singola chiave "Foo", un'operazione di lettura di HKLM\Software in fase di esecuzione conterrà anch'essa "Foo" (oltre a tutte le chiavi di sistema native).

Anche se i pacchetti MSIX includono chiavi HKLM e HKCU, vengono trattati in modo diverso. Solo le chiavi in HKLM\Software fanno parte del pacchetto, mentre quelle in HKCU o in altre parti del Registro di sistema no. Le scritture in chiavi o valori del pacchetto non sono consentite. Le scritture in chiavi o valori che non fanno parte del pacchetto sono consentite purché l'utente abbia l'autorizzazione.

Per tutte le scritture in HKCU, viene eseguita una copia su scrittura in un percorso privato per ogni singolo utente e ogni singola app. In genere, i programmi di disinstallazione non sono in grado di pulire HKEY_CURRENT_USER perché i dati del Registro di sistema per gli utenti disconnessi sono smontati e non sono disponibili.

Tutte le operazioni di scrittura vengono mantenute durante l'aggiornamento del pacchetto e vengono eliminate solo quando l'applicazione viene rimossa completamente.

Operazioni comuni

Questa breve tabella di riferimento illustra le operazioni comuni del Registro di sistema e il modo in cui il sistema operativo le gestisce.

Operazione Risultato Esempio
Lettura o enumerazione di HKLM\Software Unione dinamica dell'hive del pacchetto con l'equivalente di sistema locale. Se registry.dat contiene una singola chiave "Foo", un'operazione di lettura di HKLM\Software mostrerà i contenuti sia di HKLM\Software che di HKLM\Software\Foo.
Scritture in HKCU Copia su scrittura in un percorso privato per ogni singolo utente e ogni singola app. Analogo ad AppData per i file.
Scritture all'interno del pacchetto. Non consentiti. Il pacchetto è di sola lettura. Le scritture in HKLM\Software non sono consentite se c'è una coppia chiave/valore corrispondente nell'hive del pacchetto.
Scritture all'esterno del pacchetto Ignorato dal sistema operativo. Consentite se l'utente dispone delle autorizzazioni. Le scritture in HKLM\Software sono consentite a condizione che non ci sia una coppia chiave/valore corrispondente nell'hive del pacchetto e che l'utente abbia le autorizzazioni di accesso appropriate.

Disinstallazione

Quando un pacchetto viene disinstallato dall'utente, vengono rimossi tutti i file e le cartelle presenti in C:\Programmi\WindowsApps\package_name, nonché tutte le scritture reindirizzate in AppData o nel Registro di sistema acquisite durante il processo di creazione del pacchetto.