dll Grundlagen

Thomasio

Erfahrenes Mitglied
Ich wage mich gerade an ein neues Thema, sprich ich habe erstmal überhaupt keine Ahnung.
Ich weiss über eine .dll genau so viel, dass sie erst zur Laufzeit ins Programm eingebunden wird, wobei ich mir nicht mal sicher bin, was genau das bedeutet.

WIE man sie dann einbindet ist schon Neuland für mich, ich weiss ja nicht mal, wie man sie erstellt, wie man Resourcen einbindet usw.

Auf der Suche nach passenden Tutorials finde ich so gut wie gar nichts, ein paar Bruchstücke von Code hier und da, aber daraus werde ich nicht schlau.

Vermutlich bin ich nur zu blöd das richtige Suchwort in Google einzugeben.
Gibt es so ein Tutorial, was einem die Sache von Grund auf erklärt?
Wenn ja, dann wo?
Wenn möglich ohne Visual irgendwas, ohne .NET, einfach Code::Blocks/MinGW/GCC++
 
Hallo Thomasio,

ich versuche mal ein paar Infos dazu rüberzubringen:
Ich weiss über eine .dll genau so viel, dass sie erst zur Laufzeit ins Programm eingebunden wird, wobei ich mir nicht mal sicher bin, was genau das bedeutet.
Womit du dich vermutlich beschäftigen willst, sind reguläre DLLs (daneben gibt es noch COM-DLLs und .NET-DLLs). Diese können auf zwei Arten eingebunden werden, nämlich statisch und dynamisch.

Statisch - Zum Projekt wird eine sogenannte Import-Library dazugelinkt, die üblicherweise bei der DLL-Erstellung auch mit erzeugt wird. Das Programm lädt die DLL schon direkt beim Start und wird nur funktionieren, wenn auch die DLL verfügbar ist.

Dynamisch - Die DLL wird zur Laufzeit zu einem vom Programmierer festgelegten Zeitpunkt mittels "LoadLibrary()" geladen. Die exportierten Funktion werden über "GetProcAddress()" zugänglich gemacht. Es liegt im Ermessen des Programmierers, wie auf eine nicht vorhandene DLL reagiert werden soll.
WIE man sie dann einbindet ist schon Neuland für mich, ich weiss ja nicht mal, wie man sie erstellt, wie man Resourcen einbindet usw.
Code::Blocks kenne ich nicht; Du solltest da mal nach einer DLL-Projektvorlage suchen. Ansonsten kannst du in ähnlicher Weise, wie bei einer EXE, programmieren. Die Funktionen, die du exportieren willst, müssen allerdings nach gewissen Regeln erstellt werden:
C++:
extern "C" __declspec(dllexport) int MyFunction()
{
    // Code
}
Man kann nur Funktionen exportieren und als Rückgabewert bzw. Parameter können keine Klassenobjekte verwendet werden.

Tutorials gibt's bestimmt, aber ich kenne auf Anhieb keins. Vielleicht kannst du ja aus meiner Antwort ein paar funktionierende Suchbegriffe herausziehen :-)

Gruß
MCoder
 
Wenn ich das richtig verstanden habe, ist eine .dll also nicht viel anderes als eine selber gemachte Library.
Also eine Sammlung von Funktionen die ich im Programm mehrfach verwende, ausgelagert in eine separate Datei, wobei ich auch noch einiges an neue Syntax lernen müsste.
Das Ganze auch noch ein wenig eingeschränkt bei Rückgabewerten und Globals (ja, ich weiss, die sollte man eh nicht haben).

Da stellt sich mir die Frage, warum überhaupt eine .dll? Da kann ich doch genausogut eine MyFunctions.h als header einbinden.
Oder was übersehe ich jetzt?
 
...
Man kann nur Funktionen exportieren und als Rückgabewert bzw. Parameter können keine Klassenobjekte verwendet werden.
...

das ist nicht ganz richtig...
Code:
extern "C"
so werden funktionen im C-Stil exportiert, klar das man hier keine klassen benutzen kann, lässt du es weg, wird der C++ stil angewandt und man kann durchaus klassen verwenden.. variablen lassen sich auch exportieren

@thomasio
warum eine DLL? der code ist somit "ausgelagert" und du kannst von anderen programmen auf diesen code zugreifen, ohne das er sich in diesem programm befindet, was platzsparender ist, als wenn 100 programme den selben code haben... wenn die DLL geladen wird, wird sie nur 1x von windows geladen und viele prozesse können dann darauf zugreifen... siehe File Mapping usw..
das war nur ein beispiel :)
 
Aus Wikipedia:
Wird ein Stück Programmcode verbessert, müssen nicht alle Programme geändert werden, die diesen Code nutzen, sondern es genügt, ihn in der DLL zu aktualisieren. Alle Programme können in diesem Fall auf die aktualisierte Fassung zugreifen. Dadurch ist es Softwareentwicklern möglich, relativ kleine Patches für größere Softwarepakete herauszugeben, beispielsweise auch für ganze Betriebssysteme. Ein ganzes Paket kann so durch die Aktualisierung einzelner DLLs auf den neuesten Stand gebracht werden.

In Form von Plug-ins können mit DLLs neue Programmteile für ein bereits bestehendes Programm erstellt und darin nahtlos integriert werden, ohne dass am schon existierenden Programm Veränderungen vorgenommen werden müssten. Diese Idee der dynamischen „Einbindbarkeit“ wird zum Beispiel unter Windows durch ActiveX realisiert.

Auch können durch solch einen modularen Aufbau einfach nicht benötigte Funktionen deaktiviert werden.

http://de.wikipedia.org/wiki/Dynamic_Link_Library#DLL-Datei_Aufbau
Hier sind die Vorteile sowie (für c++) zwei Codebeispiele aufgeführt!
Grüße,
Orbit
 
Na das erklärt zumindest mal den Sinn, Anwendungsübergreifende Funktionen nur einmal im Speicher, könnte ich tatsächlich gut gebrauchen.

Nur mit den Beispielen stehe ich mal wieder auf dem Schlauch.
Die Beispiele gehen von VC++ über Borland bis Delphi, aber MinGW Fehlanzeige.
Nachdem das völliges Neuland für mich ist, stolpere ich schon über kleinste Feinheiten in der Syntax.
Immerhin gibt es ein API Beispiel für LoadLibrary, das hilft auf jeden Fall weiter.

Wenn ich jetzt nur noch wüsste wie ich sie erstelle.
Code::Blocks hat unter "New Project" den Punkt "DLL" aufgeführt, und so wie ich C::B kenne geben die auch gleich ein Grundgerüst vor, da werde ich mich morgen mal ran setzen.

Auf jeden Fall vielen Dank an alle.
 
lässt du es weg, wird der C++ stil angewandt und man kann durchaus klassen verwenden.. variablen lassen sich auch exportieren
Das schränkt aber die Verwendbarkeit der DLL erheblich ein, da dann nur noch C++ -Programme dammit umgehen können. Die C-Aufrufkonvention dagegen stellt sicher, dass auch mit anderen Programmiersprachen erstellte Programme die DLL verwenden können. Wenn Klassen verwendet werden sollen, dann ist es besser, gleich eine COM-DLL zu bauen.

Gruß
MCoder
 
Zurück