Frage zu DLL/Gegenseitige Bereitstellung von Funktionen
-
Hallo alleseits!
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
-
Ich glaub das geht gar nicht
Soweit ich weiß, können (zur Laufzeit) nur DLLs ausführbaren Code anbieten..
-
exe dateien können auch funktionen exportieren... die frage is halt ob sich die funktionen aufrufen lassen
ich hab das zwar noch nie versucht aber probiers mal so-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 dllkönnte funktionieren... warum auch immer man sowas machen sollte
und sag bescheid obs klappt
-
na klar kann exe auch funktion exportieren. exe und dll sind genau das gleiche, nur ein paar andere flags im pe header
-
mir is noch was eingefallen
probiers mal damit in der dll: http://msdn2.microsoft.com/en-us/library/ms683199.aspx
-
Das ist sicherlich möglich. Callbacks sind ja nichts anders
Übergib an die DLL mit einer Funktion einen Zieger auf eine Funktionin der EXE. Die DLL kann nun diese Funktion aufrufen.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...
).
-
Martin Richter schrieb:
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?
-
Mal ne ganz doofe Frage (bzw. mehrere): kann eine .EXE Funktionen exportieren?
Und kann man die dann in einer DLL importieren die in diesen Prozess geladen wird?
Und wenn ja, geht das nur dynamisch oder auch statisch?
-
hustbaer schrieb:
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
?
-
Es ist möglich über eine DEF Datei Funktionen zu exportieren.
Ich denke es müsste sogar möglich sein statisch zu linken, sofern die EXE Datei bereits im Prozess geladen ist. Eine Lib-Datei zu erzeugen ist ja nur eine zusätzliche Linker Funktion.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.
-
Ist auch mehr eine theoretische Frage. Mich interessiert halt was möglich ist
-
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?
-
wenn die exe ne andere base adresse als die exe vom prozess hat, wieso soll er die ned laden können? oder was meinst du jetzt.
-
noobi schrieb:
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...
-
Martin Richter schrieb:
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
-
Nicht jetzt alles durcheinanderwerfen...
Wenn es um die selbe EXE geht, müsste es gehen!
Wenn es um eine andere EXE geht, kannn es nicht gehen!
-
was? ich meine nur du kannst doch ne exe mit LoadLibrary laden und dann genauso code daraus ausführen lassen wie bei einer dll auch mit GetProcAddress und dem ganzen quatsch. das geht jawohl und das ist auch alles was ich meinte. was das bringen soll ist ja eine andere frage. aber ich meine doch ned einen neuen prozess zu starten, das hat doch nie jemand gesagt.
-
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
-
Sovok schrieb:
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.
-
so unterschiedlich sind sie auch wieder nicht
im wesentlichen werden nur ausführbare befehle in den arbeitsspeicher befördertbei 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
