Einführung in den Shellnamespace
Der Shell-Namespace organisiert das Dateisystem und andere objekte, die von der Shell verwaltet werden, in einer einzigen strukturstrukturierten Hierarchie. Konzeptionell handelt es sich um eine größere und inklusivere Version des Dateisystems.
Einführung
Eine der Hauptaufgaben der Shell ist die Verwaltung und Bereitstellung des Zugriffs auf die vielzahl von Objekten, aus denen das System besteht. Die zahlreichsten und vertrautsten dieser Objekte sind die Ordner und Dateien, die sich auf Computerlaufwerken befinden. Die Shell verwaltet jedoch auch eine Reihe von Nichtdateisystem- oder virtuellen Objekten. Beispiele hierfür sind:
- Netzwerkdrucker
- Andere vernetzte Computer
- Systemsteuerung Anwendungen
- Papierkorb
Einige virtuelle Objekte beinhalten überhaupt keinen physischen Speicher. Das Druckerobjekt für instance enthält eine Auflistung von Links zu Netzwerkdruckern. Andere virtuelle Objekte, z. B. der Papierkorb, enthalten möglicherweise Daten, die auf einem Datenträgerlaufwerk gespeichert sind, müssen aber anders als normale Dateien behandelt werden. Beispielsweise kann ein virtuelles Objekt verwendet werden, um daten darzustellen, die in einer Datenbank gespeichert sind. In Bezug auf den Namespace können die verschiedenen Elemente in der Datenbank im Windows-Explorer als separate Objekte angezeigt werden, obwohl sie alle in einer einzelnen Datenträgerdatei gespeichert sind.
Virtuelle Objekte befinden sich möglicherweise sogar auf Remotecomputern. Für instance können die Dokumentdateien eines Benutzers auf einem Server gespeichert werden, um das Roaming zu erleichtern. Um Benutzern zugriff auf ihre Dateien von mehreren Desktop-PCs aus zu gewähren, verweist der Ordner "Eigene Dateien" auf dem desktop-PC, den sie derzeit verwenden, auf den Server, nicht auf die Festplatte des Desktop-PCs. Sein Pfad enthält entweder ein zugeordnetes Netzwerklaufwerk oder einen UNC-Pfadnamen.
Wie das Dateisystem enthält der Namespace zwei grundlegende Objekttypen: Ordner und Dateien. Ordnerobjekte sind die Knoten der Struktur. sie sind Container für Dateiobjekte und andere Ordner. Dateiobjekte sind die Blätter der Struktur; Dabei handelt es sich entweder um normale Datenträgerdateien oder um virtuelle Objekte, z. B. Druckerlinks. Ordner, die nicht Teil des Dateisystems sind, werden manchmal als virtuelle Ordner bezeichnet.
Wie Dateisystemordner variiert die Sammlung virtueller Ordner in der Regel von System zu System. Es gibt drei Klassen virtueller Ordner:
- Virtuelle Standardordner, z. B. der Papierkorb, die sich auf allen Systemen befinden.
- Optionale virtuelle Ordner, die Standardnamen und -funktionen aufweisen, aber möglicherweise nicht auf allen Systemen vorhanden sind.
- Nicht standardmäßige Ordner, die vom Benutzer installiert werden.
Im Gegensatz zu Dateisystemordnern können Benutzer keine neuen virtuellen Ordner selbst erstellen. Sie können nur solche installieren, die von Nicht-Microsoft-Entwicklern erstellt wurden. Die Anzahl der virtuellen Ordner ist daher normalerweise viel kleiner als die Anzahl der Dateisystemordner. Eine Erläuterung zum Implementieren virtueller Ordner finden Sie unter Namespaceerweiterungen.
Eine visuelle Darstellung der Struktur des Namespace wird in der Explorer leiste des Windows-Explorer angezeigt. Der folgende Screenshot von Windows Explorer zeigt beispielsweise einen relativ einfachen Namespace.
Der ultimative Stamm der Namespacehierarchie ist der Desktop. Direkt unter dem Stamm befinden sich mehrere virtuelle Ordner wie "Arbeitsplatz" und der Papierkorb.
Die Dateisysteme der verschiedenen Datenträger können als Teilmengen der größeren Namespacehierarchie angesehen werden. Die Wurzeln dieser Dateisysteme sind Unterordner des Ordners "Arbeitsplatz". Mein Computer enthält auch die Wurzeln aller zugeordneten Netzwerklaufwerke. Andere Knoten in der Struktur, z. B. Eigene Dokumente, sind virtuelle Ordner.
Identifizieren von Namespaceobjekten
Bevor Sie ein Namespaceobjekt verwenden können, müssen Sie es zuerst identifizieren können. Ein Objekt im Dateisystem kann einen Namen wie MyFile.htm haben. Da es möglicherweise andere Dateien mit diesem Namen an anderer Stelle im System gibt, erfordert die eindeutige Identifizierung einer Datei oder eines Ordners einen vollqualifizierten Pfad wie "C:\MyDocs\MyFile.htm". Dieser Pfad ist im Grunde eine geordnete Liste aller Ordner in einem Pfad aus dem Dateisystemstamm C:\, der mit der Datei endet.
Im Kontext des Namespace sind Pfade immer noch sehr nützlich, um Objekte zu identifizieren, die sich im Dateisystemteil des Namespace befinden. Sie können jedoch nicht für virtuelle Objekte verwendet werden. Stattdessen bietet die Shell eine alternative Methode zur Identifizierung, die mit jedem Namespaceobjekt verwendet werden kann.
Element-IDs
Innerhalb eines Ordners verfügt jedes Objekt über eine Element-ID, die das funktionale Äquivalent eines Datei- oder Ordnernamens ist. Die Element-ID ist tatsächlich eine SHITEMID-Struktur :
typedef struct _SHITEMID {
USHORT cb;
BYTE abID[1];
} SHITEMID, * LPSHITEMID;
Das abID-Element ist der Bezeichner des Objekts. Die Länge von abID ist nicht definiert, und ihr Wert wird durch den Ordner bestimmt, der das Objekt enthält. Da es keine Standarddefinition dafür gibt, wie abID-Werte von Ordnern zugewiesen werden, sind sie nur für das zugeordnete Ordnerobjekt von Bedeutung. Anwendungen sollten sie einfach als Token behandeln, das ein Objekt in einem bestimmten Ordner identifiziert. Da die Länge der abID variiert, enthält das cb-Element die Größe der SHITEMID-Struktur in Bytes.
Da Element-IDs für Anzeigezwecke nicht nützlich sind, weist der Ordner, der das Objekt enthält, normalerweise einen Anzeigenamen zu. Dies ist der Name, der von Windows Explorer verwendet wird, wenn der Inhalt eines Ordners angezeigt wird. Weitere Informationen zur Behandlung von Anzeigenamen finden Sie unter Abrufen von Informationen aus einem Ordner.
Listen der Element-ID
Die Element-ID wird selten selbst verwendet. Normalerweise ist es Teil einer Element-ID-Liste, die demselben Zweck wie ein Dateisystempfad dient. Anstelle der für Pfade verwendeten Zeichenfolge ist eine Element-ID-Liste jedoch eine ITEMIDLIST-Struktur . Bei dieser Struktur handelt es sich um eine geordnete Sequenz aus mindestens einer Element-IDs, die durch einen NULL-Wert mit zwei Byte beendet wird. Jede Element-ID in der Element-ID-Liste entspricht einem Namespaceobjekt. Ihre Reihenfolge definiert einen Pfad im Namespace, ähnlich wie ein Dateisystempfad.
Die folgende Abbildung zeigt eine schematische Darstellung der ITEMIDLIST-Struktur , die C:\MyDocs\MyFile.htm entspricht. Der Anzeigename jeder Element-ID wird darüber angezeigt. Die unterschiedlichen Breiten der abID-Member sind beliebig; sie veranschaulichen, dass die Größe dieses Elements variieren kann.
PIDLs
Für die Shell-API werden Namespaceobjekte normalerweise durch einen Zeiger auf ihre ITEMIDLIST-Struktur oder durch einen Zeiger auf eine Elementbezeichnerliste (Item Identifier List, PIDL) identifiziert. Der Einfachheit halber bezieht sich der Begriff PIDL in dieser Dokumentation im Allgemeinen auf die Struktur selbst und nicht auf den Zeiger darauf.
Die in der vorherigen Abbildung gezeigte PIDL wird als vollständige oder absolute PIDL bezeichnet. Eine vollständige PIDL beginnt auf dem Desktop und enthält die Element-IDs aller Zwischenordner im Pfad. Es endet mit der Element-ID des Objekts, gefolgt von einem Beenden von zwei Byte NULL. Eine vollständige PIDL ähnelt einem vollqualifizierten Pfad und identifiziert das Objekt im Shell-Namespace eindeutig.
Vollständige PIDLs werden selten verwendet. Viele Funktionen und Methoden erwarten eine relative PIDL. Der Stamm einer relativen PIDL ist ein Ordner, nicht der Desktop. Wie bei relativen Pfaden definiert die Reihe von Element-IDs, aus denen die Struktur besteht, einen Pfad im Namespace zwischen zwei Objekten. Obwohl sie das Objekt nicht eindeutig identifizieren, sind sie in der Regel kleiner als eine vollständige PIDL und für viele Zwecke ausreichend.
Die am häufigsten verwendeten relativen PIDLs( Single-Level-PIDLs) sind relativ zum übergeordneten Ordner des Objekts. Sie enthalten nur die Element-ID des Objekts und einen beendenden NULL-Wert. Mehrstufige PIDLs werden auch für viele Zwecke verwendet. Sie enthalten mindestens zwei Element-IDs und definieren in der Regel einen Pfad von einem übergeordneten Ordner zu einem Objekt über eine Reihe von mindestens einem Unterordner. Beachten Sie, dass eine PIDL mit einstufiger Ebene immer noch eine vollqualifizierte PIDL sein kann. Insbesondere sind Desktopobjekte untergeordnete Elemente des Desktops, sodass ihre vollqualifizierten PIDLs nur eine Element-ID enthalten.
Wie unter Abrufen einer Ordner-ID erläutert, bietet die Shell-API eine Reihe von Möglichkeiten zum Abrufen der PIDL eines Objekts. Sobald Sie es haben, verwenden Sie es in der Regel nur, um das Objekt zu identifizieren, wenn Sie andere Shell-API-Funktionen und -Methoden aufrufen. In diesem Zusammenhang sind die internen Inhalte einer PIDL undurchsichtig und irrelevant. Stellen Sie sich für diese Diskussion PIDLs als Token vor, die bestimmte Namespaceobjekte darstellen, und konzentrieren Sie sich darauf, wie sie für allgemeine Aufgaben verwendet werden.
Zuweisen von PIDLs
Obwohl PIDLs eine gewisse Ähnlichkeit mit Pfaden aufweisen, erfordert ihre Verwendung einen etwas anderen Ansatz. Der Hauptunterschied besteht in der Zuweisung und Zuordnung von Arbeitsspeicher für sie.
Wie die für einen Pfad verwendete Zeichenfolge muss Arbeitsspeicher für eine PIDL zugeordnet werden. Wenn eine Anwendung eine PIDL erstellt, muss sie ausreichend Arbeitsspeicher für die ITEMIDLIST-Struktur zuweisen. In den meisten der hier beschriebenen Fälle erstellt die Shell die PIDL und verarbeitet die Speicherbelegung. Unabhängig davon, was der PIDL zugeordnet wurde, ist die Anwendung in der Regel für die Aufhebung der Zuordnung der PIDL verantwortlich, wenn sie nicht mehr benötigt wird.
Verwenden Sie die CoTaskMemAlloc-Funktion , um die PIDL zuzuordnen, und die CoTaskMemFree-Funktion , um die Zuordnung aufzulösen.