Informazioni sul funzionamento di Desktop Bridge

Questo articolo fornisce informazioni approfondite su come funziona Desktop Bridge.

Uno degli obiettivi principali di Desktop Bridge è quello di separare il più possibile lo stato dell'applicazione dallo stato del sistema, mantenendo nel contempo la compatibilità con altre app. Questo risultato viene ottenuto inserendo l'applicazione in un pacchetto UWP (Universal Windows Platform), quindi rilevando e reindirizzando alcune modifiche apportate dall'applicazione al file system e al Registro di sistema in fase di esecuzione.

I pacchetti creati per l'app desktop sono app solo desktop con attendibilità totale e non sono virtualizzati o in modalità 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 include 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. All'avvio, tale app non viene eseguita all'interno di un contenitore di app, ma invece viene eseguita nel contesto dell'utente, come avviene 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

Per contenere lo stato dell'app, il bridge tenta di acquisire le modifiche apportate dall'app ad AppData. Per tutte le scritture nella cartella AppData dell'utente (ad esempio, C:\Utenti\nome_utente\AppData), tra cui creazione, eliminazione e aggiornamento, viene eseguita una copia su scrittura in un percorso privato per ogni singolo utente e ogni singola app. Ciò crea l'illusione che l'app in pacchetto stia modificando la cartella AppData reale, mentre invece viene 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 eseguire la pulizia di questi file quando l'app viene disinstallata, riducendo così il deterioramento del sistema e offrendo all'utente un'esperienza di rimozione delle app migliore.

Oltre a reindirizzare AppData, il bridge unisce anche in modo dinamico le ben note cartelle di Windows (System32, Programmi (x86) e così via) con le directory corrispondenti nel pacchetto dell'app. Ogni pacchetto contiene nella radice una cartella denominata "VFS". Le letture delle directory o dei file nella directory VFS vengono unite in fase di esecuzione con le rispettive controparti native. Un'app potrebbe ad esempio contenere C:\Programmi\WindowsApps\nome_pacchetto\VFS\SystemX86\vc10.dll come parte del pacchetto dell'app, ma il file sembrerebbe installato in C:\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 e cartelle nel pacchetto dell'app non sono consentite. Le scritture in file e cartelle che non fanno parte del pacchetto vengono ignorate dal bridge e sono consente, a condizione che l'utente abbia le autorizzazioni.

Operazioni comuni

Questa breve tabella di riferimento mostra le operazioni comuni sul file system e come vengono gestite dal bridge.

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 Copia su scrittura in un percorso per ogni singolo utente e ogni singola app. AppData si trova in genere in C:\Utenti\nome_utente\AppData.
Scrittura all'interno del pacchetto Operazione non consentita. Il pacchetto è di sola lettura. Le scritture in C:\Programmi\WindowsApps\nome_pacchetto non sono consentite.
Scritture all'esterno del pacchetto Ignorate dal bridge. 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'app avrà la percezione che i file si trovino nei percorsi di sistema indicati, mentre in realtà si trovano nei percorsi reindirizzati in C:\Programmi\WindowsApps\nome_pacchetto\VFS. I percorsi FOLDERID derivano da 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 di sistema

Il bridge gestisce il Registro di sistema in modo analogo al file system. I pacchetti delle app contengono un file registry.dat che funge da equivalente logico di HKLM\Software nel Registro di sistema 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).

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 vengono ignorate dal bridge e sono consente, a condizione che l'utente abbia le autorizzazioni.

Per tutte le scritture in HKCU, viene eseguita una copia su scrittura in un percorso privato per ogni singolo utente e ogni singola app. Questo offre gli stessi vantaggi della gestione da parte del bridge del file system per quanto riguarda la pulizia al momento della disinstallazione. 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 conservate durante l'aggiornamento del pacchetto ed eliminate solo quando l'app viene completamente rimossa.

Operazioni comuni

Questa breve tabella di riferimento mostra le operazioni comuni sul Registro di sistema e come vengono gestite dal bridge.

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. Operazione non consentita. 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 Ignorate dal bridge. 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 in C:\Programmi\WindowsApps\nome_pacchetto vengono rimossi, come pure tutte le scritture reindirizzate ad AppData o al Registro di sistema che sono state acquisite dal bridge.

Passaggi successivi

Trovare risposte a domande specifiche

Il nostro team monitora questi tag di StackOverflow.

Inviare commenti e suggerimenti su questo articolo

Utilizza la sezione dei commenti seguenti.