Sonstiges: Warum DLL Objekte nie global sind


Als dieser Artikel verfasst wurde, war ActiveX Programmierung zwar nicht mehr unbedingt 'hip'. Trotzdem: Es gibt offensichtlich immer noch eine Menge Programmierer 'da draußen', die sich damit auseinander setzen (müssen).

Viele dieser Programmierer scheinen sich immer noch mit einem alten Problem herumzuschlagen:

Sie haben eine ActiveX-DLL und möchten ein COM-Objekt so erstellen, dass verschiedene Clients der ActiveX-DLL mit dem gleichen COM-Objekt arbeiten - und scheitern!

Unter Mehrfache Verwendung von Objektinstanzen wird anhand eines VB 6.0 Beispiels erklärt, wie diese Beschränkung mit regulären Mitteln mit Hilfe einer ActiveX-EXE umgangen werden kann.

Warum aber können verschiedene Clients einer ActiveX-DLL deren COM-Objekte nicht gemeinsam nutzen?

Wenn eine Anwendung eine DLL einbindet, hat das zur Folge, dass der Binärcode der DLL so behandelt wird, als sei dies der Binärcode der Anwendung selbst. Dies gilt erst recht für jede Variable, die innerhalb des DLL-Codes erstellt wird bzw. existiert.

Mit anderen Worten: obwohl die DLL nur einmal auf der Festplatte gespeichert ist, wird sie jedesmal wenn sie von einer Anwendung geladen wird, in den Speicherbereich der betreffenden Anwendung geladen.

Da jede Anwendung ihren eigenen geschützten Speicherbereich hat, ist es vollkommen ausgeschlossen, dass eine Anwendung mit regulären ActiveX-Mitteln auf den Speicherbereich einer anderen zugreift.

Mancher Leser möchte dieser Argumentation nicht folgen, schließlich ist bekannt, dass Windows den Binärcode einer DLL nur einmal lädt (wenn die erste Anwendung die DLL verwendet) und anschließend jeder weiteren Anwendung nur eine Kopie der bereits zuvor geladenen DLL zur Verfügung stellt.

Diese Aussage ist richtig, widerspricht jedoch nicht dem oben gesagten. Um das genau zu verstehen, muss man sich etwas näher mit der Speicherverwaltung von Windows auseinander setzen. Ich möchte dies nicht vertiefen. nur soviel:

Windows verfügt über einen ausgeklügelten Mechanismus, um sicherzustellen dass jede DLL nur einmal von der Festplatte in den Arbeitsspeicher geladen werden muss und trotzdem jede Anwendung die DLL so sieht und verwendet, als habe sie eine eigene exklusive Instanz.

Der Artikel DLL-Injektion über API-Hooking enthält eine ausführliche und gut verständliche Beschreibung dazu.

Seitenanfang

Kontaktaufnahme- und Terminvereinbarung:

Bei Fragen und für Terminvereinbarungen erreichen Sie uns unter:

0 63 49 99 07 38

0 151 51 95 34 00

Oder nutzen Sie das Kontaktformular




Ihr Ansprechpartner:


Hier sollte das Fahnungsfoto zu sehen sein.

Ralf Kunsmann

Spezialist für VBA-Programmierung
(alle Office-Anwendungen)
Entwickler der
VBA-Extension-Tools