[Techno-Demo]Von Dll auf VCL-Objekte der Anwendung zugreifen

[chaosben]

Oft gibt es ja Diskussionen darüber, warum man von einer DLL nicht auf die Komponenten des aufrufenden Programms zugreifen kann. Das Ganze wurde hier auch schon erklärt.

Wir haben nun eine Art "Framework" geschrieben um Objekte aus der Hauptanwendung in die DLL (und umgedreht) zu exportieren. Innerhalb der DLL kann man fast alle windigen und nicht-windigen Sachen mit den importierten Objekten machen.
Aber es gibt auch die folgende Einschränkung: Wenn eine Eigenschaft/ein Objekt selbstständig Speicher allociert, kann es sein, das beim Beenden der Anwendung Zugrifssverletzungen entstehen. Die betrifft zum Beispiel die Font-Eigenschaft. Das bedeutet, das man diese Eigenschaften einfach ignorieren soll.
Wichtig ist auch, dass innerhalb der DLL allocierte Strings (auch durch einfache Zuweisung) am Ende (finalization) freigegeben/auf '' gesetzt werden. Aber seht euch einfach die Sourcen der Demo an und probiert ein wenig herum. (Und in der Demo einfach mal auf die Hints schauen. )

Liste der möglichen Fallstricke:

• DLL und Programm müssen mit exakt den selben Sourcen und dem gleichen Compiler erstellt werden
• to be continued ...

[negaH]

Ich empfehle dieses Beispiel eines hacks nicht in Produktivcode zu benutzen.
Das was man mit dieser DEMO zeigen möchte ist einfach nicht auf diese Weise machbar. Die einzigsten Lösungen sind

1.) COM Interfaces benutzen
2.) Packages benutzen

punkt.

Zb. dieser Source hier

Delphi-Quellcode:

 pInfo:=AObject.ClassInfo;

  //if we can not get any valid information exit
  if (pInfo = nil) or (pInfo^.Kind <> tkClass) then
    exit;

  //get information about the type of the class
  pType := GetTypeData(pInfo);

Falls AObject aus dem Modul A stammt und der Code im Modul B ausgeführt wird ist dieser Code einfach UNZULÄSSIG !

Mit AObject.ClassInfo wird eine Klassenmethode im Modul B aufgerufen die im Modul A steht. Sie gibt einen Zeiger zurück auf das Codesegment des Modules A. Soweit noch ok.

Nun greift man aber mit pInfo^.Kind schon aus dem Modul A in das Codesegment des Modules B zu. Dieser Zugriff ist zwar unter heutigen Windows Betriebssystemen in dem eigenen Prozess auf selber geladene Module noch fast zulässig aber im Grund eigentlich verboten ! Wäre zb. die Klasse in einer DLL wie Kernel32.dll implementiert ist es sicher das mit solchen Zugriffen eine AV auftreten wird.

Denn es ist durchaus möglich das Codesegment eines Modules vor dem Lesen durch andere Module zu schützen.

Es geht aber noch weiter mit GetTypData(pInfo); wird nun ein Code in Modul A versuchen eine Datenstruktur im Modul B auszuwerten. Dies wird aber nur funktionieren wenn Modul A und Modul B mit identischen Sourcen compiliert wurden.

Wäre zb. Modul A mit Delphi 3 kompiliert und Modul B mit Delphi 5 so ergäbe sich eine andere RTTI/Klassenstruktur in den Codesegementen. Die Funktion GetTypData() aus Modul B würde also im Codesegement des Modules A deren Klassenstrukturen und RTTIs absolut falsch auswerten. Also auch hier wieder AVs.

Es sind also gravierende Einschränkungen zu beachten die aber das Konzept der DLLs und ihrer Schnittstellenlogik zuwider laufen. Kurz gesagt: diese Methode eines Plugin Systems macht die Vorteile von DLLs wieder zunichte.

Denn bei einer DLL als Schnittstelle ist es ja der Vorteil das man diese eine saubere Schnittstelle hat bei der man die DLL zb. in BCB version 3 schreibt und diese in belieben Anwendungen die zb. in BASIC oder Delphi 5 gechrieben wurden, aufrufen kann.

Gruß Hagen

PS: heist also, das Irgendwas funktioniert und machbar ist heist noch lange nicht das es auch zulässig und sauber ist. Aus Sicht eines Protected Mode Betriebssystemes und dem Sharing von DLL's und deren Codesegemente Prozessübergreifend sind solche Tricks wie oben eben unzulässig.

Wir als Programierer müssen aber immer von reproduzierbaren und sauberen Konzepten ausgehen, damit unsere Produkte auch funktionieren. Man kann sich also über die vielen Unzulänglichkeiten eines MS Windows aufregen, aber mit solchen Konstrukten wie oben ist das dann kein Wunder.

[Elvis]

Es ist IMHO auch ziemlich witzlos eine DLL zu schreiben, die voraussetzt, dass die benutzende App mit dem gleichen Compiler kompostiert wurde.
Da sind doch Packages weitaus netter. Hier sorgt der Compiler schon dafür, dass du völlig transparent deinen Code auslagern kannst UND das die Delphi Runtime (MM, RTL, VMTs,...) ebenfalls völlig transparent geteilt wird.

[chaosben]

Morgen!

@Hagen: Du hast ja nun wortreich erklärt, das dieses Vorgehen, nur einsetzbar ist, wenn DLL und Program mit dem gleichen Compiler und den gleichen Sourcen erstellt wurde. Das ist wohl auch logisch, oder?
Außerdem schreibe ich meine DLL's sehr selten so, das sie jeder Andere benutzen kann. Zum Beispiel arbeite ich @Work gerade an unserem Versandprogramm. Die einzelnen Module sind dll's und besitzen jeweils eine eigene Datenbank-Verbindung. Mit obigem Konzept kann ich ohne Umstände (COM, ...) die DB-Verbindung des Hauptprogramms an die Module exportieren.
Und nochwas: was redest du da andauernd von zulässig? Wer außer den Entwicklern von MS-Windows und Delphi will mir sagen was zulässig ist?

Zitat von Hagen:

Das was man mit dieser DEMO zeigen möchte ist einfach nicht auf diese Weise machbar.

Falsch
Punkt! Das was ich mit dieser Demo zeige, zeige ich auch. Man sieht das es funktioniert. Und bei überlegter Programmierung und Beachtung der Grenzen, die dieser Technologie gesetzt sind, kann man das wohl im produktiven Einsatz nutzen.

Und btw.: Warum sollten bestimmte Infos nicht verfügbar sein? Ich exportiere die Daten an einer Stelle wo alle Infos da sein müssen, da das Objekt dort existiert.

PS:
Ich hoffe ich war nicht zu aggressiv. Und normalerweise bin ich ein ganz ruhiger Mensch. Aber es stinkt mich an, das da jemand daher kommt und meint, das seine Meinung oder sein Wissen mehr Wert ist, als alles andere und mit solch destruktiven Kommentaren die Arbeit anderer zerredet. Ich habe nicht gegen konstruktive Kritik um eine Sache zu verbessern. Aber dieses Bemühen kann ich hier nicht erkennen.

[MarcoWarm]

Zitat von negaH:

Dieser Zugriff ist zwar unter heutigen Windows Betriebssystemen in dem eigenen Prozess auf selber geladene Module noch fast zulässig aber im Grund eigentlich verboten !

Wie kann etwas, was im Grund eigentlich verboten ist gleichzeitig fast zulässig sein?

Meine Behauptung: Zugelassen ist alles, was Delphi, die VCL bzw. das Betriebssystem nicht unterbindet.

Zitat von BERTELSMANN Wörterbuch:

zu|las|sen -> erlauben, gestatten, dulden

Es ist richtig, daß diese Methode nicht dem eigentlichen Sinn von DLLs gerecht wird. Das wissen wir, und darüber muss man sich ja nicht streiten. Andererseits handelt es sich nur um das "herumschießen mit Pointern", etwas, was man in C++ andauernd macht, auch über DLL-Grenzen hinweg (was bleibt einem auch anderes übrig ohne Packages ) Man muss sich schon im klaren sein, was man da eigentlich tut.

[negaH]

Man sollte sich fragen WAS der Sinn einer DLL eigentlich ist.

Es ist eine Schnittstelle aus Sicht eines öffentlich sichtbarem teil, nämlich die exportierten Funktionen und deren Parameter hin zu einem punsichtbaren und privaten Bereich, nämlich der Implementation innerhalb der DLL.

Alle Tricks die hier beschrieben werden basieren darauf das diese DLL einen zeiger auf ihre internen Strukturen zurückliefern und der Benutzer der DLL damit die öffentliche Schnittstelle der DLL ausser Kraft setzen kann indem er direkt in die DLL über Zeiger zugreift.

Das ist defakto wohl offensichtlich, zum Konzept einer DLL als Schnittstelle, widersprüchlich. Das unterminiert schlichweg den Sinn einer DLL.

Packages dagegen stellen für jeden Zugriff eine eineindeutig benamte Funktion als Export zur Verfügung. Der Copmiler wieder lösst alle Zugriff auf die Packages vollständig transparent auf. Das betrifft sogar globale Variablen wie Application: TApplication aus unit Forms.pas. Auch dafür exportiert ein Package Zugrifffunkionen !!

Gruß Hagen

[qoute]
ch hoffe ich war nicht zu aggressiv. Und normalerweise bin ich ein ganz ruhiger Mensch. Aber es stinkt mich an, das da jemand daher kommt und meint, das seine Meinung oder sein Wissen mehr Wert ist, als alles andere und mit solch destruktiven Kommentaren die Arbeit anderer zerredet. Ich habe nicht gegen konstruktive Kritik um eine Sache zu verbessern. Aber dieses Bemühen kann ich hier nicht erkennen.
[/quote]

Stop mal, jetzt wirst du persönlich. Überlese bitte nochmal alle meine Kommentare und du wirst sehen das ich zu keiner zeit ausfälig geworden bin, noch behauptet hätte das mein Wissen mehr Wert wäre. Du legst mir damit Worte und Gedanken in den Mund die nur DU gegacht und gesagt hast, nicht ich.
Dies ist nämlich nur eine Bewertung die durch die Leser der DP getroffen werden kann.

Das was ich indirekt hier aber kritisiere ist dein Vorgehen hier irgendwas, was machbar ist als ultimative Lösung in den Raum zu stellen. Bedenke bitte das du damit den Glauben bei den Lesern der DP förderst das solche Tricks wie die Deinigen zulässig wären und somit Probleme in einem schlechten Konzept eines Plugin Systemes lösen könnten.

Suche hier mal in der DP die viele Threads bei denen exakt mit deiner Methode im Zusamenhang mit der VCL gearbeitet wurde und es immer wieder zu Problemen gekommen ist.

Sorry, aber ich verfolge sowas schon über 10 Jahre, denn deine Lösung ist mindestens so alt. Sie ist also nichts Neues aus meiner Sicht. Und exakt weil ich aus Erfahrung darum weis wie schlecht diese Lösung ist, habe ich versucht mit plausiblen Argumenten sie zu zerlegen.

[chaosben]

Jetzt kommen wir der Sache schon näher.

Nehmen wir als Beispiel mal einen PKW. Ja, einen Personenkraftwagen. Man sollte sich also fragen, wozu ein PKW dient. Er wurde dazu erfunden Personen mit Hilfe von krafterzeugenden Maschinen von einem Punkt A zu einem Punkt B zu befördern. Nehmen wir auch an, ich befördere mit diesem PKW Müllsäcke vom Garten zu meiner Wohnung um sie dort ordnungsgemäß zu entsorgen. Wer würde in diese, Fall zu mir sagen: Das ist defakto wohl offensichtlich, zum Konzept eines PKW als Personenbeförderungsmittel, widersprüchlich. Das unterminiert schlichweg den Sinn eines PKW.

Btw.: Ich gebe zu, das ich in meinem Leben noch nie etwas mit Packages programmiert habe. Aber, ich mein Programmier-Ausbilder, der schon einige Jahre (annährend 10) Delphi-Erfahrung auf dem Buckel hat, hat aus eigener leidvoller Erfahrung berichtet, was Packages für Ärger machen könne. Ich verspreche, ich werde eines Tages auch dieses Thema unter die Lupe nehmen.

Zitat von negaH:

Das was ich indirekt hier aber kritisiere ist dein Vorgehen hier irgendwas, was machbar ist als ultimative Lösung in den Raum zu stellen.

Wenn ich nur könnte, würde ich dir gern recht geben. Nur leider fehlt mir dafür die textliche Grundlage um solche Assoziationen aus meinem ersten Post zu entnehmen. Jede Technologie hat ihre Grenzen. Nehmen wir an, jemand würde die Indy Komponenten hier vorstellen und sagen: "... mit denen man alles machen kann". Käme ich jetzt auf die Idee, mit diesen Komponenten Brot zu backen, würde mich etwa 15.000 DP-Mitglieder schallend auslachen.

Zitat von negaH:

Überlese bitte nochmal alle meine Kommentare und du wirst sehen das ich zu keiner zeit ausfälig geworden bin, noch behauptet hätte das mein Wissen mehr Wert wäre.

Zugegeben, du bist nicht ausfallend geworden und du hast auch nie behauptet, das dein Wissen mehr wert ist. Aber was mich stört, ist das Ziel was du mit deinen Posts hier bewirken willst und was du mir freundlicherweise nun auch bestätigt hast:

Zitat von negaH:

habe ich versucht [...] sie zu zerlegen.

Und genau das, passt nicht in eine freundliche Community, dachte ich jedenfalls bisher.

[Luckie]

Ich sehe daran nichts unfreundliches, wenn jemand meinen Code kritisiert und ihn "zerlegt". Hagen hat nur andere Ansichten technischer Natur geäußert und dies auf eine sachlich Art und Weise. Führt eure persöbnliche Diskussion bitte per pN weiter und diskutiert im Forum den Code sachlich weiter.

PS: In der Regel hat ein Auto einen Kofferaum, der bestimmt nicht zur Personenbeförderung gedacht ist.

[Elvis]

Zitat von chaosben:

Außerdem schreibe ich meine DLL's sehr selten so, das sie jeder Andere benutzen kann. Zum Beispiel arbeite ich @Work gerade an unserem Versandprogramm. Die einzelnen Module sind dll's und besitzen jeweils eine eigene Datenbank-Verbindung. Mit obigem Konzept kann ich ohne Umstände (COM, ...) die DB-Verbindung des Hauptprogramms an die Module exportieren.

Hmm.. ich sehe es irgendwie immer noch nicht, warum hier DLLspraktischer als Packages sein könnten. Kannst du das mal etwas genauer erklären?

[Daniel]

Zitat von chaosben:

Und genau das, passt nicht in eine freundliche Community.

Auch das gehört zu einer Community. Deine Lösung hat einige ... sagen wir ... technische Besonderheiten, die zwingend in Deinem Beitrag erwähnt werden müssten. Die Tatsache, dass alle Bestandteile mit dem selben Compiler erstellt werden müssen, ist eine davon. Und gerade diese Anforderung weicht erheblich von dem ab, was ich sonst von DLLs kenne und gewohnt bin.

Es geht in Ordnung, so eine Lösung vorzustellen, aber unbedingt gehört eine Auflistung der möglichen Fallstricke dazu. Du selber hast auf diese Liste leider verzichtet und so hat Hagen sie eben nachgereicht.