DLL wegen RTTI zu einem Package umbauen

[QuickAndDirty]

Hallo,
Ich muss ein DLL (wegen der RTTI)in ein Package umbauen und habe verschiedene Fragen.

Ist ein Package zur laufzeit ladbar?
Nach dem was ich über LoadPackage gelesen hab ist dem wohl so.
Aber wie lautet dann das Äquivalent zu getProcAddress?

Überhaupt was muss ich jetzt machen die DLL Methoden in eine
Unit Packen und diese Unit in ein Package stecken?

Kann ich ein Package getrennt von der Anwendung weitergeben?

Eigentlich brauche ich nur zu wissen wie ich das in ein Runtime-Package packe.

Hilfe!!

[Elvis]

Ein Package *ist* eine DLL, aber eine mit Metadaten, die die Delphi RTL verwerten kann.
"GetProcAddress" funktioniert dort also auch, genau wie die exports clause.

[QuickAndDirty]

Sähe das so aus

Delphi-Quellcode:

Package bla;

uses dbtables, classes, ect;

Fn1(a,v:Tdatentyp):TBla;
Begin
  Result := Rechnung1;
end;

Fn2(a,v:Tdatentyp):TBla;
Begin
  Result := Rechnung2;
end;

Fn3(a,v:Tdatentyp):TBla;
Begin
  Result := Rechnung3;
end;

exports
  Fn1,Fn2,Fn3;

Begin

end;

Und läst es sich dann auch mit
GetModuleHandle bzw. LoadLibrary zur Laufzeit laden?

Sorry, aber wenn ich hier im D7 versuche ein Package zu machen
ists einfach nur eine Include und Contains Liste. Wie mache
ich Runtime Packages?

[mkinzler]

Zitat:

Sorry, aber wenn ich hier im D7 versuche ein Package zu machen
ists einfach nur eine Include und Contains Liste. Wie mache
ich Runtime Packages?

In dem du das Package compilierst.

[QuickAndDirty]

mkMinzler, in meinem Package ist ja keine Function enthalten
die sich exportieren ließe. ich kann da nur units und weiter packages
hinzufügen. was soll ich damit schon anfangen?

kann mich mal bitte jemand mit nem Beipiel von einem Package bewerfen
das eine Funktion exportiert.

[jbg]

Zitat:

Zitat von QuickAndDirty

was soll ich damit schon anfangen?

Na eine Unit hinzufügen.

Zitat:

kann mich mal bitte jemand mit nem Beipiel von einem Package bewerfen
das eine Funktion exportiert.

Packages exportieren ganze Units und nicht nur einzelene Funktionen. Der Export einer Unit wird über das hinzufügen der Unit in die contains-Klausel des Packages erzieht. Der Import geht dann über die einfache Nutzung der Unit in der EXE-Datei (oder anderen Packages). Dafür musst du aber das Package bei der EXE unter "Projektoptionen/Packages - Mit Runtimepackages kompilieren" hinzufügen.

[mkinzler]

Zitat:

Der Import geht dann über die einfache Nutzung der Unit in der EXE-Datei (oder anderen Packages). Dafür musst du aber das Package bei der EXE unter "Projektoptionen/Packages - Mit Runtimepackages kompilieren" hinzufügen.

Oder durch Laden der Libraray wie bei einer Dll.

[jbg]

Zitat:

Zitat von mkinzler

Oder durch Laden der Libraray wie bei einer Dll.

Dann brauchst du aber ein weiteres Package (mit Units), über das du dann die Kommunikation regelst, außer du nutzt das BPL wie eine DLL (wobei die exports-Anweisung in eine Unit verlager werden muss).

[QuickAndDirty]

Zitat:

Oder durch Laden der Libraray wie bei einer Dll.

Genau so muss ich es haben.
Nur wie mache ich dem Package klar das es bestimmte Funktionen veröffentlichen soll?

Soll ich meine DLL Funktionen in eine Unit packen. Die Köpfe ins Interface und fertig?
Oder noch eienen Exports teil dazu?

Sorry ich weiß das sich die fragen selten blöd anhören aber ich habe bisher immer nur Packages
für Komponenten gebastelt die direkt mit in die Anwendung kompiliert wurden.
Naja und jetzt bin ich dabei alle BDE Bezüge aus unserer Anwendung zu entfernen. Dafür habe ich mir
eigene TDatasets geschrieben die die Datenbank Virtualisieren. So bracht man quasi nur ein neues DLL
Schreiben um die Datebank zu wechseln, das ging auch gut. Doch leider ließ sich das RTTI Probelm
irgendwann nicht mehr umgehen(sonst half immer in temporäres objekt kopieren).

Und jetzt steh ich da mit ner DLL (bestimmt über Hundert Funktionen) auf der einen Seite und fertigen Wraperklassen
auf der anderen Seite. Und hätte eigentlich ein Package gebraucht. :(

Zitat:

außer du nutzt das BPL wie eine DLL (wobei die exports-Anweisung in eine Unit verlager werden muss).

Gehört Exports bei Packages in die Unit mit den Funktionen? In den Interface oder implemantation Teil?

[jbg]

Zitat:

Zitat von QuickAndDirty

Nur wie mache ich dem Package klar das es bestimmte Funktionen veröffentlichen soll?

Ich zitiere mich mal selbst (wie so des öfteren)

Zitat:

wobei die exports-Anweisung in eine Unit verlager werden muss

[jbg]

Ach ja und das Problem mit der RTTI könntest du auch dadurch lösen, dass die EXE sowie deine DLLs alle "Mit Runtime-Pckages kompilieren" aktiv haben und dort "rtl;vcl" eingetragen ist. Ggf. auch noch vcldb dazu.

[QuickAndDirty]

Zitat:

Zitat von jbg

Ach ja und das Problem mit der RTTI könntest du auch dadurch lösen, dass die EXE sowie deine DLLs alle "Mit Runtime-Pckages kompilieren" aktiv haben und dort "rtl;vcl" eingetragen ist. Ggf. auch noch vcldb dazu.

Du scherzt . Das wäre viel zu einfach. *Hoffnung*
Du meinst da problem wenn er meldet "Tstringlist ist nicht vom Typ Tstringlist" *g*
das würde sich dann erübrigen?
Ok, die Sache könnte ich zwar nicht entscheiden aber es wäre eine weiter Option.

Du meinst also ich könnte ein package mit nur einer Unit mit meinen Funktionen und nem Exportteil
machen und das ganze dann ohne Änderung auf der Anwendungsseite benutzen?

[QuickAndDirty]

Danke an alle
Diese Beispiel scheint zu funktionieren

nochmals Danke!

Das Package

Delphi-Quellcode:

package Test;

{$R *.res}
{$ALIGN 8}
{$ASSERTIONS OFF}
{$BOOLEVAL OFF}
{$DEBUGINFO ON}
{$EXTENDEDSYNTAX ON}
{$IMPORTEDDATA ON}
{$IOCHECKS ON}
{$LOCALSYMBOLS ON}
{$LONGSTRINGS ON}
{$OPENSTRINGS ON}
{$OPTIMIZATION OFF}
{$OVERFLOWCHECKS ON}
{$RANGECHECKS ON}
{$REFERENCEINFO OFF}
{$SAFEDIVIDE OFF}
{$STACKFRAMES OFF}
{$TYPEDADDRESS OFF}
{$VARSTRINGCHECKS ON}
{$WRITEABLECONST ON}
{$MINENUMSIZE 1}
{$IMAGEBASE $400000}
{$IMPLICITBUILD OFF}

requires
  vcl,
  rtl;

contains
  TESTLIB in 'TESTLIB.pas';

end.

Unit des Packages

Delphi-Quellcode:

unit TESTLIB;

interface

uses dialogs;

Procedure LoadLib;

exports  LoadLib;

implementation

Procedure LoadLib;
Begin
  Showmessage('*Schnips*');
end;

end.

Die Anwendung

Delphi-Quellcode:

unit Testformular;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

TTestProc = Procedure;

var
  Form1: TForm1;
  Alib:Thandle;
  aMethod:TTestProc;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var p:Pointer;
begin
  alib := 0;
  alib := LoadPackage(Pchar('Test.bpl'));
  If alib<>0 then
  Begin
    p := nil;
    p := GetProcAddress(alib,PChar('LoadLib'));
    if p <> nil then
    Begin
      @AMethod := p;
      AMethod;
    end;
    UnloadPackage(alib);
  end;
end;

end.

[jbg]

Zitat:

Zitat von QuickAndDirty

Du scherzt . Das wäre viel zu einfach. *Hoffnung*

Nein, ich scherze nicht. So mache ich das auch bei DelphiSpeedUp und DDevExtensions (beides DLLs, die gegen vcl.bpl und rtl.bpl gelinkt sind)

[QuickAndDirty]

Alles Umsonst sorry.
Aber eine BPL war nicht die lösung für das problem.
denn Ich brauche in der DLL (oder bpl) und in der Anwendung
unterschiedlich kompilierte Units und packages.
Das kann ich nur mit einer DLL haben.
Eine andere lösung wär COM aber
1. ist das Projekt schon zu weit fortgeschritten um jetzt noch com zu machen und
2. ist com nicht gerade performant.

Werde jetzt DLL Seitig auch mit eigenen TDatasets arbeiten welches ohne
assign, is, as funktionieren.
(den Großteil kann man ja aus der DBTables(oder DbISAMTables) übernehmen)

[testra]

:?: Wie mache ich es, wenn ich alle units in packages gesteckt habe und von der exe datei aus jedoch nur bestimmte objekte aus einigen packages aufrufen will? :?:

[Gruber_Hans_12345]

Zitat:

Zitat von jbg (Beitrag 516092)

Zitat:

Zitat von QuickAndDirty

Du scherzt . Das wäre viel zu einfach. *Hoffnung*

Nein, ich scherze nicht. So mache ich das auch bei DelphiSpeedUp und DDevExtensions (beides DLLs, die gegen vcl.bpl und rtl.bpl gelinkt sind)

Hallo, bin gerade daruf gestossen

schaffe ich es auch damit (wenn ich EXE und DLL mit rtl und vcl packages compiliere), das ich in einer "normalen" DLL eine Objekt samt RTTI erzeuge, dieses Objekt dann in ner Funktion der EXE gebe und die EXE kann dann per RTTI auf die properties zugreifen?

Oder hab ich dieses Aussage falsch verstanden?

[Sir Rufo]

Wenn alles mit Runtime-Packages und alles mit dem absolut gleichen Kompiler erzeugt wurde, dann ja.

Dann kannst du aber auch gleich ein Package anstatt einer DLL verwenden.

[mkinzler]

Man sollte nie Objekte im Interface einer Dll verwenden. Für diesen Zweck wurden die Bpls entwickelt (technisch handelt es sich ja um Dlls, mit erweitertem Interface)

[Gruber_Hans_12345]

Ich habe bei den BPL's Angst, das wenn sich viel in der EXE tut ich jedesmal die BPL's erneut erzeugen muss

Der Kompiler würde eh immer gleich sein/bleiben ...

Nur muss ich eben von 2-3 Stellen dynamisch diese Objekte erzeugen und dynamisch auf RTTI Properties zugreifen können

[Sir Rufo]

Und bei einer DLL wäre das anders? :roll:

[Gruber_Hans_12345]

Hmmmmm... ich hatte halt die Hoffnung ;)

Wenn ich nun eine DLL habe die hat ja dein ihre eigene RTTI.

Sagen wir in der DLL habe ich folgendes Objekt.

Delphi-Quellcode:

type TMeinDLLObject = class
published
  Lines : TStringList;
  Text : string;
end;

in der EXE habe ich nun ein Objekt : TMeinDLLObjekt

Kann ich nun in der EXE rausfinden, das das Objekt eine RTTI hat die nicht in der EXE zu finden ist?
Und es sind dann AUTOMATISCH alle properties (in dem Fall Lines : TStringList) auch in der RTTI der DLL zu finden oder?

Bzw grob gesagt alles was in der DLL mit .Create erzeugt wird hat die RTTI in der EXE und umgekehrt oder?

[mkinzler]

Warum sollte das notwendig sein? (Neuerzeugung BPL, wenn Exe sich ändert)

[himitsu]

Rausfinden ob ein Objekt (dessen Klasse) in der RTTI der EXE ist, lässt sich leicht.
Du fragst einfach nach der RTTI zu dieser Klasse und es wird natürlich Keine gefunden.

Aber nur weil die Klassen in beiden Modulen (EXE/DLL) die gleiche/selbe Deklaration haben, müssen die Instanzen und die RTTI nicht kompatibel sein.

Beispiel:
In der EXE wird auf ein Feld/Methode nicht zugegriffen, also lässt der Compiler das weg und schon ist alles Nachfolgende verschoben.
Die Offsets zu den nachfolgenden Feldern/Variablen/VirtuellenMethoden stimmen nicht mehr überein und die Zugriffe gehen auf falsche Adressen.

Zitat:

Warum sollte das notwendig sein? (Neuerzeugung BPL, wenn Exe sich ändert)

Garnicht.

Da die EXE sich auf die BPL bezieht, braucht man nichts machen, wenn man an der EXE etwas ändert.
Ändert sich was an der BPL, dann muß man auch nicht sofort die EXE neu kompilieren, solange sich keine öffentlichen/geteilten Schnittstellen ändern.
Und wenn sich Schnittstellen ändern,dann muß man sowohl EXE, als auch BPL neu kompileren, aber mit dem Unterschied, daß bei der BPL ein Fehler geworfen wird, sobald die Schnittstellen nich zusammenpassen, was bei der DLL nicht passiert und man sich somit mit der DLL schöne Laufzeitfehler einfangen kann.

[Gruber_Hans_12345]

Zitat:

Zitat von mkinzler (Beitrag 1275669)

Warum sollte das notwendig sein? (Neuerzeugung BPL, wenn Exe sich ändert)

Weil ich es so rausgelesen haben prinzipielle....

Zitat:

When you want to update your DLL (change some function's implementation), you simply compile it, export some new routines and ship the new version. All the applications using this DLL will still work (unless, of course, you've removed existing exported routines). On the other hand, when updating a package, you cannot ship a new version of that package without also updating the executable

[mkinzler]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1275671)

Zitat:

Zitat von mkinzler (Beitrag 1275669)

Warum sollte das notwendig sein? (Neuerzeugung BPL, wenn Exe sich ändert)

Weil ich es so rausgelesen haben prinzipielle....

Zitat:

When you want to update your DLL (change some function's implementation), you simply compile it, export some new routines and ship the new version. All the applications using this DLL will still work (unless, of course, you've removed existing exported routines). On the other hand, when updating a package, you cannot ship a new version of that package without also updating the executable

Das hat nicht mit Dll/Bpl zu tun, sondern mit den Abhängigkeiten, welche man durch den Austausch von Objekten eingeht. Das Problem, das hier angesprochen wird hat auch nicht mit Änderungen der Dll sondern mit Änderungen der Standard-Bpls (VCL/RTL) und den Änderungen des Compilers zu tun. Beschränkt man sich auf einfache/eigene Objekte sollte eine Bpl genauso problemlos wie Dlls unabhängig von Exe entwickelt werden können.

[Gruber_Hans_12345]

Ok Danke

Dann werde ich das morgen mal probieren, ob es in meinem Fall so funktioniert wie ich es mir wünsche ... :D

[edit]Würde das dann auch funktionieren, wenn mit dem SELBEN Compiler auf zwei verchiedenen Rechner das ganze mache?
Also auf einem REchner spriche einem Delphi 2007 erzeuge ich die EXE und auf einem anderen Rechner auch mit Delphi 2007 dann die BPL dazu?
Oder würde es da dann krachen?[/edit]

[mkinzler]

Ja funktioniert. Mit verschieden Compiler meinte ich verschiedene Delphiversionen.
Wenn auf den 2 Rechner die selbe Version (inkl. Patchstand) installiert ist, funktioniert das. Sonst würden die ganzen 3rd-Party Komponenten/Plugins, welche nur als Bpl kommen auch nicht funkionieren.

[Gruber_Hans_12345]

Ok danke

So hab noch mal einiges gelesen ....

Also wenn ich meine BPL schreibe, und ich WILL ja KEINE NEUE EXE machen müssen wenn ich die BPL aktualisiere.

Darf ich nichts in der interface section ändern, also alle Änderungen in der implemenation Section sind tabu

Stimmt das so? Oder darf ich gewisse änderungen in der interface section machen?
zB.: private variablen in eine Klasse hinzufügen oder gewissen funktionen/procedure dazu?

Also welche Änderungen darf ich in einer unit machen ohne das sich die Version der Package ändert?

Was passiert mit units die ich per uses in die BPL einbinde?
Hat dazu noch wer interne infos?

[mkinzler]

Zitat:

Darf ich nichts in der interface section ändern, also alle Änderungen in der implemenation Section sind tabu

Was hat die implementation Section mit dem Interface zu tun?
Dort darfst Du so viel verändern wie Du willst.
Im Interface darfst Du nichts entfernen oder funktional verändern; erweitern kannst Du.

Eine Bpl ist eine Dll, mit der zusätzlichen Möglichkeit komplexere (Objekt-)typen im Interface zu verwenden.

[Gruber_Hans_12345]

Zitat:

Zitat von mkinzler (Beitrag 1275679)

Zitat:

Darf ich nichts in der interface section ändern, also alle Änderungen in der implemenation Section sind tabu

Was hat die implementation Section mit dem Interface zu tun?
Dort darfst Du so viel verändern wie Du willst.
Im Interface darfst Du nichts entfernen oder funktional verändern; erweitern kannst Du.

Eine Bpl ist eine Dll, mit der zusätzlichen Möglichkeit komplexere (Objekt-)typen im Interface zu verwenden.

ah sorry meinte natürlich interface

... Aber was meinst du mit "erweitern kannst du" ?

den published properties werde ich ja nichthinzufügen dürfen vermute ich mal oder?
Das ich nichts entfernen kann/darf, das ist kein Problem, aber eben neue Sachen hinzufügen ... da habe ich noch wenig infos dazu gefunden.