Implementieren der gemeinsamen Nutzung von parallelen Komponenten in Anwendungen (Erweitert)
Dieser Artikel gibt einen Überblick über die Implementierung von gemeinsam genutzten parallelen Komponenten in Microsoft® Windows® 2000 und Windows 98 Zweite Ausgabe, wie in den Windows-Zertifizierungsspezifikationen beschrieben. Auß;erdem wird die Erstellung von neuen parallelen Komponenten und die Verwendung der DLL/COM-Umleitung zur Behebung der Inkompatibilität zwischen verschiedenen Versionen derselben Komponente erläutert, und es werden Richtlinien für das Schreiben und Installieren von parallelen Komponenten und das Packen und Testen von Anwendungen erstellt.
Auf dieser Seite
Einführung
Moderne Betriebssysteme und Anwendungen werden aus vielen Komponenten erstellt. Eine Komponente ist eine unabhängige Softwareeinheit mit einer Reihe von Funktionen, die von einer Vielzahl von Anwendungen genutzt werden können. Da einzelne Komponenten von mehr als einer Anwendung genutzt werden, ist die gemeinsame Nutzung von Komponenten von grundlegender Bedeutung.
Die gemeinsame Nutzung von globalen Komponenten erfordert, dass jede gemeinsam genutzte Komponente genauso funktioniert wie frühere Versionen dieser Komponente. In der Praxis ist eine 100%ige Abwärtskompatibilität jedoch schwierig oder sogar unmöglich, da nicht alle Konfigurationen getestet werden können, in denen die gemeinsam genutzte Komponente verwendet werden kann. Sowohl neuere als auch ältere Anwendungen benutzen dieselbe Komponente, und die Fehlerbehebung und Optimierung der Komponente wird im Laufe der Zeit immer schwieriger.
Auch die praktische Funktionalität einer Komponente ist schwer zu definieren. Anwendungen können von unbeabsichtigten Nebeneffekten abhängig werden, die nicht zu den Grundfunktionen der Komponente gehören. So kann eine Anwendung z. B. von einem Programmierfehler in der Komponente abhängig werden, und wenn der Komponentenentwickler diesen Fehler behebt, tritt ein schwerer Fehler in der Anwendung auf (dies wird auch als "DLL-Wirrwarr" bezeichnet). Die immense Zahl von Anwendungen, die jede Komponente verwenden, verstärkt das Problem.
Diese mangelnde Abwärtskompatibilität kann dazu führen, dass bei der Weitergabe einer neuen Anwendung bereits weitergegebene Anwendungen beschädigt oder die Funktionalität der neuen Anwendung beeinträchtigt wird. Eine neue Anwendung erfordert eine andere Version einer gemeinsam genutzten Komponente als die bereits weitergegebene Version. Microsoft hat in Windows 2000 und Windows 98 Zweite Ausgabe die gemeinsame Nutzung von parallelen Komponenten eingeführt. Durch die hierin eingebaute selektive Isolierung ist eine erfolgreiche gemeinsame Nutzung bei gleichzeitiger Optimierung der Anwendungsstabilität gewährleistet.
Hintergrundinformationen
Bevor wir uns mit den Einzelheiten der gemeinsamen Nutzung von parallelen Komponenten befassen, werfen wir einen Blick auf einige Hintergrundaspekte und Probleme des "DLL-Wirrwarrs".
Gemeinsames Nutzen von Komponenten
In Windows war von Anfang an das Konzept der gemeinsamen Nutzung implementiert. Alle Betriebssysteme müssen die Notwendigkeit eines stabilen, umfangreichen Dienstangebots gegen die Ressourcenbeschränkungen der Hardware abwägen, für die das Betriebssystem entworfen wurde. Bis vor kurzem waren die Ressourcen für die CPU-Verwendung und den Festplattenspeicher auf der PC-Plattform sehr begrenzt. Daher bot es sich an, den Betriebssystem- und Anwendungscode durch eine weitreichende gemeinsame Codenutzung zu komprimieren. Neben vielen weiteren Vorteilen optimiert die gemeinsame Nutzung von Codeanweisungen den wiederholten Einsatz der Hardwareressourcen und minimiert den Testaufwand bei der Qualitätssicherung. Die gemeinsame Nutzung von Code trägt entscheidend zum Erfolg von Windows bei.
In Windows wird nicht nur Code gemeinsam genutzt. Der Anwendungs- und Komponentenstatus kann im Betriebssystem in Form des Registrierungsstatus, anwendungsspezifischer Datenspeicherung im Dateisystem und der Windows-APIs ermittelt werden, die globale Namespaces offen legen. Diese gemeinsame Nutzung ermöglicht eine weitreichende Interoperabilität zwischen Anwendungen unterschiedlicher Hersteller und bewirkt so eine Kostensenkung und höhere Softwareeffizienz.
Die gemeinsame Nutzung hat jedoch auch Nachteile: Anwendungen werden voneinander abhängig, und es entstehen Schwachstellen. Änderungen an einer Komponente können unbeabsichtigte Auswirkungen auf andere Komponenten haben. I.d.R. wird eine Anwendung von einer bestimmten Version einer gemeinsam genutzten Komponente abhängig. Wenn eine andere Anwendung mit einer höheren (oder niedrigeren) Version dieser gemeinsam genutzten Komponente installiert wird, ergeben sich negative Auswirkungen auf die erste Anwendung. Im Extremfall weisen Anwendungen, die zuvor ordnungsgemäß; funktionierten, plötzlich unerklärliche Fehler auf. Dieser Zustand wird häufig als "DLL-Wirrwarr" bezeichnet.
Isolierung
Das Gegenteil der gemeinsamen Nutzung von Komponenten in einem System ist die Isolierung. Anwendungen können isoliert werden, indem alle Ressourcen und der gesamte Code statisch an die Anwendung gebunden werden. Eine vollständige Isolierung ist bei heutigen Anwendungen, die auf COM oder anderen global gespeicherten Systemressourcen beruhen, jedoch unmöglich.
Eine Möglichkeit der Behebung von Schwachstellen in Anwendungen besteht darin, bestimmte Anwendungen und Komponenten zu isolieren. In diesem Szenario können alle Anwendungen Zugriff auf dieselbe Komponente haben, doch es sind jetzt mehrere Versionen dieser Komponente verfügbar. Komponentenentwickler können nun neue Versionen alter Komponenten veröffentlichen, Verbesserungen vornehmen und Fehler beheben. Kunden wiederum können die Version wählen, die am besten für eine bestimmte Anwendung geeignet ist. Stellen Sie sich vor, Sie kaufen in einem Geschäft für Autoersatzteile eine Benzinpumpe für Ihren 84er Mercedes und finden neben Ihrer Pumpe auch Pumpen für andere Modelle bzw. neuere Jahrgänge. Bei Komponenten ist das Entscheidende, für jede Anwendung die richtige Version bereitzustellen und die unterschiedlichen Versionen voneinander zu isolieren. Bei einer Umleitung können Anwendungen so konfiguriert werden, dass sie die richtige Komponentenversion für eine bestimmte Anwendung verwenden, unabhängig davon, welche weiteren Versionen derzeit oder künftig weitergegeben werden.
Gemeinsames Nutzen von parallelen Komponenten
Sowohl Microsoft Windows 2000 als auch Windows 98 Zweite Ausgabe enthalten eine neue Form der gemeinsamen Komponentennutzung (nämlich die gemeinsame Nutzung von parallelen Komponenten), bei der selektive Isolierung verwendet wird, um das Auftreten eines "DLL-Wirrwarrs" zu minimieren. Bei einer gemeinsamen Nutzung von parallelen Komponenten können mehrere Versionen derselben Komponente (COM oder Win32®) gleichzeitig in unterschiedlichen Prozessen ausgeführt werden. Anwendungen können dann die spezielle Version einer Komponente verwenden, für die sie entworfen und getestet wurden, selbst wenn eine andere Anwendung eine andere Version derselben Komponente erfordert. Dadurch können Entwickler zuverlässigere Anwendungen erstellen und weitergeben, da sie unabhängig von anderen Anwendungen im System die Version der Komponente angeben können, die sie für ihre Anwendung verwenden.
Neue Strategien für die gemeinsame Nutzung von Komponenten
Bei der gemeinsamen Nutzung von parallelen Komponenten in Windows 2000 und Windows 98 Zweite Ausgabe werden zwei Strategien verfolgt:
| • | Erstellen von parallelen Komponenten. Entwickler erstellen neue Komponenten, die die gleichzeitige Ausführung von mehreren Versionen dieser Komponente unterstützen. Benutzer dieser neuen Komponenten können jetzt die Version verwenden, für die sie erstellt und installiert wurden, unabhängig davon, welche anderen Versionen auf dem Computer installiert sind. |
| • | DLL/COM-Umleitung. Entwickler und Administratoren verpacken vorhandene Anwendungen und Komponenten neu, so dass die erforderlichen Versionen der gemeinsam genutzten Komponenten für die Anwendung privatisiert werden, die sie benötigt. Diese Versionen funktionieren parallel zu anderen Versionen. |
Parallele Komponenten werden nicht in allen Szenarios unterstützt. (Dies gilt sowohl für neu erstellte Komponenten als auch für Komponenten, die Bestandteil einer vorhandenen, neu konfigurierten Anwendung sind.)
| • | Das Hauptszenario für das Erstellen von parallelen Komponenten tritt ein, wenn In-Process-Komponenten bei ihrer Ausführung eine andere Containeranwendung als Host verwenden. Wenn Ihre Steuerelemente beispielsweise von einer Windows-Desktopanwendung verwendet werden sollen (die in Microsoft Visual Basic® oder Visual C++® geschrieben ist), bieten sich diese Steuerelemente für eine paralle Nutzung an. Parallele Komponenten sollten nicht in Servern verwendet werden. |
| • | Das Hauptszenario für eine DLL/COM-Umleitung tritt ein, wenn neue Clientanwendungen auf Computern veröffentlicht werden, die bereits mehrere andere Anwendungen unterstützen, oder wenn die neue Clientanwendung gegen Änderungen in gemeinsam genutzten Komponenten durch die Installation anderer Anwendungen immunisiert werden muss. Die DLL/COM-Umleitung sollte nicht in Servern verwendet werden. Anmerkung Die DLL/COM-Umleitung dient speziell der Lösung von Anwendungskonflikten bei der Weitergabe von vorhandenen Anwendungen und Komponenten. Bei der Entwicklung einer neuen Anwendung oder neuer Komponenten ist die beste Strategie die Entwicklung von isolierten parallelen Komponenten. |
Vergleich der beiden Strategien
In der folgenden Tabelle werden die beiden Ansätze (DLL/COM-Umleitung und das Erstellen von parallelen Komponenten) beschrieben, und Sie erhalten Anhaltspunkte für die Auswahl des richtigen Ansatzes für Ihr Szenario.
Tabelle 1. Parallele Strategien im Vergleich
| Attribute | Parallele Komponenten | DLL/COM-Umleitung |
Wo liegt der Hauptfokus? | Erstellen von stabilen neuen Komponenten, die in künftigen Versionen gegen Änderungen immun sind, welche ihre Abwärtskompatibilität aufheben. | Abschirmen von vorhandenen Anwendungen gegen Probleme, die dadurch verursacht werden, dass andere Anwendungen inkompatible gemeinsam genutzte DLLs installieren. |
Werden bestimmte Komponentenversionen in den Anwendungen isoliert, von denen sie verwendet werden? | Ja. Parallele Komponenten müssen stets so weitergegeben werden, dass sie in den Anwendungen isoliert sind, von denen sie verwendet werden. | Ja. Anwendungen, die eine DLL/COM-Umleitung einsetzen, verwenden die Versionen von gemeinsam genutzten Komponenten, die im Anwendungsverzeichnis installiert sind, unabhängig davon, welche Versionen an anderer Stelle im System installiert sind. |
Sind neue Codeanweisungen oder Änderungen an den vorhandenen Codeanweisungen erforderlich? | Ja. Das Erstellen von parallelen Komponenten (oder Umwandeln von vorhandenen Komponenten in parallele Komponenten) erfordert mindestens eine Änderung des COM-Registrierungscodes, um einen Zugriff über den relativen Pfad zu ermöglichen. Es können weitere Codeänderungen erforderlich sein, um sicherzustellen, dass der globale Status zwischen den ausgeführten Versionen paralleler Komponenten richtig verarbeitet wird. | Nein. Die DLL/COM-Umleitung ermöglicht das Rekonfigurieren von Anwendungen für die Installation und Ausführung paralleler Komponenten ohne Codeänderungen oder eine Rekompilierung. Dadurch können Administratoren, die keinen Zugriff auf den Quellcode einer Anwendung haben, die Anwendung rekonfigurieren, um "DLL-Wirrwarr"-Probleme zu lösen. |
Funktioniert die Strategie in allen Szenarios? | Ja. Parallele Komponenten sind für die entsprechende Installation und Ausführung entworfen und codiert. Daher weisen sorgfältig entworfene, entwickelte und getestete parallele Komponenten (sowie die Anwendungen, von denen sie verwendet werden) keine "DLL-Wirrwarr"-Probleme auf. | Nein. Die DLL/COM-Umleitung erfordert keine Codeänderung. Vorhandene Anwendungen und Komponenten wurden u.U. nicht so entworfen, dass mehr als eine Version gleichzeitig ausgeführt werden kann. Erfahrungswerte haben gezeigt, dass vorhandene Anwendungen und Komponenten in den meisten Fällen parallele Komponenten ausführen können; es muss jedoch getestet werden, ob dies für ein bestimmtes Szenario zutrifft. (Siehe auch "Auswählen von zu isolierenden Komponenten".) |
Als Faustregel gilt:
| • | Wenn "DLL-Wirrwarr"-Probleme die Weitergabe einer vorhandenen Anwendung verhindern, sollten Sie die DLL/COM-Umleitung verwenden, um die konfliktbehafteten Komponenten zu isolieren. (Weitere Informationen zu dieser Option erhalten Sie in den folgenden Szenarios.) |
| • | Wenn Sie eine neue Anwendung erstellen und diese bereits beim Entwurf und der Entwicklung vor "DLL-Wirrwarr"-Problemen schützen möchten, sollten Sie parallele Komponenten entwickeln. |
Erstellen von neuen parallelen Komponenten
Das gemeinsame Nutzen von parallelen Komponenten erfordert, dass Entwickler bei der Erstellung von neuen Anwendungen parallele Anwendungen schreiben. Dabei handelt es sich um gewöhnliche COM- oder Win32-Komponenten, die jedoch nicht im Systemverzeichnis, sondern im Anwendungsverzeichnis (oder einem Unterverzeichnis) installiert werden. Sie werden in eine bestimmte Anwendung isoliert und nicht global in allen Anwendungen gemeinsam genutzt.
Daher kann eine Komponente problemlos parallel installiert werden, auch wenn in einem anderen Anwendungsverzeichnis eine andere Version derselben Komponente installiert ist. Wenn eine andere Anwendung im System eine andere Version erfordert (und installiert), hat dies keine Auswirkungen auf Ihre Anwendung. Beide Anwendungen werden jeweils mit der entsprechenden Version der Komponente ausgeführt.
Wenn die andere Anwendung eine neue Version einer Komponente im System installiert, hat dies keine Auswirkungen auf Ihre Version der Komponente, da Sie diese im Anwendungsverzeichnis installiert haben. Ihre Anwendung verwendet weiterhin die in ihrem Lieferumfang enthaltene Version der Komponente, während die andere Anwendung ihre eigene Version verwendet. Das Betriebssystem kann beide Versionen gleichzeitig laden.
Da eine parallele Komponente eine "private" Komponente der Anwendung darstellt, von der sie installiert wurde, kann das Deinstallationsprogramm der Anwendung die parallele Komponente stets problemlos entfernen, da per Definition keine andere Anwendung von einer privaten Komponente abhängen kann.
Anmerkung Parallele Komponenten müssen ordnungsgemäß; im Betriebssystem registriert sein (wie weiter unten in diesem Artikel beschrieben), damit keine Konflikte zwischen den unterschiedlichen Versionen der Komponente auftreten.
Anmerkung Sowohl Windows 2000 als auch Windows 98 Zweite Ausgabe unterstützen die gemeinsame Nutzung von parallelen Komponenten. Diese Funktion wird von älteren Versionen des Windows-Betriebssystems nicht unterstützt. Auf diesen älteren Systemen kann jedoch eine parallele DLL (d.h. eine DLL, die gemäß; den Richtlinien im nächsten Abschnitt geschrieben wurde) im Systemverzeichnis installiert werden. Die DLL wird global gemeinsam genutzt, d.h. sie ist abwärts kompatibel. Anwendungen müssen die Betriebssystemversion dynamisch überprüfen, um das zu verwendende Verfahren zur gemeinsamen Nutzung zu bestimmen.
Richtlinien für das Schreiben von parallelen Komponenten
Die folgenden Richtlinien gelten für die Erstellung von parallelen Komponenten (COM oder Win32). Wenn Sie parallele Komponenten schreiben und im Anwendungsverzeichnis platzieren, ist Ihr Code für den Anwendungskontext privatisiert. Wenn Sie Ihre Daten basierend auf dem Anwendungsnamen in die Registrierung eintragen, werden die Daten für die Anwendung privatisiert.
Kunden Ihrer parallelen Komponente werden von Änderungen isoliert, die andere Kunden Ihrer Komponente benötigen. Auß;erdem können Sie Ihre Komponenten aktualisieren, ohne dabei vorhandene Anwendungen zu beschädigen. Anwendungen können Ihre Komponente ohne Neustart installieren, selbst wenn eine andere Anwendung eine andere Version Ihrer Komponente verwendet.
Anmerkung Diese Richtlinien sind eine erweiterte Version der aktuellen Windows-Zertifizierungsrichtlinien. Sie werden darauf hingewiesen, Win32-DLLs im Anwendungsverzeichnis zu platzieren.
Allgemeine Aspekte
| • | Versuchen Sie nicht, Dateien zu ersetzen, die mit Systemdateischutz versehen und im Lieferumfang von Windows 2000 enthalten sind. (Dies gilt für die meisten SYS-, DLL-, EXE- und OCX-Dateien.) |
| • | Sie müssen alle Komponenten testen, um v.a. in den Bereichen eine parallele Gültigkeit sicherzustellen, in denen eine gemeinsame Nutzung auftreten kann, da die aktuellen Betriebssysteme keine Parallelität erzwingen. |
| • | Fassen Sie alle versionsspezifischen Namen in #defines zusammen, um die Codemigration von einer Version in eine andere zu erleichtern. Dadurch können Sie die Version zentral ändern, und alle Registrierungsschlüssel werden automatisch angepasst. Beispiel: #define MeinRegistrierungsschlüssel "MeineAnwendungVers1.0.0.0" Wenn Sie eine neue Version Ihrer Komponente veröffentlichen, müssen Sie die Version lediglich an einer Stelle ändern. |
| • | Stellen Sie sicher, dass Sie weiterhin schnelle Korrekturen an Komponenten vornehmen können, auch wenn diese sich nun in willkürlich platzierten Anwendungsverzeichnissen befinden. Als Komponentenentwickler wissen Sie u.U. nicht, an welchen Stellen Sie Korrekturen an Ihrer Komponente vornehmen müssen. Anwendungshersteller müssen Kunden Aktualisierungen zur Verfügung stellen. |
| • | Vermeiden Sie prozessübergreifende gemeinsame Nutzungen. So können z. B. gemeinsam genutzte Arbeitsspeicherabschnitte Probleme auslösen, da ein Abschnitt nicht von verschiedenen Versionen Ihrer Komponente gemeinsam genutzt werden kann. |
| • | Sie müssen alle gemeinsam genutzten Datenstrukturen als parallele Komponenten (die für jede Version der Komponente anders gestaltet sind) entwerfen, einschließ;lich Speicherzuordnungsdateien, Mutexe, Named Pipes und Hardwaretreiber. |
| • | Sie müssen temporäre Daten im Verzeichnis TEMP speichern. |
| • | Speichern Sie Benutzerdaten nicht in globalen Speicherorten. Es sollte eine klare Trennung zwischen Anwendungsdaten und Benutzerdaten vorliegen. |
Verstärken Ihrer Komponenten
| • | Sie müssen eine ordnungsgemäß;e Verweiszählung Ihrer GUIDs in der globalen Registrierung vornehmen, die die Installationen und Deinstallationen Ihrer Komponente durch verschiedene Hersteller umfasst. Die verlässlichste Vorgehensweise besteht dabei in der Erstellung eines Verweiszählers im GUID-Schlüssel.
HKEY_CLASSES_ROOT\CLSID\{GUID}\InprocServer32
Default=foo.dll
ThreadingModel=Apartment
RefCount=1
Anmerkung Sie müssen die Verweiszählung der DLL unabhängig von der GUID vornehmen. |
| • | Verwenden Sie bei COM-Registrierungen keine vollständigen Pfadnamen. Sie können sich bei der Suche nach Ihrer Komponente und deren Abhängigkeiten auf die Verzeichnissuche im Anwendungsverzeichnis verlassen. |
| • | Wenn Sie Metadaten (z. B. das Threadingmodell) unter der COM-GUID ändern, müssen Sie eine Namensänderung vornehmen und eine neue GUID für Ihre Komponente anwenden, da es sich um eine neue Version der Komponente handelt. Dies ist erforderlich, da die Daten in der Registrierung mit der privaten Version Ihrer Komponente für diese Anwendung im Kontext einer anderen Anwendung nicht gültig wären. |
| • | Sie müssen die Typbibliothek in Ihrer DLL platzieren, nicht in einer anderen Datei. |
| • | Verwenden Sie nicht die LoadRegTypeLib-Funktion, um Typbibliotheken über die Registrierung zu laden. Das Registrieren der Typbibliothek in der Registrierung ist ein globaler Status und läuft den Regeln der Privatisierung zuwider. Verwenden Sie stattdessen die LoadType Lib-Funktion. |
| • | Die Erstellung einer neuen Version von externen Typbibliotheken durch OLEAUT ist instabil und fehleranfällig. Sie sollten für parallele Komponenten keine externen Typbibliotheken verwenden. |
| • | Wenn Sie eine vorhandene Komponente in eine parallele Komponente umwandeln, ändern Sie die Aktivierung dieser Komponente für die Verwendung eines relativen Pfads und die Isolierung des globalen Status. Sie müssen der Komponente eine neue CLSID und ProgId verleihen, die Datei umbenennen und dann diese CLSID, ProgId und den neuen Dateinamen für künftige parallele Versionen verwenden. Dadurch vermeiden Sie Konflikte, die andernfalls auftreten würden, wenn eine nicht parallele Version einer Komponente über eine parallele Version registriert wird. Parallele Komponenten sind nicht abwärts kompatibel mit nicht parallelen früheren Versionen. |
Statusspeicherung
| • | Hinsichtlich der in der Registrierung gespeicherten Einstellungen (bzw. des gespeicherten Status) müssen Sie den Status für den ausgeführten Anwendungskontext privatisieren. Sie können die GetModuleFileName()-Funktion verwenden, um ein virtuelles Stammverzeichnis einzurichten. Dies sollte für HKLM- und HKCU-Teilstrukturen erfolgen. | ||||||
| • | Registrierungseinstellungen müssen auf Versionsbasis vorgenommen werden, um eine Registrierungsisolierung zu erzielen. Registrierungsschlüssel sind eine gängige Methode für die Speicherung des Komponentenstatus. Da auf Ihrem Computer u.U. unterschiedliche Versionen Ihrer Komponente installiert sind, sollte die Versionszuordnung Ihrer Schlüssel bei der Rekompilierung so einfach wie möglich sein. Dies wird durch Headerdateien und Hilfsprogramm-APIs ermöglicht. | ||||||
| • | Speichern Sie Ihren Registrierungsstatus unter Verwendung der folgenden Benennungskonvention in Schlüsseln: HKCU\MeineFirma\MeineKomponente\VersionXXXX Nehmen Sie z. B. an, es liegt eine Konfigurationseinstellung namens InteressantesFeatureAktivieren mit dem Wert TRUE oder FALSE vor. I.d.R. würden Sie diese Informationen wie folgt in der Registrierung speichern: HKEY_CurrentUser\Software\MeineFirma\MeineKomponente InteressantesFeatureAktivieren = TRUE Bei einer gemeinsamen Nutzung von parallelen Komponenten müssten Sie die Informationen wie folgt speichern:
HKEY_CurrentUser\Software\MeineFirma\MeineKomponente\Version01.01
InteressantesFeatureAktivieren = TRUE
| ||||||
| • | Wenn Sie sich hingegen für eine Isolierung in einer Anwendung entscheiden, können Sie Folgendes verwenden: HKCU\MeineFirma\MeineKomponente\VersionXXYY\BeliebigeAnwendung\ Dabei ist BeliebigeAnwendung der Rückgabewert von GetModuleFileName. Dadurch kann eine Komponente ihre Einstellungen nur für die Anwendung isolieren, unter der sie derzeit ausgeführt wird. | ||||||
| • | Im Idealfall sollten Sie ein Modell der Dauerhaftigkeit unterstützen, so dass die Anwendung für die Beibehaltung Ihres Status verantwortlich ist und die Registrierung nicht ändert. Eine Anwendung sollte nicht direkt auf die Registrierungseinträge einer Komponente zugreifen müssen. Stattdessen sollte die Komponente APIs bereitstellen, die parallele, kompatible Einstellungen speichern oder wiederherstellen. | ||||||
| • | Für die Interaktion mit einem globalen Status sollten die Einstellungen an anderen Speicherorten als der Registrierung parallel gespeichert werden. Diese Speicherorte umfassen Folgendes:
|
Installieren von parallelen Komponenten
Vor der Installation
Bevor Sie parallele Komponente installieren, müssen Sie feststellen, ob diese von Ihrem Betriebssystem unterstützt werden. Die folgende Codeanweisung ermittelt, ob eine gemeinsame Nutzung von parallelen Komponenten verfügbar ist oder nicht. Falls dies nicht der Fall ist, müssen die Komponenten im Systemverzeichnis installiert werden.
BOOL bPlatformSupportsSideBySide(void)
{
OSVERSIONINFOEX osviex ;
osviex.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
// Wenn die Plattform die OSVERSIONINFOEX-Struktur nicht unterstützt,
// kann sie auch keine Parallelkomponenten unterstützen.
// Im Kernel haben wir diese Änderungen zusammen vorgenommen...
//
if (!GetVersionEx((OSVERSIONINFO *)&osviex))
{
return FALSE ; // Keine DLL-Umleitung
}
// Dann verfügte NT4 SP4 über Unterstützung für OSVERSIONINFOEX,
// unterstützte jedoch nicht die DLL-Umleitung.
// Wenn die DLL-Umleitung in künftigen NT4SPs angeboten
// wird, muss dieser Code aktualisiert werden.
//
if ( (osviex.dwPlatformId == VER_PLATFORM_WIN32_NT) &&
(osviex.dwMajorVersion < 5) )
{
return FALSE ;
}
// Für andere Plattform-IDs Annahme, dass parallele Komponenten
// unterstützt werden
return TRUE ;
}
Installieren und Deinstallieren
Es ist entscheidend, dass Sie Ihre Komponente direkt installieren und deinstallieren. Im Idealfall müssen Sie Ihre Komponente lediglich in das Anwendungsverzeichnis kopieren bzw. aus dem Anwendungsverzeichnis löschen, um sie zu installieren oder zu deinstallieren. Wenn Sie jedoch eine COM-Registrierung oder eine sonstige Einrichtung der Komponente vornehmen müssen, sollte dabei eine parallele Kompatibilität sichergestellt werden.
Windows 2000 umfasst Windows Installer Version 1.1. Dieses Dienstprogramm unterstützt die Installation und Deinstallation von parallelen Komponenten. (Windows Installer wird nach der Veröffentlichung von Windows 2000 auch online erhältlich sein.) Bei der Registrierung Ihrer parallelen COM-Komponente müssen Sie sicherstellen, dass die Spalte Attributes in der Tabelle Class auf den Wert msidbClassAttributesRelativePath gesetzt ist. Dadurch wird die Komponente mit einem relativen Pfadnamen gespeichert, und es sind mehrere Kopien derselben Komponente zulässig.
Sie sollten bedenken, dass Ihre Komponente zwar für das Anwendungsverzeichnis privatisiert ist, eine andere Anwendung jedoch auf diesem Computer eine andere Version installiert haben könnte. Bei der Installation oder Deinstallation dieser Komponente sollten Sie nichts tun, was negative Auswirkungen auf andere Anwendungen haben könnte. Daher müssen Sie die Anwendung, die Ihre Komponente verwendet, ordnungsgemäß; über die Selbstregistrierungs-Einstiegspunkte DLLRegisterServer oder DLLUnregisterServer (für COM-Komponenten) oder DllInstall (für Win32- oder COM-Komponenten) installieren. Weitere Informationen zu diesen
Funktionen finden Sie unter "Register Server" (in Englisch) im Plattform-SDK.
Zur ordnungsgemäß;en Installation Ihrer Komponente im Anwendungsverzeichnis gehen Sie wie bei einer regulären Komponente vor, führen jedoch zusätzlich die folgenden Schritte aus:
1. | Stellen Sie bei der Registrierung von GUIDs sicher, dass diese über relative Pfadnamen verfügen. |
2. | Stellen Sie sicher, dass ein Verweiszähler für Ihre GUID vorliegt. |
3. | Wenn die GUID vorhanden ist, erhöhen Sie Ihren Verweiszähler.
{00000109-0000-0010-8000-00AA006D2EA4}
\InprocServer32
Default = "meineKomponente.dll"
ReferenceCount=1
Anmerkung Typbibliotheken sollten in Ihrer DLL enthalten sein und müssen nicht in der Systemregistrierung registriert werden. |
Zur ordnungsgemäß;en Deinstallation Ihrer Komponente im Anwendungsverzeichnis gehen Sie wie bei einer regulären Komponente vor, führen jedoch zusätzlich die folgenden Schritte aus:
| • | Verringern Sie Ihren Verweiszähler. Wenn er 0 erreicht, können Sie die GUID löschen, da keine anderen Benutzer vorliegen. Falls er größ;er als 0 ist, ist eine andere Anwendung im System installiert und vom Registrierungsstatus abhängig. |
DLL/COM-Umleitung
Die DLL/COM-Umleitung erfordert, dass bei der Weitergabe der Anwendung die ausführbare Anwendungsdatei sowie alle isolierten Komponenten in das Anwendungsverzeichnis (anstatt in das Systemverzeichnis) installiert werden. Auß;erdem wird eine ".local"-Datei an das Anwendungsverzeichnis weitergegeben, um das Windows-Bindungsverhalten zu ändern, so dass die Anwendung nicht an die global gemeinsam genutzte Version, sondern an die isolierten Komponenten gebunden wird.
Daher verwendet die Anwendung eine Komponente, die problemlos gemeinsam mit einer an anderer Stelle (d.h. in einem anderen Anwendungsverzeichnis oder im Systemverzeichnis) installierten anderen Version derselben Komponente ausgeführt werden kann. Wenn eine andere Anwendung im System eine andere Version erfordert, hat dies keine Auswirkungen auf Ihre Anwendung, und beide Anwendungen werden mit den entsprechenden Versionen der Komponente ausgeführt.
Wenn eine andere Anwendung eine neue Version einer Komponente im System installiert, hat dies keine Auswirkungen auf die Anwendungsversion der Komponente, da Sie diese in Ihrem Anwendungsverzeichnis installiert haben. Ihre Anwendung verwendet weiterhin dieselbe Version der Komponente, die Sie mit Ihrer Anwendung ausgeliefert haben, während die andere Anwendung ihre eigene Version verwendet. Das Betriebssystem kann beide Versionen gleichzeitig in den Arbeitsspeicher laden.
Anmerkung Isolierte COM-Komponenten müssen ordnungsgemäß; im Betriebssystem registriert werden, so dass keine Konflikte zwischen verschiedenen Versionen der Komponente auftreten. Diese Registrierung erfordert, dass sich zwar zwischen verschiedenen Versionen die Komponentenimplementierung ändern kann, registrierte COM-Metadaten (z. B. CLSID, ProgID, Typbibliothek und Threadingmodell) jedoch beibehalten werden.
Anmerkung Sowohl Windows 2000 als auch Windows 98 Zweite Ausgabe unterstützen die DLL/COM-Umleitung. Diese Funktion wird von älteren Versionen des Windows-Betriebssystems nicht unterstützt.
Verwenden der DLL/COM-Umleitung
Die DLL/COM-Umleitung ermöglicht es den Entwicklern oder Administratoren, bestimmte vorhandene Komponenten für die von ihnen erstellte oder weitergegebene Anwendung zu isolieren. In diesem Abschnitt wird erörtert, wie Sie die DLL/COM-Umleitung aktivieren und die zu isolierenden Komponenten auswählen.
Aktivieren der DLL/COM-Umleitung
Die DLL/COM-Umleitung wird durch das Vorhandensein einer ".local"-Datei auf Anwendungsbasis aktiviert. Die ".local"-Datei ist eine leere Datei in demselben Verzeichnis wie die EXE-Datei der Anwendung. Sie hat denselben Namen wie die EXE-Datei der Anwendung, wobei zusätzlich ".local" an den Dateinamen angehängt ist.
Wenn Sie z. B. die DLL/COM-Umleitung für eine Anwendung namens meineAnwendung.exe aktivieren möchten, erstellen Sie eine leere Datei mit dem Namen meineAnwendung.exe.local in dem Verzeichnis, in dem die Datei meineAnwendung.exe installiert wird.
Wenn die DLL/COM-Umleitung aktiviert ist und die Anwendung eine DLL oder OCX lädt, sucht Windows die DLL oder OCX stets als Erstes in dem Verzeichnis, in dem die EXE-Datei der Anwendung installiert ist. Wenn dieses Verzeichnis eine Version der DLL oder OCX enthält, wird diese (unabhängig davon, welcher Verzeichnispfad in der Anwendung oder Registrierung angegeben ist) von der Anwendung verwendet. Falls das Verzeichnis keine Version der DLL oder OCX enthält, wird der normale Suchpfad oder Serverpfad verwendet.
Auswählen von zu isolierenden Komponenten
Die DLL/COM-Umleitung ermöglicht die Isolierung von vorhandenen Komponenten, wenn auf einem Computer installierte Anwendungen verschiedene Versionen derselben Komponente erfordern. Es sind keine Codeänderungen an der Komponente erforderlich, da die aktivierte DLL/COM-Umleitung das Windows-Bindungsverhalten ändert.
Bisher wurde die parallele Ausführung von verschiedenen Komponentenversionen beim Entwerfen von Komponenten jedoch i.d.R. nicht berücksichtigt. Komponenten können zwar parallel installiert (d.h. an einem gemeinsam genutzten Speicherort installiert und in eine oder mehr Anwendungen isoliert), jedoch nicht parallel ausgeführt werden. Dies liegt daran, dass einige Komponenten einen globalen Status (z. B. die in der Registrierung gespeicherten Einstellungen) verwenden und davon ausgehen, dass jeweils nur eine Version der Komponente auf dem Computer installiert ist. Auß;erdem geht die Komponente bei der Suche nach anderen benötigten Ressourcen u.U. von dem Verzeichnis aus, in dem sie installiert ist.
Daher sollten Anwendungen, die isolierte Komponenten verwenden, sowohl eigenständig als auch im Kontext der anderen Anwendungen getestet werden, aus denen die Komponenten isoliert werden. Die Erfahrungen von Microsoft haben gezeigt, dass gemeinsam genutzte Komponenten in den meisten Szenarios parallel ausgeführt werden können. In einigen Fällen muss jedoch zunächst eine Anwendung geschlossen werden, bevor die nächste ausgeführt werden kann.
Bei der Auswahl von zu isolierenden Komponenten sollten die folgenden Richtlinien befolgt werden:
| • | Versuchen Sie nicht, Dateien zu isolieren, die mit Systemdateischutz versehen und im Lieferumfang von Windows 2000 enthalten sind. (Dies gilt für die meisten SYS-, DLL-, EXE- und OCX-Dateien.) |
| • | Sie müssen alle Anwendungen testen, um v.a. in den Bereichen eine parallele Gültigkeit sicherzustellen, in denen eine gemeinsame Nutzung auftreten kann, da die aktuellen Betriebssysteme keine Parallelität erzwingen. |
| • | Stellen Sie sicher, dass Sie weiterhin schnelle Korrekturen an Komponenten vornehmen können, auch wenn diese sich nun in willkürlich platzierten Anwendungsverzeichnissen befinden. Als Administrator müssen Sie wissen, an welchen Stellen Sie Korrekturen an Ihrer Komponente vornehmen müssen. |
Szenario I: Privatisieren von ActiveX-Steuerelementen für eine Anwendung
In diesem Szenario kann ein Administrator eine neue Anwendung nicht weitergeben, da die neue Anwendung eine Version eines in Visual Basic erstellten ActiveX-Steuerelements verwendet, die sich von der erforderlichen Version für derzeit weitergegebene Anwendungen unterscheidet.
Über die Zeit haben Fehlerkorrekturen und andere Änderungen am ActiveX-Steuerelement semantische Unterschiede bewirkt, die die das Steuerelement verwendende Anwendung beschädigen, wenn nicht die Version verwendet wird, für die sie getestet wurde. Der Administrator muss verschiedene Versionen des ActiveX-Steuerelements mit unterschiedlichen Anwendungen ausführen können, ohne jede Anwendung korrigieren und neu testen zu müssen, auf die eine Änderung des ActiveX-Steuerelements Auswirkungen hätte.
Anmerkung In Visual Basic ist es für Entwickler derzeit relativ schwierig, parallele ActiveX-Steuerelemente zu schreiben. Dies liegt daran, dass bei der Registrierung von in Visual Basic verfassten ActiveX-Steuerelementen der vollständig qualifizierte Pfad in die OCX-Datei in die Registrierung geschrieben wird.
Der Administrator kann die Verwendung der richtigen Version des ActiveX-Steuerelements durch eine neue Anwendung erzwingen und sicherstellen, dass die Konfiguration der vorhandenen Anwendungen unverändert bleibt, indem er die Einrichtung der neuen Anwendung wie folgt ändert:
| • | Installieren der neuen Version des ActiveX-Steuerelements in dem Verzeichnis, in dem sich die EXE-Datei der Anwendung befindet. |
| • | Installieren einer .local-Datei in dem Verzeichnis, in dem sich die EXE-Datei der Anwendung befindet. Die .local-Datei legt fest, dass bei jeder Ausführung der Anwendung das ActiveX-Steuerelement aus dem Verzeichnis geladen wird, in dem sich die EXE-Datei der Anwendung befindet. |
Szenario II: Privatisieren von Win32-DLLs für eine Anwendung
In diesem Szenario erfährt der Administrator, dass eine vorhandene Anwendung nach der Weitergabe einer neuen Anwendung ausgesetzt hat. Er kann ermitteln, dass das Problem durch die Veränderung einer gemeinsam genutzten Komponente verursacht wird, die bewirkt, dass die neue Version der gemeinsam genutzten Komponente keine Abwärtskompatibilität mit der älteren Version unterstützt.
Der Administrator kann die Anwendung korrigieren, indem er folgende Schritte ausführt:
| • | Installieren der älteren Version der gemeinsam genutzten DLL in dem Verzeichnis, in dem sich die EXE-Datei der vorhandenen Anwendung befindet. |
| • | Erstellen einer .local-Datei in dem Verzeichnis, in dem sich die EXE-Datei der vorhandenen Anwendung befindet. Die .local-Datei legt fest, dass bei jeder Ausführung der Anwendung die DLLs aus dem Verzeichnis geladen werden, in dem sich die EXE-Datei der Anwendung befindet. |
Erwägungen beim Installieren von isolierten COM-Servern
Die DLL/COM-Umleitung wird dadurch erzielt, dass die DLL- oder OCX-Datei an einem neuen Speicherort installiert wird, der für die Anwendung privat ist. Andere Systemstatus für die COM-Server werden jedoch nicht isoliert. Dies hat bestimmte Auswirkungen für das Isolieren von COM-Servern.
Wenn Sie einen isolierten COM-Server installieren und auf dem Computer (z. B. durch eine andere Anwendung) bereits eine Version der Komponente installiert ist, sollten Sie sicherstellen, dass der InprocServer-Dateipfad nicht mit dem neuen Pfad der isolierten Komponente überschrieben wird. Bei isolierten COM-Servern wird der InprocServer-Dateipfad zur Laufzeit ignoriert. Vorhandene Anwendungen, die keine DLL/COM-Umleitung verwenden, erfordern jedoch, dass der InprocServer-Dateipfad weiterhin den Speicherort des zuvor installierten COM-Servers angibt. Dies hat folgende Auswirkungen:
| • | Wenn Sie einen isolierten COM-Server installieren und bereits eine Version des COM-Servers installiert ist, registrieren Sie den isolierten COM-Server nicht zum Zeitpunkt der Installation. |
Wenn hingegen noch keine Version des isolierten COM-Servers auf dem Computer installiert ist, muss der COM-Server registriert werden. Das erläuterte Problemszenario tritt auf, wenn ein COM-Server für eine Anwendung isoliert und im Verzeichnis mit der EXE-Datei der Anwendung installiert wird, und später nicht isolierte Anwendungen installiert werden, die diese Komponente erfordern. In diesem Fall ist es unwahrscheinlich, dass bei der Deinstallation der isolierten Anwendung isolierte COM-Komponenten als gemeinsam genutzte Dateien behandelt und andere Anwendungen beschädigt werden. Dies hat folgende Auswirkungen:
| • | Wenn Sie einen isolierten COM-Server installieren und auf dem Computer noch keine Version des COM-Servers installiert ist, kopieren Sie die DLL- oder OCX-Datei sowohl in das EXE-Verzeichnis der Anwendung als auch in das Systemverzeichnis (oder an einen anderen gemeinsam genutzten Speicherort). Registrieren Sie die Kopie im Systemverzeichnis (oder an einem anderen gemeinsam genutzten Speicherort). |
Für vorhandene Komponenten, bei denen bestimmte Versionen von einigen Anwendungen gemeinsam genutzt werden und andere Versionen für bestimmte Anwendungen privat sind, lautet die Faustregel wie folgt: Stellen Sie nach der Installation von Anwendungen, die isolierte Versionen von potentiell gemeinsam genutzten Komponenten verwenden, sicher, dass sowohl eine gemeinsam genutzte Version als auch eine isolierte Version der Komponente installiert und die gemeinsam genutzte Version registriert ist. Dadurch können Deinstallationsprogramme die isolierten Versionen entfernen, ohne andere Anwendungen zu beschädigen.