Ich habe für mein aktuelles Projekt eine Frage: Kann ich aus einer DLL, die ich dynamisch einbinde heraus wiederum Funktionen aus meinem aufrufendem Programm verwenden? D.h. ich habe ein Programm test.exe und eine DLL test.dll. Nun lade ich in test.exe die test.dll, rufe in test.dll eine Funktion auf und diese Funktion wiederum ruft eine (oder mehrere) Funktionen aus test.exe auf.

Das sowas geht stelle ich ausser Frage, meine Frage ist nur wie? Wie kriege ich die Adressen für die Funktionen aus test.exe in test.dll heraus, bzw. gibt es auch eine einfachere Möglichkeit?

Hat da jemand eine Idee oder Erfahrung??

Vielen Dank!

~code_pilot

-exportier ein paar funktionen aus der exe wie dus auch aus der dll machst
-übergeb die adressen der funktionen als parameter von der exe an die dll

könnte funktionieren... warum auch immer man sowas machen sollte

und sag bescheid obs klappt

probiers mal damit in der dll: http://msdn2.microsoft.com/en-us/library/ms683199.aspx

Nichst anderes gescheiht mit Fensterfunktionen. Hier wird der Zeiger aus der EXE in einer Klasse gespeichert (WndProc) und ann Windows übergeben. DIese Funktion wird dann brav aufgerufen. Das OS ist auch nichts anderes als eine gigantische DLL (mit ein bischen mehr... ).

DÜbergib an die DLL mit einer Funktion einen Zieger auf eine Funktionin der EXE.

das hab ich schon vorgeschlagen aber is das wirklich nötig?

kann man nich direkt mit GetModuleHandle und GetProcAddress arbeiten?

kann eine .EXE Funktionen exportieren?

Klar.

hustbaer schrieb:

Und kann man die dann in einer DLL importieren die in diesen Prozess geladen wird?

Wenn Du mit 'diesem Prozess' den Prozess der .exe meinst, in dem die eigentlichen Funktionen liegen, ja sollte möglich sein. BTW: Mit importieren, meinst Du aufrufen bzw. mit der Funktionsadresse 'arbeiten', oder?

hustbaer schrieb:

Und wenn ja, geht das nur dynamisch oder auch statisch?

Denke statisch geht das nicht, da ich nicht wüsste wie man ne Exe statisch linken soll. Hab sowas allerdings auch noch nicht gemacht .

Jetzt eine (kleine) Frage: Wozu sowas ?

Mit Sicherheit kann der Lader keine EXE in den aktuellen Prozess laden in der bereits eine EXE läuft. Die Mechanismen die das erlauben wie DllMain fehlen dieser ja.

Aber ich sehe auch keinen großenSinn.
Ich sehe nicht mal einen Sinn für GetProcAddress, wen die Exe selber Callbacks in der DLL definieren kann.

Mit Sicherheit kann der Lader keine EXE in den aktuellen Prozess laden in der bereits eine EXE läuft. Die Mechanismen die das erlauben wie DllMain fehlen dieser ja.

was redest du denn da? was meinst du damit?

Martin Richter schrieb:

Mit Sicherheit kann der Lader keine EXE in den aktuellen Prozess laden in der bereits eine EXE läuft. Die Mechanismen die das erlauben wie DllMain fehlen dieser ja.

was redest du denn da? was meinst du damit?

Dein Ton gefällt mir nicht.

Es kommt nicht auf die Basisadresse an.
Das Problem ist, dass das Laden einer DLL etweas anderes ist als das Laden eines Prozesses.
Bei einem Prozess wird ein neuer Thread gestartet, dieser erhält die Kontrolle und führt dann den Code aus, der durch den Linker als Einsprungspunkt definiert wurde.

Was soll denn bitte passieren, wenn man LoadLibrary auf eine EXE ausführt? Eine DllMain hat er natürlich nicht. Wer sollte die Initialisierung durchführen, sollte einer zusätzlicher Thread gestartet werden..., wer kontrolliert diesen...

Eine Exe kann als Ressource in den aktuellen/bestehenden Prozess geladen werden (LoadLibraryEx LOAD_LIBRARY_AS_IMAGE_RESOURCE), aber nicht als ausführbarer Code...

Eine Exe kann als Ressource in den aktuellen/bestehenden Prozess geladen werden (LoadLibraryEx LOAD_LIBRARY_AS_IMAGE_RESOURCE), aber nicht als ausführbarer Code...

andererseits ist die exe bereits einmal im prozess geladen, da die dll ja durch die exe geladen wurde.

d.h. es könnte ja durchaus sein, dass bereits ein handle auf die exe im prozess vorhanden ist, das bloß noch geholt und mittels getprocadress benutzt werden kann.

werd ich heut abend mal ausprobiern

schwieriger wirds natürlich wenn wir von zwei verschiedenen exe dateien reden.
da kommt dann die von martin angesprochene problematik ins spiel.

allerdings verstehe ich nicht was dllmain mit der ladefähigkeit zu tun hat.
dllmain ist doch vollkommen optional

Wenn es um die selbe EXE geht, müsste es gehen!
Wenn es um eine andere EXE geht, kannn es nicht gehen!

die frage ist im prinzip nur wie windows das problem löst oder eben nicht löst

das laden einer exe ist aber eigentlich gleichbedeutend mit dem starten eines neuen prozesses wohingegen das laden einer dll nie einen neuen prozess erzeugt.
das ist die theoretische problematik.

die frage ist im prinzip nur wie windows das problem löst oder eben nicht löst

Das ist gar nicht das selbe. Und es ist auch nicht dasselbe Problem.
Du verwendest nur das selbe Wort: "Laden"!

Windows verwendet einmal CreateProcess und einmal LoadLibrary!
Die Funktionsweisen sind komplett unterschiedlich.

bei einer exe müssen halt zusätzlich noch verwaltungsinformationen für einen neuen prozess angelegt werden

Windows verwendet einmal CreateProcess und einmal LoadLibrary!
Die Funktionsweisen sind komplett unterschiedlich.

Also das glaube ich nämlich garnicht. Es sind beides bloss PE Images. Die werden in den Speicher geladen, dann werden weitere Dependencies aufgelöst wodurch evtl. weitere PE Images geladen werden etc.

Der einzige Unterschied ist IMO dass beim Starten einer .EXE vorher ein "leerer" Prozess angelegt wird, und beim nachladen von Dependencies eben diese in den "aktuellen" Prozess geladen werden.

Davon abgesehen habe ich schon diese Situation gemeint:

A.EXE importiert (statisch) X@B.DLL
B.DLL importiert (statisch) Y@A.EXE

Dise Abhängigkeit, die Du aufzeigst müsste gelöst werden können.

Was in keinem Fall geht:
Prozess X lädt statisch oder dynamisch die B.DLL, denn diese benötigt A.EXE!