DLL wird zu oft geladen!

[m_junglas]

Hallo zusammen,

ich habe ein Problem: ich programmiere gerade ein Projekt in dem viele Teile in eigene DLLs ausgelagert werden sollen.
So habe ich schon ein paar DLLs erzeugt, die gut funktionieren.
Eine davon ist z.B. eine, die sich um Logfiles kümmert und die entsprechende Funktion wird von allen DLLs auch benutzt.

Als ich mehrere DLLs in das Hauptprogramm eingebunden habe gab es dann aber Seltsamkeiten. Nach einigen Tests habe ich herausgefunden, dass z.B. diese Logfile-DLL für jedes Modul wiederum eigenständig geladen wurde.

So hat mir auch z.B. der ProcessExplorer zwei identische DLLs gezeigt, die mein Programm dann geladen hat.
Beide DLLs wissen voneinander nichts und jede "gehört" zu dem jeweils aufrufenden Modul (andere DLL oder Hauptprogramm).

Das ist für mein Project jetzt nicht sehr hilfreich. Ich dachte eigentlich eine DLL wird einmal in den Adressraum geladen und dann entsprechend vom ganzen Prozess aus benutzt.
In Zukunft sollen die DLLs auch überkreuz bekannt sein udn da weiss ich noch garnicht, was dann passieren wird.

Wie kann ich das hinbekommen? Oder mache ich irgendwas falsch?


Ich benutze übrigends Delphi 6. Die DLLs werden (noch) statisch eingebunden:

Delphi-Quellcode:

const
  LOGDLLNAME = '.\dll\Solid_Log.dll';

procedure WriteToLog (Infotext : shortstring; Level : integer); external LOGDLLNAME;
procedure LOGinitialize; external LOGDLLNAME name 'DLLinitialize';
procedure LOGfinalize; external LOGDLLNAME name 'DLLfinalize';

Tschüss

/\/\arcus

p.s. das "stdcall" fehlt, das ist hier aber richtig.

[brechi]

Das kann definitiv nicht vorkommen. Jede DLL wird nur einmal geladen. Auch wenn mehrmals LoadLibraryA bzw die statische Einbundung benutzt wird, ist die dll nur einmal im Speicher.

Mach mal einen Screenshot von dem angeblichen Doppelladen. (z.b. vom ProcessExplorer)

[m_junglas]

Hallo!

Klaro, hier ist der Screenshot vom ProcessExplorer.

Aber schön, dass Du mir nicht glaubst. Das bedeutet, dass das Problem nicht zu weit verbreitet ist und nicht normal. Denn das hätte mir dann wirklich Kopfzerbrechen bereitet.

Tschüss

/\/\arcus

[brechi]

Einfach mal einen Rechtsklick machen.
Dann sieht man, dass es sich nur einmal um ein Image handelt.
Beim anderen ist es ein Mapping von der Data Section.

[m_junglas]

Hallo,

also per Rechtsklick bekomme ich das nicht raus.
Außerdem verschwindet einer der beiden Einträge, wenn ich z.B. in der anderen DLL die Referenz entferne.
D.h: Zwei Importe -> 2x DLL. Ein Import -> 1x DLL.

Unangenehm für mich ist wie gesagt, dass die zwei Teile unabhängig laufen und z.B. ihre eigenen globalen Variablen haben, die ich eigentlich bei jedem Aufruf brauche.
Ich habe auch mal beim Laden der DLL eine Zufallszahl auswürfeln lassen und habe sie mit ins Logfile geschrieben. Da sieht man dann deutlich, dass es zwei seperate "DLLs" sind, die abwechselnd ins Logfile schreiben.

Ich habe da leider noch garkeine Lösung.

Tschüss

/\/\arcus

[m_junglas]

Hallo zusammen,

ich weiss nicht ob es noch jemanden interessiert. Aber ich weiss woran es liegt:

Der Fehler war bereits in meinem ersten Posting enthalten: es ist der PFAD !

Das ".\dll\xxxxx.dll" darf man nicht benutzen. Offenbar erkennt das Windows-System (oder Delphi?) eine solche DLL NICHT als gleich, wenn sie aus verschiedenen Orten aus mit diesem Pfad angesprochen wird.

Ich weiss nicht ob es ein Delphi-Code ist oder Windows... aber es ist ein Armutszeugnis! Ein expandierter Pfad hätte da beim Vergleich Wunder getan...
Offenbar "darf" man DLLs nur direkt vom Dateinamen aus ansprechen. Ein Pfad ist Tabu.

Nunja, ich muss nun all meine DLLs in das Rootverzeichnis zum Hauptprogramm legen, weil eben Pfade nicht erkannt werden. Eine Sortierung "Hauptprogramm" -> "DLL-Unterordner" ist so nicht mehr möglich.
Lächerlich.


Und ich bin der erste, der sowas seit Delphi 1 hier probiert und fragt???
E N T Ä U S C H E N D!

Ich muss mein Geld zum Studium hier verdienen und habe Delphi deswegen angesprochen, weil es eine saubere Sprache ist als jedes C oder gar C++ - ja sogar Java.
Tja!?

Tschau

/\/\arcus

p.s. Ich habe ein Beispielprogramm erstellt. Sourcen und Binaries kann ich auf Wunsch rausschicken.

[brechi]

Häng die Files doch einfach mal an.
Ist die dll unterschiedlich oder nur der Pfad?

Bei 2 gleichen Dlls in unterschiedlichen Pfaden werden beide geladen.
Bei der gleichen dll in unterschiedlichen Pfaden [C:\bla\blub.dll] und z.b [bla\blub.dll], sollte die dll nur einmal geladen werden.

Sowohl bei der statischen als auch bei der dynamischen Einbindung macht Delphi da nichts.

Da micht höchstens Punkt 2 etwas verwundern würde warum es nicht klappt, gebe ich bezüglich deinen Posts keinen weiteren Kommentar ab. Würd mich nicht wundern wenn der Fehler mal wieder VOR dem Rechner sitzt.

Ich teste es aber selbst mal nach...

[brechi]

folgender Test:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  windows;


procedure blub; external 'F:\delphi\dlltest\test.dll' name 'blub';
procedure blub2; external 'test.dll' name 'blub';

begin
  blub;
  blub2;
end.

Delphi-Quellcode:

library test;

uses
  windows;

procedure blub;
asm
  nop
end;

exports blub;

begin
  MessageBoxA(0,'test',nil,0);
end.

Ergibt 2 mal die MessageBoxA mit statsicher einbindung von unterschiedlichen Pfaden.
Macht man es aber dynamisch (und das sollte man immer bei Pfadangabe) dann wird die dll nur ienmal geladen.

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  windows;


var blub: procedure;
var blub2: procedure;

begin
  @blub := GetProcAddress(LoadLibrary('F:\delphi\dlltest\test.dll'),'blub');
  @blub2 :=GetProcAddress( LoadLibrary('test.dll'),'blub');
  blub;
  blub2;
end.

Und es liegt dann an Windows, wenn er den absoluten Pfad (bei schon einer geladenen Dll) mit dem relativen Pfad als gleich ansehen soll und nicht an Delphi (statisch = Importtabelle = delphi kann nix dafür macht nur des was der Programmierer sagt)
Obwohl man dann noch darüber diskutieren kann obs am Programmierer oder wirklich an Windows liegt bei unterschiedlichen Pfaden.

Trotzdem: Wer eine statische Einbindung macht ist selbst schuld ^^
Bevor du alles umstruktuierst versuchs erstmal mit der dynamischen Einbindung.


PS: Entäuschend ist es eher wenn man keine Ahnung hat und es dann einfach mal auf die Programmiersprache / Umgebung schiebt.