Seite 1 von 1

laden von DLL

Verfasst: Mo, 15. Mär 2021 13:34
von Manfred
Ich habe irgendwo einmal gelesen, dass ein/das OS eine DLL, die von mehreren Programmen genutzt wird nur 1x in den Speicher lädt, aber allen Programmen zur Verfügung stellt, die es laden wollen. Stimmt das so, oder war das eine falsche Info?
Wenn dem so ist, das OS sich darum kümmert, dann wäre meine nächste Frage, wie sieht es denn dann genau aus? Gilt das immer nur, wenn die Programme die DLL aus nur einem Verzeichnis laden, oder können die Programme und DLL stehen wo sie wollen, das OS erkennt das und kümmert sich darum?

Re: laden von DLL

Verfasst: Mo, 15. Mär 2021 13:58
von Marcus Herz
Ich weiß, dass eine Applikation eine DLL nur einmal lädt. Bei 2. Versuch bekommst du einfach den Handle der geladenen DLL zurück, in jedem Xbase Thread den gleichen. Selbst wenn die DLL im Windows Cache liegt, bekommt jede Applikation einen eigenen Hanlde zur DLL. Der Hanlde muus für Windows eindeutig sein.
Windows chached ganz viel. auch DLLs. DIe werden aber in jedem Fall über Pfad identifiziert, da gibts sogar ein Windows System Unterverzeichnis, wo die DLLs nochmal als Kopie liegen. Aber das verwaltet Windows. Nicht unser Problem.

Re: laden von DLL

Verfasst: Mo, 15. Mär 2021 14:01
von Manfred
ich verstehe Deine Aussage jetzt so, das x Programme in x Verzeichnissen mit jeweils der gleichlautende DLL trotzdem jeweils die DLL nachladen, weil die DLL jedesmal in einem andern Verzeichnis steht. Also in dem Fall keine Ersparnis der Resource?

Re: laden von DLL

Verfasst: Mo, 15. Mär 2021 14:19
von brandelh
Ich meine, dass die DLL aus einem gemeinsamen Verzeichnis für alle gilt, das hatte M$ so vorgesehen und musste feststellen, dass es Programm-Versionskonflikte geben kann.

Daher lade ich alle nötigen DLL in das jeweilige EXE Verzeichnis, die so gestarteten DLL müssten für die EXE einmalig sein, denn ich kann ja Xbase++1.90 und 2.00 Anwendungen gleichzeitig laufen lassen.
Ich vermute dass dies auch bei normalen DLL gilt, denn nur so kann man eine spezielle DLL für eine Anwendung sicherstellen, auch wenn eigentlich eine andere aktuell wäre.

Aber ich kann mich natürlich auch irren ;-)
Windows chached ganz viel. auch DLLs.
DIe werden aber in jedem Fall über Pfad identifiziert, da gibts sogar ein Windows System Unterverzeichnis,
wo die DLLs nochmal als Kopie liegen. Aber das verwaltet Windows. Nicht unser Problem.
das spricht für meine Aussage, DLL im EXE Verzeichnis # DLL in einem anderen Verzeichnis :D

Re: laden von DLL

Verfasst: Mo, 15. Mär 2021 14:24
von HaPe
Hallo Marcus !
Ich weiß, dass eine Applikation eine DLL nur einmal lädt
Als Ergänzung:
Es gibt Single- und Multithreaded-COM-DLLs.
Visual Foxpro kann beide Arten erstellen; zb. für den IIS für Web-Services über SOAP - da stellt man auf Multithreaded.

Multithreaded ist notwendig, wenn der IIS mehrere Instanzen der COM-DLL lädt und damit jeweils die Umgebung (globale Varibalen usw.) getrennt hält.
Andernfalls würden der zweite Aufruf der DLL die Umgebung des ersten Aufrufes manipulieren.

Re: laden von DLL

Verfasst: Mo, 15. Mär 2021 15:02
von Tom
Statische DLLs, die über den selben Pfad referenziert werden, werden nur einmal geladen, ganz egal, von wie vielen Programmen sie genutzt werden, etwa die Windows-DLLs wie "KERNEL32.DLL" usw. Dynamische DLLs werden je Ladeaufruf einmal geladen, zuweilen von einzelnen Applikationen mehrfach, wenn sie in verschiedenen Threads geladen und entladen werden.

Re: laden von DLL

Verfasst: Di, 16. Mär 2021 11:00
von mikehoffmann
Dank Jeffrey Richter weiß ich, was wirklich passiert.

Ich versuch mal, Euch in das Gelernte einzuweihen.

Im Rechner ist physischer Speicher verbaut, das RAM.

Unsere Anwendung sieht virtuellen Speicher in ihrem Prozess. In diesen virtuellen Speicher wird der physische Speicher eingeblendet. Kreuz und quer und putz und munter. Die virtuelle Adresse und die physische Adresse sind zwei Paar Ballettschuhe, aber es gibt im Prozess ein festes Mapping, so dass von der virtuellen Adresse immer zur physischen umgerechnet werden kann. Da braucht man sich nicht drum kümmern, das geht auf's Haus mit den Fenstern.

Alle PE-Module ("Portable Executables", auch "Images") kommen auf dem Umweg über den physischen Speicher in unseren Prozess. Dlls und Exes sind PE-Module.

Der physische Speicher wird durch diese PE-Modul-Dateien "gebacked", also nicht gebacken, sondern er wird damit hinterlegt. Wichtig ist zu verstehen, dass Backen nix mit Laden zu tun hat. Backen heißt nur, der physische Speicher wird mit der Datei assoziiert. Mehr erstmal nicht. Erst wenn auf den Speicher zugegriffen wird, dann findet der Transfer von der Datei in den physischen Speicher und damit auch in den virtuellen Speicher unseres Prozesses statt. Geht auch auf's Haus mit den Fenstern. Wenn das übrigens nicht klappt, dann kommt der Anwender in den dunkelblauen Himmel, auch BSOD genannt.

Erster cooler Trick des Hausherrn: Es wird nicht gleich das ganze Modul geladen, sondern erst mal nur ein Bissel. Wenn mehr gebraucht wird, dann wird halt wieder von der Datei in den Speicher übertragen.

Zweiter cooler Trick des Hausherrn: Der physische Speicher, der nun durch das PE-Modul gebackt ist, wird im virtuellen Speicher mehrerer Prozesse eingeblendet. Wird also eine Dll oder Exe gebraucht, schaut das Betriebssystem, ob die schon mit physischem Speicher assoziiert ist. Ist das der Fall, wird in Windeseile der assoziierte physische Speicher in den virtuellen Speicher des anfordernden Prozesses eingeblendet und der Code kann mit Volldampf voraus sofort starten.

Nun zum kleinen aber feinen Unterscheid zwischen Exe und Dll:
Die Exe hat einen Einstiegspunkt, bei dem der Primärthread loslegt, nachdem sie in den Prozess eingeblendet wurde. Wenn der Thread von da zurückkehrt, ist der Prozess beendet.
Die Dll hat einen Einstiegspunkt, der jedes Mal gerufen wird, wenn die Dll frisch in einen Prozess eingeblendet wurde, und auch jedes Mal, wenn ein neuer Thread gestartet wurde. Dieser Einstiegspunkt wird auch jedes Mal gerufen, wenn ein Thread oder der Prozess beendet wird.

Mit dieser Technik des "Backing" kriegt man auch die ganzen anderen tollen Sachen hin, die das Leben mit den Fenstern so schön machen. Shared Memory (geteilter Speicher zwischen zwei Prozessen) und auch die Swap-Datei funktionieren mit dieser Technik. Raffiniert und pfeilschnell.
Also: Dlls und Exes sind maximal einmal mit physischem Speicher assoziert. Sie "backen" den Speicher. Der "gebackte" physische Speicher kann in mehrere Prozesse eingeblendet sein, aber in einen Prozess nur einmal. Er kann in jedem Prozess eine andere virtuelle Adresse haben.

Das war alles im Überblick. Im Detail ist das ziemlich ausgefeilt und da fängt der Spaß erst so richtig an.