DLLs Vorteil/Nachtei/Tutorial?

Aber so wie ich das seh, ist jeder Unreg für Mr. N direkt der Dreck des Forums.

Mr. N

Artchi schrieb:

OK, da scheine ich wohl auch noch was lernen zu müssen (bin aber nur Windows-User): was ist denn die Definition von Sharedlibs, so das sie sich von DLLs unterscheidet?

Achtung: Ich kenne nur ELF-SharedLibs.

DLLs werden bekanntlich indirekt gelinkt, über .libs. Soweit ich weiß ist eine DLL fast wie ein eigener Prozess, nur dass eben von außen über Namen und Nummer auf Funktionen zugegriffen werden kann. Sie haben ja auch ihren eigenen Heap. Beim Starten wird die DLLMain aufgerufen, die einige interessante Einschränkungen hat.

Shared Libraries werden direkt gelinkt. Beim Compilieren werden sie erstmal nur als Abhängigkeit eingetragen und es wird geprüft, ob alle Symbole vorhanden sind. Zur Runtime wird dann wirklich gelinkt. (Wobei das nur fast stimmt, man kann Symbole so markieren, dass sie schon vorher gelinkt werden und dann nach außen nicht sichtbar sind.) Eine Shared Library hat keinen eigenen Heap und beim Laden werden die Funktionen mit constructor-Attribut aufgerufen, umgekehrt beim Entladen die Funktionen mit destructor-Attribut, für diese gibt es keine schwerwiegenden Einschränkungen.

Shared Libraries haben noch ein paar interessante Anwendungsmöglichkeiten, die durch das Linken zur Laufzeit entstehen. So kann man zum Beispiel eine Shared Library preloaden um Funktionen aus anderen Bibliotheken zu ersetzen. Oder man kann eine Bibliothek mit dem Flag RTLD_GLOBAL händisch laden, dann können alle danach händisch geladenen Bibliotheken auf deren Symbole zugreifen. Und noch ein paar andere lustige Dinge.

Der größte Nachteil von Shared Libraries ist IMHO, dass man leicht in Versuchung gerät, mehr zu exportieren als nötig, da standardmäßig alle Symbole exportiert werden. Aber mit dem GCC-Flag -fvisibility=hidden kann man das umdrehen.

Alle Angaben ohne Gewähr.

Kenner der Scene schrieb:

Aber so wie ich das seh, ist jeder Unreg für Mr. N direkt der Dreck des Forums.

Ja, bis das Gegenteil bewiesen ist. Des weiteren ist ja der Punkt, dass ich keine Lust hatte, mein Design auf etwas so Eingeschränktes wie DLLs anzupassen.

Mr. N schrieb:

Ja, bis das Gegenteil bewiesen ist.

Sind wir ein "klein bisschen" rassistisch gegenüber Unregs? "Ja, bis das Gegenteil bewiesen ist." kommt mir irgendwie bekannt vor, ist aber ein paar Jahrzehnte her.

Mr. N schrieb:

dass ich keine Lust hatte, mein Design auf etwas so Eingeschränktes wie DLLs anzupassen.

DLLs sind nicht eingeschränkt nur dein Konzept mit ihnen umzugehen, ja ich weiß: Um dein Ego zu verteidigen kommt jetzt wieder Blödsinn und alle anderen sind es schuld. Ja ja, selbst die von Adobe, Microsoft, Novell, uvm. weil die mit DLLs richtig umgehen können.

Mr. N

Ach ja, wenn man fünf Anwendungen lädt, die die Shared Library libfoo.so laden, wird libfoo.so nur einmal physikalisch in den Speicher geladen (übrigens mit mmap, das natürlich fünfmal), nur die Tabelle mit den Funktionspositionen ist für jeden Prozess lokal.

Simon2

Kenner der Scene schrieb:

Mr. N schrieb:

Ja, bis das Gegenteil bewiesen ist.

Sind wir ein "klein bisschen" rassistisch gegenüber Unregs? "Ja, bis das Gegenteil bewiesen ist." kommt mir irgendwie bekannt vor, ist aber ein paar Jahrzehnte her....

Guter Vergleich: "Unreg-Poster im C++-Forum" sind die "Juden von heute" !
Gibt doch nichts, was man mit einem Nazivergleich nicht noch unterbieten könnte.

Großes Kino !

TheToast

Dabei müssen DLLs aber nicht unbedingt gelinkt werden, man kann auch DLLs erst später nachladen. (Für plugIns etwa)

Mr. N

TheToast schrieb:

Dabei müssen DLLs aber nicht unbedingt gelinkt werden, man kann auch DLLs erst später nachladen. (Für plugIns etwa)

Ich dachte, DLLs werden überhaupt nicht gelinkt.

Klar, beim späteren Laden muss man die Funktionen aber alle händisch extrahieren, per GetProcAddress, oder etwa nicht? (Ist natürlich auch bei Shared Libraries so.)

TomasRiker

Natürlich werden die gelinkt, darum heißen sie ja Dynamic Link Library ...

Mr. N

TomasRiker schrieb:

Natürlich werden die gelinkt, darum heißen sie ja Dynamic Link Library ...

Wozu ist dann die .lib da? Wird die nur zum Spaß erzeugt?

Ich dachte, es wird eine .lib erzeugt und die wird dann gelinkt, nicht die eigentliche DLL. Aber du kannst mich gerne aufklären.

EDIT: Ich schreib mir in 7 Absätzen die Finger wund um zu erklären, wie ich die Unterschiede zwischen DLLs und Shared Libraries verstanden habe, und dann muss ich mir ein fettgeschriebenes "Link" bieten lassen.

Artchi

Na, und die DLL wird zum Spaß erzeugt?

Das kannst du doch so nicht sehen. Die LIB dient nur als Stub (oder wie man sowas nennt), mehr ist das nicht. Ist sozusagen die Header-Datei für den Linker. Halt by-Design vom MSVC. Der rafft das anscheinend anders nicht...

Mr. N

Artchi schrieb:

Na, und die DLL wird zum Spaß erzeugt?

Natürlich nicht, aber sie wird nicht selber gelinkt.

Artchi schrieb:

Das kannst du doch so nicht sehen. Die LIB dient nur als Stub (oder wie man sowas nennt), mehr ist das nicht. Ist sozusagen die Header-Datei für den Linker.

Also wird die LIB gelinkt?!

Können andere Compiler DLLs ohne LIB linken?

Artchi

Ja, MinGW macht das meines Wissens (bin aber kein wirklicher MinGW-Kenner), und auch Delphi braucht keine LIB (die brauchen nur ein Schlüsselwort im Source) um DLLs nutzen zu können.

Aber ich bin selber kein DLL-Freund, ich benutze eigentlich nur DLLs von anderen.

Was stört dich eigentlich an dem Stub? Nur weil der da ist, ist eine DLL statisch? DLL sagt doch eigentlich aus, was gemacht wird: dynamisch (zur Laufzeit) wird gelinkt. Eigentlich unmissverständlich, wie ich finde.

Mr. N

Artchi schrieb:

Ja, MinGW macht das meines Wissens (bin aber kein wirklicher MinGW-Kenner), und auch Delphi braucht keine LIB (die brauchen nur ein Schlüsselwort im Source) um DLLs nutzen zu können.

Ich meine mich bei MinGW an irgendwelche .a-Dateien zu erinnern. Bei Delphi kann ich mir alles vorstellen.

Artchi schrieb:

Aber ich bin selber kein DLL-Freund, ich benutze eigentlich nur DLLs von anderen.

Wie erreichst du dann Modularität?

Artchi schrieb:

Was stört dich eigentlich an dem Stub?

Stört mich nicht wirklich, ich finde es allerdings auch nicht unbedingt elegant.

Artchi schrieb:

Nur weil der da ist, ist eine DLL statisch?

Nein, aber die LIB, die man linkt.

Artchi schrieb:

DLL sagt doch eigentlich aus, was gemacht wird: dynamisch (zur Laufzeit) wird gelinkt. Eigentlich unmissverständlich, wie ich finde.

Namen sind Schall und Rauch. Wichtig ist doch, was passiert.

Zeus

.a sind die statische Lib und Mingw kann auch auch Dll's erstellen

Mr. N

Ich hab nochmal nachgelesen, MinGW erstellt auch Import Libraries, allerdings mit der Endung .a (die gleiche Endung benutzt er für statische Libraries, so wie jeder normale Unix-Compiler, .a entspricht also .lib).

Artchi

Also Modularität erreiche ich nicht nur mit DLLs. Die erreiche ich auch mit LIBs oder Templates. Und eine *.cpp ist auch schon ein Modul. Ich kann auch durch abstrakte Klassen Abhängigkieten verringern usw. Deshalb verstehe ich jetzt nicht unbedingt, was DLLs zwangsweise mit Module zu tun haben? DLLs machen nur in wenigen Scenarien Sinn bzw. bringen in wenigen einen Vorteil. Aber ich glaube nicht, das man das nochmal durchkauen muß.

Mr. N

Artchi schrieb:

Also Modularität erreiche ich nicht nur mit DLLs. Die erreiche ich auch mit LIBs oder Templates. Und eine *.cpp ist auch schon ein Modul. Ich kann auch durch abstrakte Klassen Abhängigkieten verringern usw. Deshalb verstehe ich jetzt nicht unbedingt, was DLLs zwangsweise mit Module zu tun haben?

Stimmt schon, gibt halt noch den Fall des Modul-zur-Laufzeit-Ladens.

Artchi schrieb:

DLLs machen nur in wenigen Scenarien Sinn bzw. bringen in wenigen einen Vorteil. Aber ich glaube nicht, das man das nochmal durchkauen muß.

Ja, die Frage, ob DLLs gelinkt werden oder nicht, interessiert mich jetzt doch mehr. :p

Damit man mich nicht falsch versteht: Das Laden einer DLL per LoadLibrary ist kein Linken! Zumindest aus Applikationssicht.

TomasRiker

Hier steht alles, was man wissen muss
http://msdn2.microsoft.com/en-us/library/ms681914.aspx

Mr. N

Ich hab mich hier weitergebildet.

hustbaer

Mr. N schrieb:

Achtung: Ich kenne nur ELF-SharedLibs.

DLLs werden bekanntlich indirekt gelinkt, über .libs.

Ja, zum linken verwendet man .lib Files. Und? Unterschied?

Soweit ich weiß ist eine DLL fast wie ein eigener Prozess, nur dass eben von außen über Namen und Nummer auf Funktionen zugegriffen werden kann.

Eine DLL und ein Prozess sind grundlegend verschieden. Eine DLL ist ein eigenständiges PE Image, ja, aber das war's dann auch schon.

Sie haben ja auch ihren eigenen Heap.

Nope, haben sie nicht. Eine DLL kann eine "private" Speicherverwaltung verwenden wenn sie z.B. ihren eigenen Heap anlegt (z.B. in DllMain) oder einfach eine eigene Heap-Implementierung enthält. Eine DLL "hat" aber nicht einfach so ihren eigenen Heap. Eine DLL "hat" garkeinen Heap, zumindest keinen den sie vom Betriebssystem bekommen würde.

Der Unterschied zwischen SOs und DLLs was die Speicherverwaltung angeht kommt daher dass mit SOs immer nur eine Kopie von z.B. malloc vorliegen kann (auch wenn mehrere SOs eine Funktion namens malloc implementieren), und diese eine Version wird dann für alle Aufrufe verwendet, egal wo diese stehen.
Bei DLLs ist das anders. Ein Import in einer DLL oder Windows EXE ist sinngemäss nicht "verwende die Funktion namens malloc, egal wo sie herkommt" sondern "verwende die Funktion namens malloc aus der DLL XYZ.DLL".

Beide Varianten haben Vorteile und Nachteile. Der Vorteil bei SOs ist dass man "global" Funktionen austaushen/überschreiben kann, bzw. dass eine Funktion eines Namens auch immer nur 1x vorliegt. Das erleichtert einiges wenn man eben soetwas wie ein Pluginsystem basteln möchte, oder wenn man mal eben ptmalloc durch tcmalloc ersetzen will.

Der Vorteil von DLLs ist dass man immer genau das bekommt mit was man bei der Entwicklung des Programms gerechnet hat. Namenskonflikte zwischen unterschiedlichen DLLs die voneinander nichts wissen und sich dann irgendwann mal in einem Prozess "treffen" werden dadurch z.B. auch vermieden.
Weiters ermöglicht es relativ einfach Code von verschiedensten Compilern (die auch gerne verschiedene Runtime Libraries verwenden dürfen) zu mischen -- ohne dass irgendwas neu compiliert werden muss. Dafür bezahlt man natürlich den Preis dass man sich an Berührungspunkten zwischen Code der mit unterschiedlichen Compilern/Runtimes compiliert wurde eben selbst darum kümmern muss dass gewisse Dinge funktionieren. Man darf also einen Zeiger der aus malloc in DLL A stammt nicht unbedingt mit free in DLL B freigeben.