Exportierte Funktion aus Exe mit GetProcAddress

[Neutral General]

Hallo,

Der Titel ist etwas unklar glaube ich daher eine Erklärung:
Ich habe eine Programm, das dynamisch per LoadLibrary eine DLL lädt.
Jetzt möchte ich aus der DLL heraus eine von der EXE exportierte Funktion aufrufen (quasi "falsch rum").
Das müsste doch möglich sein oder nicht?

Code sieht ca. so aus:

Delphi-Quellcode:

library MeineDLL;

uses
  MeineDLLUnit;

begin

end.

Delphi-Quellcode:

unit MeineDLLUnit;

interface

function GetModuleHandleW(lpModuleName: PChar): Cardinal; stdcall; external 'kernel32.dll';
function GetProcAddress(hModule: Cardinal; lProcName: PChar): Pointer; stdcall; external 'kernel32.dll';

implementation

var
  hMod: Cardinal;
  DemoFunc: function: Integer;
  dummy: Integer;

initialization
  hMod := GetModuleHandleW(nil);
  DemoFunc := GetProcAddress(hMod, 'Demo');
  dummy := DemoFunc();

end.

Hier noch ein kleiner Ausschnitt aus der exe:

Delphi-Quellcode:

program MeineExe;

function Demo: Integer;
begin
  Result := 1234;
end;

exports
  Demo;

begin
  // ...
  LoadLibrary('MeineDLL.dll'); // Absoluter Pseudocode
  // ...
end.

Ich bekomme von GetProcAddress aber immer nil zurück.
Habe debugged und GetModuleHandleW liefert den richtigen Wert zurück. Aber GetProcAddress schlägt dann fehl mit GetLastError = ERROR_PROC_NOT_FOUND :(
Der PE Explorer findet die "Demo" Funktion in der exe.

[Fritzew]

Ich bin mir nicht sicher ob Delphi aus einer Exe wirklich exportiert.........

Aber ansonsten:

Use LoadLibraryEx Function and DONT_RESOLVE_DLL_REFERENCES parameter

[Neutral General]

Wie schon oben reineditiert: (siehe Anhang)

Mit LoadLibraryEx + DONT_RESOLVE_DLL_REFERENCES wird die DLL gar nicht initialisiert. (Mein Code wird gar nicht ausgeführt).
Das ist auch nicht Sinn der Sache :mrgreen:

[Fritzew]

Kann sein das ich das nicht mehr richtig im Kopf hatte.
Aber ansonsten was spricht gegen eine CallBack Function die Du als Parameter an die Dll übergibst? Das wäre wohl der "normale" Weg....

[TiGü]

Ja,dass geht problemlos. Morgen gerne mit Code.
Aber warum definierst du die Get... selbst? Die sind doch bestimmt in Winapi.Windows schon drin.
Die Module-Handles mit Cardinal zu definieren ist jedenfalls so unschön/fehleranfällig/der direkte Weg in die Hölle unter 64-Bit.

[hoika]

Hallo,
hat den hMod einen anständigen Wert?

[Neutral General]

Ein Callback wäre zu spät. Ich muss diesen Aufruf so früh wie möglich machen - am besten bevor irgendwer/irgendwas Speicher über den MemoryManager reserviert. Deswegen ist das die erste Unit in meinen uses in der DLL und deswegen definiere ich GetProcAddress etc selbst um möglichst keine Abhängigkeiten zu haben, die vor meiner Unit initialisiert werden.

@hoika: Ja, wie ich schon in meinem Ausgangspost geschrieben habe, hat hMod einen gültigen Wert ($400000).

[Fritzew]

Hallo

Zitat:

Ich muss diesen Aufruf so früh wie möglich machen - am besten bevor irgendwer/irgendwas Speicher über den MemoryManager reserviert.

Ich denke den Ansatz solltest Du noch einmal überdenken.
Du versuchst das beim laden der Dll zu lösen. Dein Code wird also in der DLL-Main ausgeführt.

Aus der MSDN:
https://docs.microsoft.com/en-us/win...best-practices

Zitat:

You should never perform the following tasks from within DllMain:
Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.

Mein Ansatz wäre das in eine function der DLL mit einem Callback auszuführen.
Ansonsten bist Du immer abhaängig vom DLL-Loader und da hast Du keinerlei Einfluss

[Neutral General]

Das habe ich gelesen, aber ich benutze weder LoadLibrary noch LoadLibraryEx.

[Fritzew]

Tja, für mich fällt das in die selbe Gruppe.
Du hast keinerlei Einfluss auf den LadeProcess. Deine Dll ist in der DLLMain.
Möglicherweise kannst Du es irgendwie umgehen im Moment. Beim nächsten Windows - Update kommt eine Änderung von Microsoft und peng......

Kannst Du uns mal erleuchten was Du eigentlich erreichen willst?

[Fritzew]

Hier mal ein kleiner Test

eigentlich müsste 2 mal eine messagebox kommen.
Schau es Dir mal im Debugger an.....

[Neutral General]

Habs hinbekommen.
Auch wenn das in der Windows Unit auf den ersten Blick so aussieht:

Delphi-Quellcode:

// Winapi.Windows
function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; stdcall; overload;
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC; stdcall; overload;

GetProcAddress gibt es (original) nicht im WideString-Format:

Delphi-Quellcode:

// Winapi.Windows
function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; external kernel32 name 'GetProcAddress';
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC;
begin
  if ULONG_PTR(lpProcName) shr 16 = 0 then // IS_INTRESOURCE
    Result := GetProcAddress(hModule, LPCSTR(lpProcName))
  else
    Result := GetProcAddress(hModule, LPCSTR(TMarshal.AsAnsi(lpProcName)));
end;

Musste also meine eigene Definition von PChar auf PAnsiChar ändern und jetzt klappt es.

[Zacherl]

Du solltest darauf achten, dass eine .reloc Section für deine .exe generiert wird, sonst bekommst du Probleme, wenn Adresse 00400000 schon belegt ist.

[Neutral General]

Wieso? Ich gehe doch nicht hartkodiert auf $400000.
GetModuleHandle(nil) sollte mir doch die Basisadresse der exe liefern egal wo sie liegt oder nicht?

[Zacherl]

Achso nevermind, du lädst die .exe ja gar nicht selbst. Passt schon :P