[VC++] Exe zugleich als DLL nutzen?

[Krishty]

Hi,

Ich möchte Programmfunktionalität nicht nur alleinstehend als Exe anbieten, sondern auch über eine Schnittstelle als dynamische Bibliothek. Kann ich beides in einem Modul vereinigen, statt eine seperate DLL zu kompilieren? Wird der Linker eine DllMain() neben einer WinMain() akzeptieren? Wie wird es mit der Initialisierung statischer Daten aussehen, falls ich einfach __declspec(dllexport)-Funktionen in die Exe packe?

Gruß, Ky

[joggel]

Interessant wärs schon zu wissen ob sowas geht... aber eigentlich kannst Du doch deine Funktionen ja in eine DLL packen und deine Exe benutzt dann die Funktionen daraus.
Aber Du wirst bestimmt deine Gründe für diese Frage haben.

[Youka]

Ich kann es mir sehr schlecht vorstellen, da beim kompilieren ein Eingangspunkt für den Assemblercode gesucht wird, der bei der shared-flag DllMain() annehmen wird und ansonsten nach WinMain oder main() sucht. __declspec(dllexport) setzt ein Attribut für den Linker, daher nehme ich an, es fällt weg, wenn keine DLL verlangt wird.
Kannst ja einfach mal ausprobieren.

[dot]

Sollte eigentlich kein Problem sein, normal müsstest du die exe einfach mit LoadLibrary() etc. laden können. Die DllMain() wird vom Loader aber nicht aufgerufen werden.

[mnemonix]

Andersherum (DLL->EXE) könnte man ja eventuell über eine Batch Datei oder Verknüpfung und der rundll32 eine selbstdefinierte Einstiegsfunktion in der DLL aufrufen und dafür eine DllMain anbieten. Sollte doch funktionieren, oder?

[eXile]

Das, was ich jetzt schreibe, ist sehr vom Anwendungsfall abhängig: Warum nicht Pimpl benutzen? Man hat in der Dll eine Struktur mit einem Haufen Funktionspointer, welche zur Laufzeit von der Exe gefüllt wird. Damit kann halt die Dll einfach Funktionen aus der Exe aufrufen – und zwar genau die, die man über diesen Mechanismus freigegeben hat. Man muss sich dann natürlich über die Schnittstelle der Exe, und damit über die Funktionen, die man freigeben möchte, im Klaren sein.

Als klare Nachteile kann man halt fehlendes Inlining und dem Overhead der Dereferenzierung ausmachen. Und, dass man bei Änderungen des Interfaces die öffentlichen Headerdateien anpassen muss. Am Ende ist das auch nur bei kleinen Schnittstellen sinnvoll, da man sonst einen viel zu große Liste an öffentlichen Funktionen verwalten muss.

[dot]

Ich denk der ganze Grund für die Frage war, dass er eben genau ohne eine dll auskommen will ;)

[eXile]

Ich weiß ja nicht, ob der „Anwender“ in diesem Fall eine standalone Exe haben will, oder nur eine Dll, welche von einer anderen Exe aufgerufen wird. In meinem Beitrag war ich vom Letzteren ausgegangen.

[BeRsErKeR]

Ich möchte Programmfunktionalität nicht nur alleinstehend als Exe anbieten ...

Wie ist das zu verstehen? Ein Exe ist doch ein fertiges Programm, dass ich in der Regel nur in der Form von anderen Programmen nutze, indem ich sie aufrufe. Wenn du die "Programmfunktionalität" auch als DLL brauchst, warum dann in einem Modul? Du kannst die DLL doch einfach in der Exe nutzen. Mir erschließt sich der Sinn nicht so ganz, da DLLs doch eigentlich genau dafür gemacht wurden.

[dot]

Ja, ich würd auch eher den Weg über die DLL gehen. Aber vermutlich will er eben nur eine exe und sonst nichts haben, warum auch immer. Unüblich, aber möglich und vorgesehen.

[BeRsErKeR]

Naja unter "dynamische Bibliothek" (siehe erster Post) versteh ich allerdings eher, dass er vorhat die DLL schon beim Compilen dazu zu linken und nicht den Weg über LoadLibrary zu gehen. Und in diesem Fall macht es halt keinen Sinn, es sei denn es gibt irgendwelche anderen Gründe, die mir gerade nicht einfallen.

[dot]

Da eine so geleadene exe aber eben keinen Einsprungpunkt hat, dürfte es mit der Initialisierung Probleme geben. Die CRT wirst du in dieser exe z.B. vermutlich nicht verwenden können und Konstruktoren/Destruktoren von Objekten im static Memory werden wohl nicht aufgerufen werden.

Edit: Wo steht im ersten Post was davon dass er load-time dynamic linking benutzen will? Ich verstehe den Post so, dass er eben genau keine dll haben will. Und unter keine dll versteh ich wirklich keine dll!?

[eXile]

So, ich hab's mal getestet. TL;DR: Definitiv nein, zumindest wenn man kein delay-loading von Hand (LoadLibrary und GetProcAddress) benutzt.

Aktuelles Setting:

• intercall1: Eine Exe, welche auswählbar Funktionen entweder aus intercall2 oder aus intercall3 aufruft.
• intercall2: Eine Exe, welche Funktionen aus intercall1 aufruft.
• intercall3: Eine Dlll, welche Funktionen aus intercall1 aufruft.

Der kompilierte Quelltext von intercall1 und intercall2 ist der gleiche. Es werden keine globalen Initialisierer o.Ä. benutzt (zumindest nicht in dem von mir geschriebenen Quelltext).

Im Debug-Build: Wenn intercall1 intercall2 benutzt (d.h. Exe und Exe), stürzt das Programm ca. jedes siebte mal in ntdll.dll!_NtRaiseException@12() + 0x12 bytes mit unklarem Callstack raus. Wenn intercall1 intercall3 benutzt (d.h. Exe und Dll), läuft es (gerade über hundert mal aufgerufen, und kein Absturz) ohne Probleme.

Im Release-Build: Genau das gleiche, nur mit verständlicherem Callstack:

Code: Alles auswählen

>	ntdll.dll!_NtRaiseException@12()  + 0x12 bytes	
 	ntdll.dll!_NtRaiseException@12()  + 0x12 bytes	
 	msvcr100.dll!___set_flsgetvalue()  + 0xf bytes	
 	msvcr100.dll!___set_flsgetvalue()  + 0xf bytes	
 	msvcr100.dll!__getptd_noexit()  + 0x2a bytes	
 	msvcr100.dll!__getptd()  + 0x8 bytes	
 	msvcr100.dll!_LocaleUpdate::_LocaleUpdate()  + 0x29 bytes	
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

What the heck is going on? Ich versuch' bald mal, das Projekt hier hochzuladen, dann kann jeder sich selbst mal überzeugen. So, ich habe das Projekt jetzt fertig gemacht. Aktualisiertes Projekt weiter hinten im Thread. Anleitung:

1. intercall1 auf Debug kompilieren.
2. intercall1 auf Debug intercall2 kompilieren.
3. Ein paar mal auf F5 hauen. Manchmal schönen Absturz beobachten.
4. intercall1 auf Debug intercall3 kompilieren.
5. So oft auf F5 hauen, bis einem die Finger wund werden. Kein Absturz.
6. Das gleiche Spiel mit Release wiederholen.

[dot]

Ja du benutzt eben vermutlich die CRT, was natürlich crashen wird, da diese in der exe nie initialisiert wird...

[eXile]

Im Debug-Modus (Debug intercall2) hast du mit dieser Vermutung recht, da hat der mir ein paar __RTC_CheckEsp reinkompiliert.

Das lustige ist aber, dass im Release-Modus (Release intercall2) der Absturz mit einer Access Violation in dieser Zeile stattfindet:

Code: Alles auswählen

00CA1004  call        dword ptr [__imp_addIntegers (0CA20ACh)]  

Richtig, beim call. Und weder bei callAddIntegers noch bei addIntegers gibts in der Disassembly irgendetwas von der CRT zu sehen!

Nachtrag: Okay, es wird wohl einfach ein sehr verwandtes Problem sein, denn addIntegers ist bzgl. dieses Moduls ein Dll-Import; wann werden die Dll-Import-Funktionszeiger von einem Modul eigentlich gesetzt und wieso kann ich schon vorher Funktionen aus diesem Modul aufrufen?

[dot]

Ich hatte jetzt grad keine Muse dieses Wirrwarr zu debuggen, drum hab ich einfach eine Demo gebaut (siehe Attachment).
Kompilieren (Ergebnis geht nach /bin/), iFunction.exe auf bla.exe droppen, staunen ;)

Man muss aber eben wirklich alles abdrehen. Exceptions, RTTI, nichtmal new und delete gibts, wenn man operator new und delete nicht selbst implementiert...

[eXile]

Naja, es tut mir leid, aber leider überzeigt mich das noch nicht ganz. ;)

Ich hatte jetzt grad keine Muse dieses Wirrwarr zu debuggen

LÜGE LÜGE LÜGE ;)

Nein, die Punkte die mich noch stören sind:

• Du benutzt LoadLibrary und GetProcAddress; ich gehe über den Windows Loader
• Du hast keine zyklische Abhängigkeit drin (bla.exe → iFunction.exe), ich schon (intercall1.exe → intercall2.exe → intercall1.exe). Darum muss ich ja auch in zwei Passes linken.
• Das erklärt noch nicht, warum es bei einer Exe klappt, bei einer Dll aber nicht. Es sei denn, der Windows Loader behandelt Exes anders als Dlls.

Ich hab mein „Wirrwarr“ so umgestellt, dass alles für intercall1.exe und intercall2.exe abgedreht wird. Die intercall3.dll wird dahingegen noch mit allen C/C++/VS-Features kompiliert. Und trotzdem klappt es mit intercall2.exe nicht, mit intercall3.dll schon.

Ich werde mal einfach als nächstes Versuchen, dein Beispiel mit zyklischen Abhängigkeiten zu versehen und das vom Windows Loader (also ohne LoadLibrary/GetProcAddress) veranstalten zu lassen. Mein Bauchgefühl sagt mir nämlich gerade, dass der Fehler am Letzteren liegt; schließlich zeigt manchmal die importierte Funktionsadresse einfach auf Müll.

Habe mein aktualisiertes Beispiel mal angehängt. Dank korrekter Dependencies muss man jetzt nur noch intercall1 auf Debug, und anschließend auf Debug intercall2 kompileren. Oder halt das gleiche mit Release.

[dot]

Mein Beispiel tut imo genau das wonach der Threadersteller gefragt hat. Ich seh nich ganz wofür da zyklische Abhängigkeiten etc.!?

[eXile]

Naja im Eingangspost ist nichts davon gesagt, ob das über LoadLibrary/GetProcAddress oder den Windows-Loader geht. Und eine zyklische Abhängigkeit ist schon nützlich. Stell dir vor, in deinem Spiel, der intercall1.exe, gibt's ne tolle, hochgeheime Mathe-Bibliothek. Die öffentliche intercall2.exe ist ein kleiner Model-Loader, welcher sowohl stand-alone, wie auch von intercall1.exe als Dll benutzt werden kann. Die intercall2.exe braucht natürlich die tollen Mathe-Funktionen aus intercall1.exe zum Laden und Animieren des Models. Darum ruft die intercall2.exe Funktionen aus der intercall1.exe auf. Andererseits will die intercall2.exe auch den Modell-Loader mal einbinden (vielleicht kann dieser ein bestimmtes Dateiformat laden, was die intercall1.exe zuvor nicht konnte). Darum kann in diesem Fall sehr wohl ein Funktionsaufruf intercall1.exe → intercall2.exe → intercall1.exe stattfinden. Das ist also kein Elfenbeinproblem hier, sondern kann so tatsächlich auftreten.

Außerdem bin ich hier doch der Threadhijacker schlechthin; ich kann auch einfach meine Posts in einen anderen Beitrag auslagern, so dass ich deinem Threadersteller-Argument geschickt entgehe. ;) Mach' ich aber nicht, weil es dann hier zwei Threads zu fast der gleichen Thematik gibt. :)

Es ist einfach nur komisch, was da passiert. Der Grund warum ich diese Posts mache, ist, dass ich es nicht verstehe. Darum ist mein neugieriger Ehrgeiz geweckt, und versuche natürlich herauszufinden, was da los ist. For science!

[dot]

For science!

We do what we must, because we can ;)

Wenn ich später etwas Zeit hab werd ich mir mal anschaun was du da genau gebastelt hast. Ansonsten kann man das Thema aber denk ich abhaken, denn die Einschränkungen, die nötig sind damit das rein theoretisch überhaupt erstmal nur gehen kann, machen das für die Praxis wohl unbrauchbar. Afaik ist die so ziemlich einzige praktische Anwendung von LoadLibrary() auf einer exe, wenn man an die Ressourcen in der exe ran will.

[Krishty]

Omg. Unbequem, dass der Eingangs-Post so missverständlich war, dass ihr euch jetzt drum raufen müsst. Worum es mir ging:

• Ich habe ein Tool geschrieben, das als Exe ausgeliefert wird.
   
• Jemand dachte: Hey! Ich könnte dieses Tool echt gut für einen automatischen Prozess benutzen; am besten, indem ich eine Handvoll Funktionen von meinem eigenen Programm aus aufrufen kann, weil sich in Echtzeit Daten ändern!
   
• Ebendas möchte ich dem Menschen, der zudem auch noch in einer anderen Sprache programmiert, gern ermöglichen. Aber Bock, extra für ihn eine DLL anzulegen, zu pflegen, zu testen und auszuliefern, habe ich nicht.
   
• Darum dachte ich mir: Hey! Ich könnte das echt einfach lösen, indem ich aus meiner Exe die paar Funktionen exportiere!
   
• Libs oder sonstigen Krempel kriegt dieser Mensch nicht. Soll er ganz altbacken via LoadLibrary() und GetProcAddress() machen. Meine Motivation ist: Ich will einzig und alleinstehend die eine Exe-Datei ausliefern.
   
• Die Handvoll Funktionen, um die es geht, ist eine halbe Engine mit Direct3D und XAudio. Das und meine statischen Daten sollten also schon funktionstüchtig sein.

Das nur zur Klärung. Danke schonmal für eure Hilfe; ich bin aber leider noch nicht zum Lesen gekommen :/

[dot]

@eXile: Es ist mir irgendwie ein Rätsel wie du dein Beispiel überhaupt kompilieren kannst. In meiner momentanen, von Kausalität geplageten, Realität, seh ich zumindest grad keinen Weg. Denn intercal1 braucht intercal2.lib, intercal2 braucht aber intercal1.lib <=> Deadlock.

Ich kanns mir nur so erklären, dass du z.B. dein intercal2 mit einer Version von intercal1.lib kompiliert hast, die erstellt wurde, als intercal1 noch nicht von intercal2 abhing. Das endet aber in einem endlosen gegenseitigen Bootstrapping. Eine der beiden exen wird immer mit einer falschen lib kompiliert werden. Dass das dann hochgeht, sollte nicht verwunderlich sein.

[dot]

Krishty: Sofern du in deiner exe nicht auf die CRT verzichten kannst, wird das mit dem exportieren wohl nix.

Deiner Beschreibung nach wärs aber evtl. eine Lösung, über Pipes oder Shared Memory eine Schnittstelle zu einer laufenden Instanz deiner exe anzubieten?

[CodingCat]

@eXile: Es ist mir irgendwie ein Rätsel wie du dein Beispiel überhaupt kompilieren kannst. In meiner momentanen, von Kausalität geplageten, Realität, seh ich zumindest grad keinen Weg. Denn intercal1 braucht intercal2.lib, intercal2 braucht aber intercal1.lib <=> Deadlock.

Darum muss ich ja auch in zwei Passes linken.

Zwar ekelhaft, aber möglich. Abgesehen vom dort beschriebenen Weg sollte es tatsächlich auch möglich sein, dieses Bootstrapping zu umgehen, indem man zunächst einfach mit "veralteten" (oder gezielt kurzzeitig reduzierten) Libraries linkt.

[dot]

Stimmt -.-

Edit: Ja, ich hab mir eigentlich auch gedacht, dass es mit den veralteten libs funktionieren müsste. Aber es wär zumindest ne Erklärung. Naja, mal debuggen...

Am Loader wird es jedenfalls nicht liegen, von OS Seite ist das rein prinzipiell ganz sicher kein Problem. Zumindest würd mir kein Grund einfallen wieso es nicht funktionieren sollte.

[eXile]

Zwar ekelhaft, aber möglich. Abgesehen vom dort beschriebenen Weg sollte es tatsächlich auch möglich sein, dieses Bootstrapping zu umgehen, indem man zunächst einfach mit "veralteten" (oder gezielt kurzzeitig reduzierten) Libraries linkt.

Dank deines Links habe ich das ganze für Freunde der gepflegten Kommandozeile auch mal in eben dieser Form ausgetüftelt:

Code: Alles auswählen

cd intercall1
cl /Od /GF /GS- /GR- /Gz /c main.cpp
lib main.obj /name:"intercall1.exe" /def
cd ..
cd intercall2
cl /Od /GF /GS- /GR- /Gz /c main.cpp
lib main.obj /name:"intercall2.exe" /def
cd ..
link /out:"intercall1.exe" intercall1/main.obj intercall2/main.lib
link /out:"intercall2.exe" intercall2/main.obj intercall1/main.lib

Das Ergebnis bleibt: Manchmal stürzt die intercall1.exe ab. Die ganzen Parameter für cl.exe ändern nichts, die können auch weggelassen werden. ;)

[Chromanoid]

Nur so mal ein unbedachter Kommentar eines Unwissenden :): Müsste man nicht mit Assembler eine Einstiegsfunktion entwickeln können, die für Exe und DLL funktioniert? Die Parameter werden doch bestimmt auf dem Stack abgelegt und bevor man die alle abräumt könnte man doch vielleicht mit einer statischen Variable und dem zweiten Parameter (hPrevInstance / fdwReason) herausfinden, ob gerade DLLMain oder WinMain angesprochen wird. Dann könnte man das Zeug wieder auf den Stack Packen und an die entsprechende gewünschte "echte" winmain/dllmain weiterleiten.

[dot]

Das Problem ist nicht, dass man keinen EntryPoint haben kann. Das Problem ist, dass der Loader diesen bei einer exe natürlich nicht aufruft (sonst würd ja die exe einfach ausgeführt werden).

Man könnte natürlich eine eigene Init-Funktion exportieren, die von der Client Anwendung als erstes aufgerufen werden muss. Allerdings möcht ich nicht wissen was passiert, wenn ich in einem bereits laufenden Prozess plötzlich nochmal die CRT initialisiere, am besten vielleicht noch eine andre Version der CRT. Das wär mir wohl viel zu frickelig...

[Chromanoid]

Habe eben noch mal gegoogelt. Das hier ist interessant :) http://sandsprite.com/CodeStuff/Using_a ... a_dll.html (edit: bringt in diesem kontext aber wohl nichts :D)

[dot]

Ich seh nicht ganz wie das hier weiterhelfen würde, wenn ich das richtig versteh, dann wird dort gezeigt wie man mit viel rumgefrickel eine exe zu einer dll umbauen kann!?