Frage zu DLL

[Luki206]

Hi,
ich habe eine kleine Frage über das Benutzen von DLL. Da ich, in den Tutorials die ich gelesen hatte, nur das einbinden einer function gesehen hatte ist jetzt meine Frage, was man mit den DLL genau noch machen kann? Weil ich hatte ein etwas älteres Programm von mir gefunden und habe jetzt vor es 'aufzuräumen'. Kann man auch in DLL ganze proceduren reinstellen die dann im Programm ausgeführt werden? Also ich meine so eine Art von proceduren die bei z.B. Labels die Caption ändern?
Danke
Luki :)

[TiGü]

Ja!

[himitsu]

Zitat:

Caption = String

Aber wenn du gewisse Dinge über die DLL-Grenzen hinweg gibst und diese auch nopch über Laufzeit der Funktion weiterbenutzt, dann mußt du den Arbeitsspeicher der DLL und der EXE verbinden.
> SharedMemory
Denn grundsätzlich nutzen erstmal beide Teile ihren eigenen Speichermanager und da String LongStrings vom Speichemanager verwaltet werden, knallt es, wenn plötzlich der falsche Speichermanager sich um den fremden Speicher kümmern soll.
> Strings, dynamische Arrays usw.

ShortString und teilweise auch PChars lassen sich dagegen problemlos übergeben.


Und wenn auch noch etwas die RTTI betreffend (z.B. Objekte) übergeben werden, dann wird es ganz lustig, da man dann auch noch die beiden RTTIs verbinden muß.
> Packages

[Luki206]

Ok danke für eure Antworten ;)
@himitsu: Ich hoffe mein Rechner explodiert dann nicht.. Oder war das einfach so eine Metapher für, das sich dann irgendetwas verabschiedet? :o

Edit: Wäre es eigentlich auch möglich gleich den ganzen 'Block' also

Delphi-Quellcode:

Label1.Caption := ('Hallo')

in eine DLL zu setzten?

[himitsu]

Der Speichermanager wirft mit Exceptions um sich, wenn er einen falschen Zeiger, der nicht ihm gehört, zum Freigeben bekommt, oder für's Ändern der Größe.

Und wenn das Programm auf einen "falschen" Typ trüft, der nicht zu seiner Umgebung gehört, dann können Adressen und gemeinsam genutzte Objekte ein schönes Chaos ergeben, was dann auch in netten Exceptions oder in netten fehlerhaften Speicherzugriffen (Buffer Overun und Co.) enden, was dann sofort oder erst später knallt, wenn der entsprechende zerschossene Speicher dann benutzt wird.

Delphi-Quellcode:

type
  TMyClass = class
    FeldA: Integer;  // liegt im Speicher am Offset +A
    FeldB: Integer;  // liegt im Speicher am Offset +B
    procedure MachWasX; virtual;  // Adresse liegt in der RTTI am Offset +X
    procedure MachWasZ; virtual;  // Adresse liegt in der RTTI am Offset +Y
  end;

Im Prinzip kann Delphi nichtbenutztes entfernen und das wird dann garnicht erst einkompilert. (auch wenn das dank der neuen RTTI nicht immer so ist ... ratet mal, warum die EXEn immer größer werden ... weil auch potentiell ungenutztes einkompiliert wird .... könnte ja sein, daß man via RTTI drauf zugreift, aber da wäre es schöner, wenn mich Delphi vorher gefragt hätte und ich ihm explizit sage, was unbedingt mit rein muß, auch wenn keine Benutzung erkannt wird)

Die EXE greift nur auf FeldB und MachWasZ zu ... der Compiler/Linker läßt FeldA und MachWasX einfach weg.
Die DLL haz zufällig alles benutzt und jetzt steht aber in der EXE das EXE.FeldB an der Speicherstelle von DLL.FeldA, sowie MachWasZ steht abeim Offset X,
womit dann die DLL auf die falschen Speicherbereiche/Adressen zugreift, wenn sie auf eine Objektinstanz zugreift, die von der EXE erstellt wurde. Und andersrum genauso.

Zitat:

Zitat von Luki206 (Beitrag 1237934)

Edit: Wäre es eigentlich auch möglich gleich den ganzen 'Block' also

Delphi-Quellcode:

Label1.Caption := ('Hallo')

in eine DLL zu setzten?

Ja, aber nur wenn man ddie Zugehörigkeiten beachtet.

[sirius]

Zitat:

Zitat von Luki206 (Beitrag 1237934)

Edit: Wäre es eigentlich auch möglich gleich den ganzen 'Block' also

Delphi-Quellcode:

Label1.Caption := ('Hallo')

in eine DLL zu setzten?

Man kann. Man muss sich dazu aber auf den Kopf stellen (sinnbildlich).

Als Tipp: Mach es nicht! Es ist nicht der Sinn solche Sachen nach außen zu verlagern. Wenn Du ein Fenster hast, dann lass es bitte in einem Programm und ändere es nur dort. Was für einen Sinn hat es denn, die Caption in der DLL zu ändern? Eigentlich keinen. Was du auslagern kannst, sind Berechnungen, Datenbanksachen. Die geben dann eine Zeichenkette zurück (achte bei der Übergabe darauf, was himi gesagt hat; aber versuche sharemem zu vermeiden) und fertig. Wenn du Grafiksachen auslagern willst z.B. als Plugin dann benutze ActiveX und stelle z.B. ein gesamtes Frame in der Bibliothek dar.

[Sir Rufo]

DLLs funktionieren auch wunderbar mit

Delphi-Quellcode:

WideString

ohne ShareMem

[himitsu]

Zitat:

Zitat von Sir Rufo (Beitrag 1237960)

DLLs funktionieren auch wunderbar mit

Delphi-Quellcode:

WideString

ohne ShareMem

ShortString geht auch Problemlos.
WideString läuft über den Speichermanager der ole32.dll oder oleauth.dll (vergess es immer), also über eine gemeinsame Ressource.

Wobei SharedMemory sich noch recht leicht einrichten lässt, da die Funktionalität direkt im FastMM verbaut ist ... man muß es nur aktivieren.


Aber Objekte über EXE-DLL-Grenzen gehen nicht (sicher),
es sei denn, man übergibt sie als Interface.

[Luki206]

Danke für eure Antworten :) Ich werde das mit dem

Delphi-Quellcode:

[Label1.Caption := ('Hallo')

in meine Anwendung setzten und nicht in die DLL ;)

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1237960)

DLLs funktionieren auch wunderbar mit

Delphi-Quellcode:

WideString

ohne ShareMem

Wenn man nicht unbedingt andere Frameworks/IDEs als Delphi/VCL verwenden will würde ich WideStrings vermeiden wenn es bei der DLL-Schnittstelle auf 100% Performance ankommt.

Widestrings sind verglichen mit den UnicodeStrings von Delphi krottenlangsam.