EXE als DLL Ersatz denkbar?

[choose]

Hi,

mit den Win32-Funktionen LoadLibrary und GetProcAddress ist es möglich, eine DLL mit ihrem (Datei-)Namen anzusprechen und exportierte Funktionen und auch sonstige Symbole in den Prozessraum zu laden. Das funktioniert gleichfalls auch mit EXE-Dateien, die ausgewählte Symbole exportieren.

Bei dem Versuch, einen Teil des Funktionsumfangs einer meiner EXE-DAteien auf diese Weise wiederverwendbar zu machen, bin ich jedoch kläglich gescheitert. Zwar wird der erwartete Code wie beschrieben eingebunden und kann uahc ausgeführt werden, anscheinend wird jedoch keiner der Initialisierungsabschnitte der kompilierten Units durchlaufen. Weil große Teile der VCL und der von mir eingesetzten Dritthersteller-Bibliotheken aber genau das erwarten, lassen sich die erfolgreich exportierten Teile nicht sinnvoll nutzen.

Hat jemand von Euch Erfahrung damit und kann mir weiterhelfen?

[jim_raynor]

VCL und DLLs vertragen sich generell nicht gut. Korrekter wäre es Packages dafür zu erstellen. Aber such mal hier im Forum nach VCL und DLL

[DelphiSourcer]

Hallo!

Weil das Thema hier grad ist, mich interessiert, wie ich aus einer .EXE Prozeduren und Funktionen exportiere. Für eine Dll ist alles klar, nämlich folgendermaßen:

Delphi-Quellcode:

library MyDll;

uses
  Unit1,Unit2...;

procedure Proc1;
begin
  Machwas;
end;

function Func1: Rückgabetyp;
begin
  Result := Berechnung;
end;

exports
  Proc1,
  Func1;

begin
end;

Wie aber mach ich das bei einer EXE. Einfach, indem ich ein Kompilieren deser DLL als EXE erzwinge, indem ich das in den Compileroptionen einstelle? Oder geht das anders, und wenn ja, wie?

das fragt

DelphiSourcer

[himitsu]

Zitat von DelphiSourcer:

... wie ich aus einer .EXE Prozeduren und Funktionen exportiere.

Du gibt einfach irgendwo (z.B. in der .dpr, oder .pas ...) die gewünschten Funktionen/Prozeduren zum export frei
Also genauso wie es in einer DLL gemacht wird ^^

Delphi-Quellcode:

exports 
  Proc1, 
  Func1;

Und ich hatte das mal vor ewigen Zeiten dafür genutzt eum eine Datei einmal als normale EXE und wenn nötig auch mal als DLL (in den Explorer integriert) zu verwenden.
Allerdings hatte ich da keine derartigen Probleme? (D4 Std)


Aber im Grunde ist es eigenltich nicht nötig innerhalb einer EXE irgendwelche Prozeduren zu exprotieren.

[choose]

Zitat von himitsu:

ich hatte das mal vor ewigen Zeiten dafür genutzt eum eine Datei einmal als normale EXE und wenn nötig auch mal als DLL (in den Explorer integriert) zu verwenden.
Allerdings hatte ich da keine derartigen Probleme? (D4 Std)

Im allgemeinen Funktioniert dieser Ansatz ja, wie beschrieben, auch bei mir fehlerlos. Problematisch wird es bei Szenarien dieser Art

Delphi-Quellcode:

var
  FReference: TObject;

function GetReference: TObject;
begin
  Result := FReference;
end;

exports
  GetReference;

initialization
  FReference := TSomeClass.Create;

finalization
  FreeAndNil(FReference);

end.

Die Prozedure GetReference kann problemlos genutzt werden und der Code wird fehlerfrei ausgeführt. Leider wird der Initialization-Block jedoch nicht ausgeführt, weshalb die Unit nicht korrekt initialisiert werden kann. In dem skizzierten Beispiel ließe sich das einfach lösen, bei diversen Units von Drittherstellern jedoch nicht mehr ohne weiteres.
Gibt es vielleicht einen speziellen Prozeduraufruf, der die sonst automatisch vorgenommenden Initialisierungen vornimmt?

[DerDan]

Oder mach doch aus deiner Exe einen ActiveX Server, dann kannst sogar mit JSCript und ähnlichem drauf zugreifen ...

mfg

DerDan

[choose]

Ein ActiveX-Server ist mir vom Deployment etwas zu aufwendig. Außerdem würde er die erwartete Schnittstelle signifikant verändern.
In meinem Szenario möchte ich Funktionalität über einfache DLLs verfügbar machen. Um die angebotene Logik zeitgleich auch über einen "Doppelklick" anbieten zu können, hatte ich an die Möglichkeit eine EXE zu verwenden gedacht. Ein Algorithmus zum Errechnen, der über eine exportierte Funktion angeboten wird, könnte in der EXE um ein mini-GUI angereichert werden, um die Funktion auch ohne Host-Anwendung nutzen zu können.

Alternativ könnte man eine leichtgewichtige EXE nehmen, deren Funktionalität vollständig auf der DLL basiert, dann jedoch müsste die Schnittstelle der DLL (die Menge der exportierten Funktionen) ggf. erweitert werden, was ich nicht unbedingt möchte. Außerdem ist dieser Ansatz abermals aufwendiger bei der Verteilung.

Eigentlich scheitert der Ansatz nur an der fehlenden Möglichkeit, die Units der EXE zu initialisieren, sobald sie als "DLL" verwendet wird. Das muss doch aber irgendwie gehen

[NicoDE]

1) Die EPs von Dlls (3 Parameter) sind nicht mit denen von EXEs (4 Parameter) kompatibel.

2) Der Compiler/Linker generiert ja nach Projektart anderen Code (falls du die RTL-Sourcen hast, such in der SysInit.pas nach _InitExe und _InitLib und deren Referenzen).

[Ghostwalker]

Warum baust du nicht einfach 2 Zusätzliche Funktionen und exportierst sie mit. Diese können das initialisieren bzw. abschließen übernehmen.

Beispiel:

Delphi-Quellcode:

      var
  FReference: TObject;

  function GetReference: TObject;
  begin
    Result := FReference;
  end;
 
   procedure Init;
   begin
     //Wichtig zum Schutz vor mehrfach Initialisierung 
     if (freference = NIL) then
        fReference := TSomeClose.create;
   end; 

   procedure Done;
   begin
     if (frefrenece <> NIL) then
        freeandnil(freference);
   end;

exports
  GetReference,
  init,
  done;

initialization
  init;

finalization
  done;

Bei Komponenten von Drittherstellern, brauchst du natürlich dafür den source.

[choose]

Hi,

Ghostwalker, bei Deinem Ansatz muss ich jede Unit so ausstatten. Sehr lästig, weil ich insbesondere die Reihenfolgen ihrer Aufrufe beachten muss...

Zitat von NicoDE:

1)Der Compiler/Linker generiert ja nach Projektart anderen Code (falls du die RTL-Sourcen hast, such in der SysInit.pas nach _InitExe und _InitLib und deren Referenzen).

Das war auch mein Ansatzpunkt, dort konnte ich aber leider nicht den Code wiederfinden, der die Units initialisiert. Hast Du einen Ansatz?