laden von DLL

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Antworten
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

laden von DLL

Beitrag 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?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 851
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 192 Mal
Kontaktdaten:

Re: laden von DLL

Beitrag 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.
Gruß Marcus

Erkenne, was du findest, dann weißt du, wonach du gesucht hast
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: laden von DLL

Beitrag 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?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: laden von DLL

Beitrag 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
Gruß
Hubert
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: laden von DLL

Beitrag 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.
--
Hans-Peter
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: laden von DLL

Beitrag 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.
Herzlich,
Tom
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: laden von DLL

Beitrag 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.
Antworten