Noções básicas sobre como os aplicativos da área de trabalho empacotados são executados no Windows

  • Artigo

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):

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:
  • Local
  • Local\Microsoft
  • Roaming
  • Roaming\Microsoft
  • Roaming\Microsoft\Windows\Start Menu\Programs
Em resposta ao comando para abrir o arquivo, o sistema operacional abrirá o arquivo primeiro do local por usuário e por pacote. Se esse local não existir, o sistema operacional tentará abrir o arquivo no local 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.