Informazioni sull'esecuzione in Windows di app desktop in pacchetto

Questo articolo fornisce un'analisi più approfondita su ciò che accade ai file e alle voci del Registro di sistema quando si crea un pacchetto di app Windows per l'applicazione desktop.

Un obiettivo fondamentale di un pacchetto moderno è separare lo stato dell'applicazione dallo stato del sistema il più possibile, mantenendo la compatibilità con altre app. Windows 10 eseguire questa operazione inserendo l'applicazione all'interno di un pacchetto MSIX e quindi rilevando e reindirizzando alcune modifiche apportate al file system e al Registro di sistema in fase di esecuzione.

I pacchetti creati per l'applicazione desktop sono applicazioni desktop-only, full-trust e non sono virtualizzate o sandbox. In questo modo, possono interagire con altre app in modo analogo alle applicazioni desktop classiche.

Installazione

I pacchetti di app vengono installati su base utente anziché a livello di sistema. 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 l'applicazione viene avviata, non viene eseguita all'interno di un contenitore di app, ma viene eseguita come 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 del file system per 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 rigido dei file. Quando un utente scarica un pacchetto MSIX, viene usato il AppxManifest.xml 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 64k, anche se esiste una percentuale di un file scaricato su disco, viene scaricato solo l'incremento diverso. Ciò riduce la larghezza di banda usata per il download.

Operazioni appData su Windows 10, versione 1903 e versioni 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, per ogni app, ma unito in fase di esecuzione da visualizzare nel percorso AppData reale. Ciò consente una certa separazione dello stato per gli artefatti usati solo dall'applicazione stessa e questo consente al sistema di pulire tali file quando l'applicazione viene disinstallata. Le modifiche ai file esistenti nella cartella AppData dell'utente possono fornire un grado di compatibilità e di interattività superiore tra applicazioni e sistema operativo. Ciò riduce il file system "rot" 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 selezionare la posizione in cui è stata interrotta una versione non in pacchetto della stessa applicazione. Si noti che il sistema operativo non supporta una cartella VFS (Virtual File System) per la cartella AppData dell'utente.

Operazioni appData su Windows 10, versione 1809 e versioni precedenti

Tutte le scritture nella cartella AppData dell'utente ,ad esempio C:\Users\user_name\AppData, inclusi la creazione, l'eliminazione e l'aggiornamento, vengono copiati in scrittura in un percorso privato per utente, per ogni app. Ciò crea l'illusione che l'applicazione in pacchetto stia modificando il reale AppData quando viene effettivamente modificata una copia privata. Reindirizzando in questo modo le scritture, il sistema può tenere traccia di tutte le modifiche ai file effettuate dall'app. Ciò consente al sistema di pulire tali file quando l'applicazione viene disinstallata, riducendo così il sistema "rot" e fornendo un'esperienza di rimozione dell'applicazione migliore per l'utente.

Directory di lavoro e file dell'applicazione

Oltre a reindirizzare AppData, Windows le cartelle note (System32, Programmi (x86) e così via. vengono uniti dinamicamente con 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 può contenere C:\Program Files\WindowsApps\package_name\VFS\SystemX86\vc10.dll come parte del pacchetto dell'app, ma il file sembra essere installato in C:\Windows\System32\vc10.dll. Ciò mantiene la compatibilità con le applicazioni desktop che prevedono che i file siano presenti in percorsi non in pacchetto.

Le scritture in file/cartelle nel pacchetto dell'app non sono consentite. Le scritture in file e cartelle che non fanno parte del pacchetto vengono ignorate dal sistema operativo e sono consentite a condizione che l'utente disponga dell'autorizzazione.

Operazioni comuni

Questa breve tabella di riferimento mostra le operazioni comuni del file system e il modo in cui il sistema operativo li 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 versioni successive: i nuovi file e le cartelle creati nelle directory seguenti vengono reindirizzati a un percorso privato per utente, per pacchetto:
  • Locale
  • Locale\Microsoft
  • Roaming
  • Roaming\Microsoft
  • Roaming\Microsoft\Windows\Menu Start\Programmi
In risposta a un comando aperto file, il sistema operativo aprirà il file dal percorso per utente, per ogni pacchetto. Se questa posizione non esiste, il sistema operativo tenterà di aprire il file dal percorso appData reale. Se il file viene aperto dal percorso appData reale, non si verifica 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 scritta in un percorso per utente, per ogni 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 percepisce questi file nei percorsi di sistema elencati, quando in realtà si trovano nei percorsi reindirizzati all'interno di C:\Programmi\WindowsApps\package_name\VFS. I percorsi FOLDERID provengono 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 non fanno parte del pacchetto sono consentite fino a quando l'utente dispone dell'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 scritture vengono mantenute durante l'aggiornamento del pacchetto ed eliminate solo quando l'applicazione viene rimossa completamente.

Operazioni comuni

Questa breve tabella di riferimento mostra le operazioni comuni del Registro di sistema e il modo in cui il sistema operativo li 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, tutti i file e le cartelle presenti in C:\Programmi\WindowsApps\package_name vengono rimossi, nonché eventuali scritture reindirizzate a AppData o al Registro di sistema acquisiti durante il processo di creazione del pacchetto.