Wird dll jemals in Maschinencode umgewandelt?

Die DLLs sind immer noch Maschinencode. Sie werden zur Laufzeit nur dynamisch zur Laufzeit verknüpft (daher der Name). Wenn Sie also die Funktionssignaturen nicht ändern, müssen Sie Ihr Hauptprogramm nicht erneut kompilieren, um eine DLL zu verwenden, nachdem sie geändert wurde. Eine statische Bibliothek ist physisch Teil Ihrer ausführbaren Datei, deshalb erfordern Änderungen dort eine Neukompilierung (oder wirklich, eine Verknüpfung).

DLLs do enthalten kompilierten Maschinencode. Der Unterschied besteht darin, dass die Verknüpfung zwischen der Anwendungs-EXE und der DLL bei runtime statt zur (traditionellen) Verbindungszeit zwischen OBJ- und LIB-Dateien erfolgt.

Eine DLL enthält normalerweise Maschinencode. Der Punkt ist nicht, dass Sie die DLL ändern können, weil es Quellcode ist, aber dass Sie den Quellcode für die DLL ändern, neu kompilieren und neu verknüpfen können, und solange die Schnittstelle bleibt Das gleiche, Sie können die alte DLL durch eine neue ersetzen, und der Rest der Anwendung kann die neue anstelle der alten verwenden.

In der Praxis führt dies häufig zu Problemen, wie z. B. eine Anwendung mit Code, der von einem Fehler in der alten DLL abhängt . Wenn Sie eine Version erstellen, die den Fehler behebt, wird die Anwendung beschädigt. Google für "DLL Hell" für viele weitere Beispiele.

Einfach ausgedrückt: DLLs können nach der Kompilierung ausgetauscht werden, da sie physisch von Ihrer Exe getrennt sind. Lib und Obj-Dateien hingegen sind in Ihre exe kompiliert, so dass sie aktualisiert werden erfordert das erneute Kompilieren deiner App.

Dlls sind effektiv exes, die main () nicht definieren.

Wenn eine DLL mit dem Hauptprogramm verknüpft ist, werden nur die Schnittstelle, d. h. Klassen, Funktionen usw., die exportiert werden, durch ihre Signatur verknüpft. Der eigentliche Maschinencode in der DLL wird nur zur Laufzeit und nicht zur Kompilierzeit geladen. Aus diesem Grund können Sie Ihre App nur mit der DLL-Bibliothek erstellen und die eigentliche DLL dort ablegen, wo Sie sie haben möchten (zum Beispiel einen freigegebenen DLL-Ordner oder was auch immer).

Sie können diese DLL dann mit jeder anderen DLL mit derselben Schnittstelle austauschen. So funktionieren Plug-in-Systeme normalerweise, da jedes Plugin einfach eine DLL ist, die einer dokumentierten vordefinierten Schnittstelle entspricht, und das Programm lädt nur alle DLLs dieser Schnittstelle, die es in einem "plugins" -Verzeichnis findet.

Der (möglicherweise) verwirrende Teil hier ist, dass es effektiv zwei Arten von .lib-Dateien gibt:

a) Bibliotheken für statische Verknüpfungen. Diese stellen ihren gesamten kompilierten Code direkt in die Hauptanwendung und sind ein fester Bestandteil der resultierenden .exe-Datei.

b) Bibliotheken für die dynamische Verknüpfung. Diese enthalten eine Schnittstelle für eine DLL, die den eigentlichen Code enthält, der der App nur zur Laufzeit zur Verfügung stehen muss (und wenn dies nicht der Fall ist, wird sie nicht gestartet und sagt Ihnen einfach, welche DLL sie nicht finden konnte) / p>

Übrigens: Sie müssen nicht angeben, welche der Bibliotheken, mit denen Sie verlinkt sind, welchen Typ hat, sie tut dies automatisch.

Außerdem: Einige Anwendungen werden als DLLs erstellt, die in einer externen Umgebung ausgeführt werden sollen. Webservices sind zum Beispiel als DLLs mit einer bestimmten Schnittstelle implementiert, die von einem Apache / IISAPI / whatever-Server ausgeführt werden . Dies funktioniert ähnlich wie bei dem oben erwähnten Plugin-System, aber hier ist jede DLL effektiv die Anwendung.