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:

markieren

Delphi-Quellcode:

library MeineDLL;

uses
  MeineDLLUnit;

begin

end.

zusammenfalten · markieren

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:

zusammenfalten · markieren

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.

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

Aber ansonsten:

Use LoadLibraryEx Function and DONT_RESOLVE_DLL_REFERENCES parameter

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

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....

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.

Hallo,
hat den hMod einen anständigen Wert?

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).

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

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

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?