Partilhar via

Introdução ao namespace do Shell

O namespace Shell organiza o sistema de arquivos e outros objetos gerenciados pelo Shell em uma única hierarquia estruturada em árvore. Conceitualmente, é uma versão maior e mais inclusiva do sistema de arquivos.

Introdução

Uma das principais responsabilidades do Shell é gerenciar e fornecer acesso à grande variedade de objetos que compõem o sistema. O mais numeroso e familiar desses objetos são as pastas e arquivos que residem em unidades de disco do computador. No entanto, o Shell gerencia uma série de sistemas que não são de arquivos ou objetos de virtual também. Eis alguns exemplos:

  • Impressoras de rede
  • Outros computadores ligados em rede
  • Aplicações do Painel de Controlo
  • A Lixeira

Alguns objetos virtuais não envolvem armazenamento físico. O objeto de impressora, por exemplo, contém uma coleção de links para impressoras em rede. Outros objetos virtuais, como a Lixeira, podem conter dados armazenados em uma unidade de disco, mas precisam ser manipulados de forma diferente dos arquivos normais. Por exemplo, um objeto virtual pode ser usado para representar dados armazenados em um banco de dados. Em termos de namespace, os vários itens no banco de dados podem aparecer no Windows Explorer como objetos separados, mesmo que todos estejam armazenados em um único arquivo de disco.

Os objetos virtuais podem até estar localizados em computadores remotos. Por exemplo, para facilitar o roaming, os ficheiros de documentos de um utilizador podem ser armazenados num servidor. Para permitir que os utilizadores acedam aos seus ficheiros a partir de vários computadores de secretária, a pasta Os Meus Documentos no computador de secretária que estão a utilizar apontará para o servidor em vez de para o disco rígido. Seu caminho incluirá uma unidade de rede mapeada ou um nome de caminho UNC.

Como o sistema de arquivos, o namespace inclui dois tipos básicos de objeto: pastas e arquivos. Os objetos de pasta são os nós da árvore; eles são contêineres para objetos de arquivo e outras pastas. Os objetos de arquivo são as folhas da árvore; eles são arquivos de disco normais ou objetos virtuais, como links de impressora. As pastas que não fazem parte do sistema de arquivos às vezes são chamadas de pastas virtuais.

Como as pastas do sistema de arquivos, a coleção de pastas virtuais geralmente varia de sistema para sistema. Existem três classes de pastas virtuais:

  • Pastas virtuais padrão, como a Lixeira, que são encontradas em todos os sistemas.
  • Pastas virtuais opcionais que têm nomes e funcionalidades padrão, mas podem não estar presentes em todos os sistemas.
  • Pastas não padrão que são instaladas pelo usuário.

Ao contrário das pastas do sistema de arquivos, os usuários não podem criar novas pastas virtuais por conta própria. Eles só podem instalar aqueles criados por desenvolvedores que não são da Microsoft. O número de pastas virtuais é, portanto, normalmente muito menor do que o número de pastas do sistema de arquivos. Para saber mais sobre como implementar pastas virtuais, consulte Extensões de namespace.

Você pode ver uma representação visual de como o namespace é estruturado na Barra do Explorer do Windows Explorer. Por exemplo, a captura de tela a seguir do Windows Explorer mostra um namespace relativamente simples.

uma exibição do namespace do shell

A raiz final da hierarquia de namespace é a área de trabalho. Imediatamente abaixo da raiz estão várias pastas virtuais, como Meu Computador e a Lixeira.

Os sistemas de arquivos das várias unidades de disco podem ser vistos como subconjuntos da hierarquia de namespace maior. As raízes desses sistemas de arquivos são subpastas da pasta Meu computador. O Meu Computador também inclui as pastas raiz de quaisquer unidades de rede mapeadas. Outros nós na árvore, como Meus Documentos, são pastas virtuais.

Identificando objetos de namespace

Antes de usar um objeto de namespace, você deve primeiro ter uma maneira de identificá-lo. Um objeto no sistema de arquivos pode ter um nome como MyFile.htm. Como pode haver outros arquivos com esse nome em outro lugar do sistema, a identificação exclusiva de um arquivo ou pasta requer um caminho totalmente qualificado, como "C:\MyDocs\MyFile.htm". Este caminho é basicamente uma lista ordenada de todas as pastas em um caminho da raiz do sistema de arquivos, C:\, terminando com o arquivo.

No contexto do namespace, os caminhos ainda são bastante úteis para identificar objetos localizados na parte do sistema de arquivos do namespace. No entanto, eles não podem ser usados para objetos virtuais. Em vez disso, o Shell fornece um meio alternativo de identificação que pode ser usado com qualquer objeto de namespace.

IDs de Itens

Dentro de uma pasta, cada objeto tem um ID de item , que é o equivalente funcional de um nome de arquivo ou pasta. O identificador do item é, na verdade, uma estrutura SHITEMID:

typedef struct _SHITEMID { 
    USHORT cb; 
    BYTE   abID[1]; 
} SHITEMID, * LPSHITEMID;

O membro abID é o identificador do objeto. O comprimento de abID não está definido e seu valor é determinado pela pasta que contém o objeto. Como não há uma definição padrão para como valores de abID são atribuídos por pastas, eles são significativos apenas para o objeto de pasta associado. Os aplicativos devem simplesmente tratá-los como um token que identifica um objeto em uma pasta específica. Como o comprimento de abID varia, o membro cb mantém o tamanho da estrutura SHITEMID, em bytes.

Como as IDs de item não são úteis para fins de exibição, a pasta que contém o objeto normalmente atribui a ele um nome para exibição. Este é o nome que é usado pelo Windows Explorer quando ele exibe o conteúdo de uma pasta. Para obter mais informações sobre como os nomes de exibição são tratados, consulte Obtendo informações de uma pasta.

Listas de IDs de Itens

O ID do item raramente é usado por si só. Normalmente, ele faz parte de uma lista de ID de item, que serve a mesma finalidade de um caminho do sistema de arquivos. No entanto, em vez da cadeia de caracteres usada para caminhos, uma lista de ID de item é uma estruturaITEMIDLIST. Essa estrutura é uma sequência ordenada de um ou mais IDs de item, terminada por dois bytes NULL. Cada ID de item na lista de ID de item corresponde a um objeto de namespace. Sua ordem define um caminho no namespace, muito parecido com um caminho do sistema de arquivos.

A ilustração a seguir mostra uma representação esquemática da estruturaITEMIDLIST que corresponde a C:\MyDocs\MyFile.htm. O nome de exibição de cada ID de item é mostrado acima do mesmo. As diferentes larguras dos membros do abID são arbitrárias; Eles ilustram o fato de que o tamanho deste membro pode variar.

uma ilustração esquemática de um pidl

PIDLs

Para a API do Shell, os objetos de namespace geralmente são identificados por um ponteiro para sua estrutura ITEMIDLIST ou ponteiro para uma lista de identificadores de item (PIDL). Por conveniência, o termo PIDL geralmente se refere nesta documentação à estrutura em si, em vez do ponteiro para ela.

O PIDL mostrado na ilustração anterior é referido como um PIDL completo, ou um PIDL absoluto. Um PIDL completo começa na área de trabalho e contém as IDs de item de todas as pastas intermediárias no caminho. Termina com o ID do item do objeto seguido por um NULL de dois bytes , terminando com. Um PIDL completo é semelhante a um caminho totalmente qualificado e identifica exclusivamente o objeto no namespace Shell.

PIDLs completos são usados com pouca frequência. Muitas funções e métodos esperam uma PIDL relativa a . A raiz de um PIDL relativo é uma pasta, não a área de trabalho. Assim como os caminhos relativos, a série de IDs de item que compõem a estrutura define um caminho no namespace entre dois objetos. Embora eles não identifiquem exclusivamente o objeto, eles geralmente são menores do que um PIDL completo e suficientes para muitos fins.

Os PIDLs relativos mais comumente usados, PIDLs de um único nível, são relativos à pasta principal do objeto. Eles contêm apenas o ID do item do objeto e um NULL de terminação . PIDLs de vários níveis também são usados para muitos fins. Eles contêm dois ou mais IDs de item e normalmente definem um caminho de uma pasta principal para um objeto através de uma série de subpastas. Observe que um PIDL de nível único ainda pode ser um PIDL totalmente qualificado. Em particular, os objetos da área de trabalho são filhos da área de trabalho, portanto, seus PIDLs completamente qualificados contêm apenas um ID de item.

Conforme discutido em Obtendo o ID de uma pasta, a API do Shell fornece várias maneiras de recuperar o PIDL de um objeto. Depois de tê-lo, normalmente você o usa apenas para identificar o objeto quando chama outras funções e métodos da API do Shell. Neste contexto, os conteúdos internos de um PIDL são opacos e irrelevantes. Para os propósitos desta discussão, pense em PIDLs como tokens que representam objetos de namespace específicos e concentre-se em como usá-los para tarefas comuns.

Atribuição de PIDLs

Embora os PIDLs tenham alguma semelhança com os caminhos, usá-los requer uma abordagem um pouco diferente. A principal diferença reside na forma de alocar e desalocar memória para eles.

Tal como acontece com uma cadeia utilizada para um caminho, a memória deve ser alocada para um PIDL. Se uma aplicação criar um PIDL, deve alocar memória suficiente para a estrutura ITEMIDLIST. Para a maioria dos casos discutidos aqui, o Shell cria o PIDL e lida com a alocação de memória. Independentemente do que alocou o PIDL, o aplicativo geralmente é responsável por deslocalizar o PIDL quando ele não é mais necessário.

Use a função CoTaskMemAlloc para alocar o PIDL e a função CoTaskMemFree para desalocá-lo.

 

 

  • Last updated on