TObject, DLL, DLL Freigabe

[TiGü]

Ich versuchs mal mit meinen bescheidenen Wissensstand:
Es sind zwei verschiedene Speichermanager!
Einer in der Anwendung, einer in der DLL.
Die Strings (AppVersion, Model...) unterliegen den Speichermanager der DLL.
Wenn die DLL entladen wird, werden auch alle referenzgezählten Typen darin freigeben, also die Strings!
Ergebnis: Du hast im MasterVersion-Objekt in deiner Anwendung zwar noch gültige Adressen auf irgendwelche Speicherbereiche, aber da steht jetzt was anderes bzw. Müll drin.

[haentschman]

Danke erstmal

Zitat:

Die Strings (AppVersion, Model...) unterliegen den Speichermanager der DLL.

Ich glaube ja auch das es daran liegt. Aber wieso? Die gehören zu dem Objekt welches im Hauptthread erzeugt wurde. Liegt es daran, daß der Text über eine Stringlist aufbereitet wird welche in der DLL erzeugt wird? Da müßte aber schon beim Freigeben der Stringlist Müll drinstehen.

[schöni]

Zitat von TiGü:

Ich versuchs mal mit meinen bescheidenen Wissensstand:
Es sind zwei verschiedene Speichermanager!
Einer in der Anwendung, einer in der DLL.
Die Strings (AppVersion, Model...) unterliegen den Speichermanager der DLL.
Wenn die DLL entladen wird, werden auch alle referenzgezählten Typen darin freigeben, also die Strings!
Ergebnis: Du hast im MasterVersion-Objekt in deiner Anwendung zwar noch gültige Adressen auf irgendwelche Speicherbereiche, aber da steht jetzt was anderes bzw. Müll drin.

Heißt das, das bei der BPL ein Speichermanager für alles zuständig ist, während bei der gewöhnlichen dll 2 verschieden sind. Ich diskutier gerade beim Lazaurs 1.2 Thread mit, dort geht es um die notwendige Neuübersetzung der IDE bei Installation neuer Komponenten. Ist also das Speichermanagerproblem einer der Gründe dafür?

@mkinzler: Was ist eine "flache Schnittstelle"?

[mkinzler]

Zitat von schöni:

Zitat von TiGü:

Ich versuchs mal mit meinen bescheidenen Wissensstand:
Es sind zwei verschiedene Speichermanager!
Einer in der Anwendung, einer in der DLL.
Die Strings (AppVersion, Model...) unterliegen den Speichermanager der DLL.
Wenn die DLL entladen wird, werden auch alle referenzgezählten Typen darin freigeben, also die Strings!
Ergebnis: Du hast im MasterVersion-Objekt in deiner Anwendung zwar noch gültige Adressen auf irgendwelche Speicherbereiche, aber da steht jetzt was anderes bzw. Müll drin.

Heißt das, das bei der BPL ein Speichermanager für alles zuständig ist, während bei der gewöhnlichen dll 2 verschieden sind.

Ja.

Zitat:

@mkinzler: Was ist eine "flache Schnittstelle"?

Die einzelnen Teile gesondert. Bzw. über ein Interface

[haentschman]

@mkinzler

Kannst du mal skizzieren wie ich eine DLL über ein Interface anbinde und keine "Speicher" Probleme habe. Wenn ich mir von der DLL das Interface auf die "Proceduren" geben lasse ist das Speicherproblem Geschichte?

[jaenicke]

Im Grunde sehr einfach:

Delphi-Quellcode:

  IMasterDeviceVersion = interface
  ['{DF6962EE-B638-4B59-9BE6-82B8BB369477}']
    function GetAppVersion: WideString;
    function GetModel: WideString;
    function GetSysVersion: WideString;
    procedure SetAppVersion(const Value: WideString);
    procedure SetModel(const Value: WideString);
    procedure SetSysVersion(const Value: WideString);

    property Model: WideString read GetModel write SetModel;
    property AppVersion: WideString read GetAppVersion write SetAppVersion;
    property SysVersion: WideString read GetSysVersion write SetSysVersion;
  end;

  TMasterDeviceVersion = class(TInterfacedObject, IMasterDeviceVersion)
  strict private
    var
      FModel: WideString;
      FAppVersion: WideString;
      FSysVersion: WideString;
    function GetAppVersion: WideString;
    function GetModel: WideString;
    function GetSysVersion: WideString;
    procedure SetAppVersion(const Value: WideString);
    procedure SetModel(const Value: WideString);
    procedure SetSysVersion(const Value: WideString);
  public
    property Model: WideString read GetModel write SetModel;
    property AppVersion: WideString read GetAppVersion write SetAppVersion;
    property SysVersion: WideString read GetSysVersion write SetSysVersion;
  end;

Und dann:

Delphi-Quellcode:

procedure ParseVersion(const aText: PChar; MasterVersion: IMasterDeviceVersion); stdcall;
//

Du darfst dann natürlich auch in der Anwendung nur noch mit IMasterDeviceVersion usw. arbeiten.

[haentschman]

Danke, das ist wirklich zu einfach. Warum nicht gleich so?

[himitsu]

Jupp, bei Klassen mußt du auf BPLs wechseln.

Wennn du Interfaces nutzt und nicht willst, daß die DLL vor Freigabe des Interfaces freigegeben wird, dann könntest du in dem Objekt eine eigene Instanz der DLL holen.
Im Contructor ein LoadLibrary.

Aber beim Freigeben gibt es ein "kleines" Problemchen, denn da müsstest du jetzt das FreeLibrary innerhalb der DLL aufrufen (im Destructor) aber dann würdest du ja den Coderücksprungpunkt löschen, auf den das FreeLibrary zurück will, womit es dann kannlt, bevor die DLL komplett verlassen wurde.
Man kann da aber einen Thread starten, welcher etwas verzögert die DLL und sich frei gibt. FreeLibraryAndExitThread (aber kein RTL-Thread, sondern nur eine "einfache" Thread-Prozedur, denn sonst bleiben eventuell Speicherlecks zurück ode es knallt dennoch, falls die DLL/RTL sich den Thread merkt und freigeben will, wenn sie freigegeben wird)

[haentschman]

Nachfrage:

Ich hätte noch als Übergabeparameter zur DLL eine generische TObjectList. (hallo DLL, mach mal die Liste voll) Wie gehe ich damit um? Da die Objekte nun zu Interfaces geworden sind geht ja nur TList. Die Interfaces werden dann in der DLL erzeugt und in die Liste gelegt.

Welche Probleme erwarten mich?

Zitat:

Wennn du Interfaces nutzt und nicht willst, daß die DLL vor Freigabe des Interfaces freigegeben wird

...die Frage ist doch, was passiert mit dem Inhalt des Interfaces bzw. der Liste mit den Interfaces beim Entladen der DLL? Bleibt das erhalten?

[himitsu]

Zitat von haentschman:

Zitat:

Wennn du Interfaces nutzt und nicht willst, daß die DLL vor Freigabe des Interfaces freigegeben wird

...die Frage ist doch, was passiert mit dem Inhalt des Interfaces bzw. der Liste mit den Interfaces beim Entladen der DLL? Bleibt das erhalten?

Das Interface geht "kaputt".

Der Speicher in der Liste wird vom Speichermanager der DLL freigegeben
und der Code, auf welchen die Funktionen des Interfaces zeigen ist weg da er ja in der DLL war.



Man könnte zwar absichtlich den Speichermanager zerschießen, damit er die "Speicherlecks" beim Beenden nicht freigibt,
oder man baut seine TList so, daß sie den Speicher z.B. direkt bei Windows holt und nicht über den Speichermanager geht,
oder man sorgt dafür, daß der Speichermanager nicht genutzt wird und stattdessen der Speichermanager der EXE verwendet wird (SharedMM),
aber es fehlt dann immernich der Code (alle Methoden, die man in dem Interface aufrufen kann), welcher die Liste verwaltet.

Die Liste müsste also in der EXE erstellt werden und alle Strings/Inhalte, dürfen nicht im Speichermanager der DLL liegen.
> Kein String, sondern nur WideString darf im Interface verwendet werden und auch sonst nichts, was im Speichermanader der DLL landen könnte.