Noções básicas sobre como os aplicativos da área de trabalho empacotados são executados no Windows
Este tópico descreve os tipos de aplicativos de área de trabalho para os quais você pode criar um pacote de aplicativo do Windows, juntamente com alguns comportamentos do sistema operacional (SO) e outras especificidades que é importante conhecer. Entraremos em detalhes sobre os itens a seguir (como veremos, o comportamento específico depende do tipo de aplicativo):
- O local de instalação e o diretório de trabalho do seu aplicativo (que pode ser diferente do que seu aplicativo assumiu no passado).
- O comportamento do sistema de arquivos e do registro do SO.
- Desinstalação.
Tipos de aplicativos de área de trabalho
Há dois tipos de aplicativos de área de trabalho que você pode criar e empacotar. Você declara o tipo do seu aplicativo no manifesto do pacote do aplicativo usando o atributo uap10:RuntimeBehavior do elemento Application:
- Um tipo inclui aplicativos WinUI 3 (que usam o SDK do Aplicativo Windows) e aplicativos de Ponte de Desktop (Centennial). Declarado com
uap10:RuntimeBehavior="packagedClassicApp". - O outro tipo representa outros tipos de aplicativos Win32, incluindo aplicativos empacotados com localização externa. Declarado com
uap10:RuntimeBehavior="win32App".
Os aplicativos da Plataforma Universal do Windows (UWP) (uap10:RuntimeBehavior="windowsApp") também são empacotados, mas este tópico não faz referência a eles.
E, em seguida, o atributo uap10:TrustLevel (do mesmo elemento Application) determina se o processo do seu aplicativo empacotado é ou não executado dentro de um contêiner de aplicativos.
- Um aplicativo totalmente confiável. Declarado com
uap10:TrustLevel="mediumIL". - Um aplicativo appContainer. Declarado com
uap10:TrustLevel="appContainer". É executado em um contêiner de aplicativo leve (e, portanto, é isolado usando a virtualização do sistema de arquivos e do registro). Para obter mais informações, consulte Aplicativos MSIX appContainer.
Importante
Para obter mais detalhes e conhecer dependências e requisitos de recursos, consulte a documentação desses dois atributos em Application. Consulte também uap10 foi introduzido no Windows 10, versão 2004 (10.0; Build 19041).
A finalidade do empacotamento e dos contêineres de aplicativos
O objetivo de empacotar um aplicativo é conceder a ele identidade de pacote em runtime. A identidade de pacote é necessária para determinados recursos do Windows (consulte Recursos que exigem identidade de pacote). Você pode empacotar todas as combinações de tipos de aplicativos descritos acima (e, assim, beneficiar-se da identidade de pacote).
Porém, um dos principais objetivos de um aplicativo appContainer é separar o máximo possível o estado do aplicativo do estado do sistema, mantendo a compatibilidade com outros aplicativos. O Windows faz isso detectando e redirecionando determinadas alterações feitas no sistema de arquivos e no registro em runtime (conhecido como virtualização). Avisaremos quando uma seção se aplicar somente a aplicativos virtualizados.
Instalação
Os pacotes do aplicativo são instalados por usuário, não no sistema inteiro. O local padrão para novos pacotes em um novo computador é C:\Program Files\WindowsApps\<package_full_name>, com o executável denominado app_name.exe. Porém, os pacotes podem ser instalados em outros lugares. Por exemplo, os comandos Start do Visual Studio usam o $(OutDir) do projeto.
Depois da implantação, os arquivos do pacote serão marcados como somente leitura e totalmente bloqueados pelo sistema operacional (SO). O Windows evitará a inicialização dos aplicativos se esses arquivos forem adulterados.
O local C:\Program Files\WindowsApps é conhecido como PackageVolume. Esse local é o PackageVolume padrão que acompanha o Windows, mas você pode criar um PackageVolume em qualquer unidade e em qualquer caminho. Além disso, nem todos os pacotes são instalados em um PackageVolume (veja o exemplo do Visual Studio acima).
Sistema de arquivos
O sistema operacional é compatível com diferentes níveis de operação de sistemas de arquivos para aplicativos de área de trabalho empacotados, dependendo do local da pasta.
Otimizado para seu dispositivo
Para evitar a duplicação de arquivos (a fim de otimizar o espaço de armazenamento em disco e reduzir a largura de banda necessária ao baixar arquivos), o sistema operacional aproveita o armazenamento único e a vinculação rígida de arquivos. Quando um usuário baixa um pacote MSIX, o AppxManifest.xml é usado para determinar se os dados contidos nesse pacote já existem no disco de uma instalação anterior do pacote. Se o mesmo arquivo existir em vários pacotes MSIX, o sistema operacional armazenará o arquivo compartilhado no disco apenas uma vez e criará links rígidos de ambos os pacotes para o arquivo compartilhado. Como os arquivos são baixados em blocos de 64 Kb, mesmo que um percentual dos arquivos baixados já esteja no disco, somente a diferença será baixada. Isso reduz a largura de banda usada para download.
Operações de AppData no Windows 10, versão 1903 e posterior
Esta seção se aplica somente a aplicativos virtualizados.
Todos os arquivos e pastas recém-criados na pasta AppData do usuário (por exemplo, C:\Users\<user_name>\AppData) são gravados em um local privado por usuário e por aplicativo, mas mesclados em runtime para aparecer no local AppData real. Isso permite um certo grau de separação de estado para artefatos que são usados apenas pelo próprio aplicativo, o que permite que o sistema limpe esses arquivos quando o aplicativo é desinstalado.
Modificações nos arquivos existentes na pasta AppData do usuário são permitidas para proporcionar um grau mais alto de compatibilidade e interatividade entre os aplicativos e o sistema operacional. Isso reduz o "apodrecimento" do sistema, porque o sistema operacional está ciente de cada alteração de arquivo ou diretório feita por um aplicativo. A separação de estados também permite que os aplicativos de área de trabalho empacotados continuem de onde uma versão não empacotada do mesmo aplicativo parou. Observe que o sistema operacional não é compatível com uma pasta de sistema de arquivos virtual (VFS) para a pasta AppData do usuário.
Operações do AppData em sistemas operacionais anteriores ao Windows 10, versão 1903
Esta seção se aplica somente a aplicativos virtualizados.
Todas as gravações na pasta AppData do usuário (por exemplo, C:\Users\<user_name>\AppData), incluindo criação, exclusão e atualização, são copiadas na gravação para um local privado por usuário e por aplicativo. Isso cria a ilusão de que o aplicativo empacotado está editando o AppData real quando, na verdade, está modificando uma cópia privada. Redirecionando gravações dessa maneira, o sistema pode acompanhar todas as modificações de arquivo feitas pelo aplicativo. Isso permite que o sistema limpe esses arquivos quando o aplicativo é desinstalado, o que reduz o "apodrecimento" do sistema e oferece uma experiência melhor de remoção de aplicativo para o usuário.
Diretório de trabalho e arquivos de aplicativo
Esta seção se aplica somente a aplicativos virtualizados.
Além de redirecionar AppData, as pastas conhecidas do Windows (System32, Program Files (x86), etc.) são mescladas dinamicamente com os diretórios correspondentes no pacote do aplicativo. Cada pacote contém uma pasta chamada VFS na raiz. Todas as leituras de diretórios ou arquivos no diretório VFS são mescladas em runtime com suas respectivas contrapartes nativas. Por exemplo, um aplicativo poderia conter C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll como parte de seu pacote de aplicativos, mas o arquivo pareceria estar instalado em C:\Windows\System32\vc10.dll. Isso mantém a compatibilidade com aplicativos da área de trabalho que podem esperar que arquivos estejam em locais que não sejam do pacote.
As gravações em arquivos/pastas no pacote do aplicativo não são permitidas. As gravações nos arquivos e nas pastas que não fazem parte do pacote são ignoradas pelo sistema operacional e são permitiras desde que o usuário tenha permissão.
Operações comuns do sistema de arquivos
Essa curta tabela de referência mostra operações comuns de sistema de arquivos e como o sistema operacional lida com elas.
| Operação | Result | Exemplo |
|---|---|---|
| Ler ou enumerar um arquivo ou pasta bem conhecido do Windows | Uma mesclagem dinâmica do C:\Program Files\<package_full_name>\VFS\<well_known_folder> com a contraparte do sistema local. |
A leitura de C:\Windows\System32 retorna o conteúdo de C:\Windows\System32 mais o conteúdo de C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86. |
Escreva em AppData |
Windows 10, versão 1903 e posterior: novos arquivos e pastas criados nos seguintes diretórios são redirecionados para um local privado por usuário e por pacote:
AppData real. Se o arquivo for aberto pelo local AppData real, não haverá virtualização do arquivo. As exclusões de arquivos em AppData serão permitidas se o usuário tiver permissões.Anterior ao Windows 10, versão 1903: faça uma cópia em gravação para um local por usuário e por aplicativo. |
AppData normalmente é C:\Users\<user_name>\AppData. |
| Escrever dentro do pacote | Não permitido. O pacote é somente leitura. | Não são permitidas gravações em C:\Program Files\WindowsApps\<package_full_name>. |
| Escrever fora do pacote | Permitido se o usuário tiver permissões. | Uma gravação em C:\Windows\System32\foo.dll será permitida se o pacote não contiver C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dll e o usuário tiver permissões. |
Locais de VFS empacotados
Esta seção se aplica somente a aplicativos virtualizados.
Esta tabela mostra onde os arquivos enviados como parte do seu pacote estão sobrepostos no sistema do aplicativo. Seu aplicativo perceberá que esses arquivos estão nos locais listados do sistema quando, na verdade, estão nos locais redirecionados dentro de C:\Program Files\WindowsApps\<package_full_name>\VFS. Os locais de FOLDERID são provenientes de constantes KNOWNFOLDERID.
| Local do sistema | Local redirecionado (em [<package_root>]\VFS) | Válido em arquiteturas |
|---|---|---|
| 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 | Comum 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 seção (e suas subseções) aplica-se somente a aplicativos virtualizados.
Pacotes de aplicativos contêm um arquivo registry.dat, que funciona como o equivalente lógico (virtual) de HKLM\Software no registro real. Em runtime, o registro virtual mescla o conteúdo desse hive com o hive do sistema nativo para fornecer uma visão única de ambos. Por exemplo, se registry.dat contiver uma única chave Foo, uma leitura de HKLM\Software em runtime também parecerá conter Foo (além de todas as chaves nativas do sistema).
Embora os pacotes MSIX incluam chaves HKLM e HKCU, eles são tratados de formas diferentes. Somente as chaves em HKLM\Software fazem parte do pacote; as chaves em HKCU ou em outras partes do registro não fazem. Não são permitidas gravações em chaves ou valores no pacote. As gravações em chaves ou valores que não fazem parte do pacote são permitidas desde que o usuário tenha permissão.
Todas as gravações em HKCU são copiadas na gravação para um local privado por usuário e por aplicativo. Tradicionalmente, os desinstaladores não conseguem limpar HKEY_CURRENT_USER, pois os dados do registro para usuários desconectados são desmontados e não estão disponíveis.
Todas as gravações são mantidas durante a atualização do pacote e são excluídas somente quando o aplicativo é totalmente removido.
Operações de registro comuns
A maior parte desta seção se aplica apenas a aplicativos virtualizados.
Essa curta tabela de referência mostra operações de Registro comuns e como o sistema operacional lida com elas.
| Operação | Result | Exemplo |
|---|---|---|
| Ler ou enumerar HKLM\Software | Uma mesclagem dinâmica do pacote hive com a contraparte do sistema local. | Se registry.dat contiver uma única chave Foo, em runtime, uma leitura de HKLM\Software mostrará o conteúdo de HKLM\Software e HKLM\Software\Foo. |
| Grava em HKCU | Copiado na gravação em um local privado por usuário e por aplicativo. | O mesmo que AppData para arquivos. |
| Grava dentro do pacote. | Não permitido. O pacote é somente leitura. | Gravações em HKLM\Software não serão permitidas se houver uma chave/valor correspondente na colmeia de pacotes. |
| Grava fora do pacote | Ignorado pelo sistema operacional. Permitido se o usuário tiver permissões. | Gravações em HKLM\Software são permitidas, desde que não exista uma chave/valor correspondente no hive de pacotes e que o usuário tenha as permissões de acesso corretas. |
Desinstalação
Esta seção se aplica somente a aplicativos virtualizados.
Quando um pacote é desinstalado pelo usuário, todos os arquivos e pastas localizados em C:\Program Files\WindowsApps\<package_full_name> são removidos, bem como todas as gravações redirecionadas para AppData ou para o registro que foram capturadas durante o processo de empacotamento.