Hallo!
Noch ein Nachtrag zur letzten Veranstaltung. Wir haben ja schon wegen Mozilla diskutiert, ich habe nun Netscape 6PR3 zum Laufen gebracht, nach- dem ich das Verzeichnis komplett gelöscht habe und dann netscape 6 neu installiert habe. Man sollte sich _nicht_ auf den Mechanismus von Netscape (Installprogramm, das die benötigten Pakete per FTP nachlegt) verlassen, sondern das Gesamtpaket vom Server holen, irgendwo bei ftp://linuxftp.netscape.com/pub/netscape6/english/unix/linux22 (Vorsicht, Adresse nur aus dem Kopf, stimmt garantiert nicht exakt!) ist ein Paket "netscape-i686-pc-linux-gnu-sea.tar.gz" zu finden, das die nötigen Zusatzpakete enthält.
Die üblichen Plug-Ins von Netscape 4.7x laufen unter Netscape6. Der Speicher- verbrauch ist nicht so viel geringer, wie ich vermutet hatte. Aber es werden mehr Teile als "shared libs" geladen, was in einem Terminal-System günstig ist. Stabil kann ich auch diese Ausgabe nicht bezeichnen, bei einfachen Seiten hat er z.T. Probleme, auf anderen mit Java oder Javascript gespickten Seiten zeigt er keine Probleme.
Gruss Reiner
On Sat, Nov 11, 2000 at 07:50:10PM +0100, Reiner Klaproth wrote:
mehr Teile als "shared libs" geladen, was in einem Terminal-System günstig
Wenn 10 Nutzer das gleiche non-shared binary benutzen, ist der Code trotzdem nur einmal im Speicher. Nur wenn andere Proggis die gleiche lib nutzen bringen shared libs was.
Reinhard
Am Sam, 11 Nov 2000 schrieb Reinhard Foerster:
mehr Teile als "shared libs" geladen, was in einem Terminal-System günstig
Wenn 10 Nutzer das gleiche non-shared binary benutzen, ist der Code trotzdem nur einmal im Speicher. Nur wenn andere Proggis die gleiche lib nutzen bringen shared libs was.
Netscape 6 benutzt AFAIK nicht nur shared libs sondern auch shared objects, welche was bringen sollten...
Bye, Stephan
On Sat, Nov 11, 2000 at 08:37:11PM +0100, Stephan Goetter wrote:
Am Sam, 11 Nov 2000 schrieb Reinhard Foerster:
mehr Teile als "shared libs" geladen, was in einem Terminal-System günstig
Wenn 10 Nutzer das gleiche non-shared binary benutzen, ist der Code trotzdem nur einmal im Speicher. Nur wenn andere Proggis die gleiche lib nutzen bringen shared libs was.
Netscape 6 benutzt AFAIK nicht nur shared libs sondern auch shared objects, welche was bringen sollten...
Wobei bringt das was?
Reinhard
Am Sam, 11 Nov 2000 schrieb Reinhard Foerster:
Netscape 6 benutzt AFAIK nicht nur shared libs sondern auch shared objects, welche was bringen sollten...
Wobei bringt das was?
Na beim Speicherverbrauch, er muss nur das laden was er wirklich benötigt, desweiteren lassen sich solche Module austauschen...große durch kleinere.
Bye, Stephan
On Sat, Nov 11, 2000 at 10:32:18PM +0100, Stephan Goetter wrote:
Wobei bringt das was?
Na beim Speicherverbrauch, er muss nur das laden was er wirklich benötigt,
Das ist doch sonst auch so, oder? Der Kode wird erstmal nur in den virtuellen Speicher gemapped. Erst beim Zugriff auf den Kode gibt es einen page fault und eine Seite des physischen RAMs wird belegt.
desweiteren lassen sich solche Module austauschen...große durch kleinere.
Das ist IMO der einzige Grund fuer DSOs, nicht der Speicherverbrauch.
Reinhard
Am Son, 12 Nov 2000 schrieb Reinhard Foerster:
Das ist doch sonst auch so, oder? Der Kode wird erstmal nur in den virtuellen Speicher gemapped. Erst beim Zugriff auf den Kode gibt es einen page fault und eine Seite des physischen RAMs wird belegt.
Der Vorteil ist das man auch noch später bestimmen kann, was beim Start geladen oder gemapped wird und was nicht. Bei shared libs legt man das beim Linken statisch fest.
desweiteren lassen sich solche Module austauschen...große durch kleinere.
Das ist IMO der einzige Grund fuer DSOs, nicht der Speicherverbrauch.
Vielleicht nicht der einzige, aber der Hauptgrund.
Bye, Stephan
On Saturday 11 November 2000 22:32, Stephan Goetter wrote:
Am Sam, 11 Nov 2000 schrieb Reinhard Foerster:
Netscape 6 benutzt AFAIK nicht nur shared libs sondern auch shared objects, welche was bringen sollten...
Wobei bringt das was?
Na beim Speicherverbrauch, er muss nur das laden was er wirklich benötigt, desweiteren lassen sich solche Module austauschen...große durch kleinere.
Ich glaube hier sollte man was klaeren:
die Begriffe "shared lib", "shared object" und "DLL" sind synonym (fuer RTL II Fans: sie bedeuten das Gleiche).
Man hat als Programmierer aber die Wahl entweder gegen eine shared lib zu linken, dann wird sie beim Starten geladen, oder sie zur Laufzeit per libdl selbst zu laden, dann muss man aber ueber Funktionszeiger arbeiten statt die Funktionen direkt aufzurufen. Beides arbeitet mit den selben Mechanismen, der Unterschied ist wann sie geladen werden und wie komfortabel es sich programmieren laesst.
Konrad
Hallo,
Am Mittwoch, 15. November 2000 19:12 schrieb Konrad Ro
selbst zu laden, dann muss man aber ueber Funktionszeiger arbeiten statt die Funktionen direkt aufzurufen. Beides arbeitet mit den selben Mechanismen, der Unterschied ist wann sie geladen werden und wie komfortabel es sich programmieren laesst.
Ein nicht zu vernachlässigender Aspekt: foo.so raus aus dem Verzeichnis, bar.so rein, und schon hat man veränderte Funktionalität im Programm. Dem gegenüber it die modulare Programmierung zur Compile-Time, also Nutzung von shared libs auf "normalem" Wege, ein wenig eingeschränkter. (RTL2-Fans: Was, dynamic class loading? Habe ich da eine Folge verpaßt?)
Josef Spillner
On Wed, Nov 15, 2000 at 07:12:11PM +0100, Konrad Rosenbaum wrote:
Ich glaube hier sollte man was klaeren:
die Begriffe "shared lib", "shared object" und "DLL" sind synonym (fuer RTL II Fans: sie bedeuten das Gleiche).
Aha, das habe ich registriert.
[...]
Funktionen direkt aufzurufen. Beides arbeitet mit den selben Mechanismen, der Unterschied ist wann sie geladen werden und wie komfortabel es sich programmieren laesst.
Aha, zwischen den beiden (oder 3) "Synonymen" bestehen also doch deutliche Unterschiede. Das widerspricht deiner Aussage von oben. (fuer RTL-2 Fans: "sich widersprechen" bedeuted, daß man 2 Aussagen trifft, die nich beide gleichzeitig wahr sein kann.)
Reinhard
am Thu, dem 16.11.2000, um 18:57:15 +0100 mailte Reinhard Foerster folgendes:
On Wed, Nov 15, 2000 at 07:12:11PM +0100, Konrad Rosenbaum wrote: (fuer RTL-2 Fans: "sich widersprechen" bedeuted, daß man 2 Aussagen trifft,
kommt jetzt 'RTL-2-Gucker' nach 'Warmduscher' ? LOL ;-)
Andreas
die Begriffe "shared lib", "shared object" und "DLL" sind synonym (fuer
RTL
II Fans: sie bedeuten das Gleiche).
Nun, eine shlib und eine DLL sind nicht ganz synonym: ((shlib)(Plattform)) [ist synonym zu] ((DLL)(Plattform)) Oder für RTL2 Fans: shared libraries sind für Unix-artige was Dynamic Link Libraries für Windows sind. Gehandhabt werden sie genauso (\Plattformspezifik).
Funktionen direkt aufzurufen. Beides arbeitet mit den selben
Mechanismen, der
Unterschied ist wann sie geladen werden und wie komfortabel es sich programmieren laesst.
Aha, zwischen den beiden (oder 3) "Synonymen" bestehen also doch deutliche Unterschiede. Das widerspricht deiner Aussage von oben. (fuer RTL-2 Fans: "sich widersprechen" bedeuted, daß man 2 Aussagen
trifft,
die nich beide gleichzeitig wahr sein kann.)
Was er meint ist, daß man einzelne Funktionen aus den Bibiliotheken laden kann, ohne sie entsprechend zu linken (genauer: aus denselben Bibiliotheken) Wenn man eine shared lib shared linked, dann linkt man eine statische lib, welche den Overhead des Suchens und Ladens der Funktionen übernimmt. D.h. eine shared lib kommt immer mit einer statischen (stub) lib. RTL2: wasislos?
(so vertehe ich das ganze, kann das einer von den Gurus bestätigen?)
Eric
p.s. Achja: Das "" oben soll "abzüglich" bedeuten (in Anlehnung an die Mengensubtraktion)
On 16.11.00 Eric Schaefer (eric@gixgax.de) wrote:
Moin,
Nun, eine shlib und eine DLL sind nicht ganz synonym: ((shlib)(Plattform)) [ist synonym zu] ((DLL)(Plattform)) Oder für RTL2 Fans: shared libraries sind für Unix-artige was Dynamic Link Libraries für Windows sind. Gehandhabt werden sie genauso (\Plattformspezifik).
Soweit ich die Leute aus den Linux-Gruppen verstanden habe -- nein. Das ELF-Format unterstützt auch das sharen zwischen Programmen, d.h. wenn ich grace gegen lesstif linke und aufrufe und habe gleichzeitig ein netscape|mozilla(?) gegen lesstif gelinkt (ja das geht wohl), am laufen greifen beiden auf denselben Code im memory zu. Bei Windows soll das wohl nicht so sein, da werden nur die Funktionen aus dem Programm ausgelagert. Das soll wohl in etwa das sein, was früher a.out war.
H.
Soweit ich die Leute aus den Linux-Gruppen verstanden habe -- nein. Das ELF-Format unterst�tzt auch das sharen zwischen Programmen, d.h. wenn ich grace gegen lesstif linke und aufrufe und habe gleichzeitig ein netscape|mozilla(?) gegen lesstif gelinkt (ja das geht wohl), am laufen greifen beiden auf denselben Code im memory zu. Bei Windows soll das wohl nicht so sein, da werden nur die Funktionen aus dem Programm ausgelagert. Das soll wohl in etwa das sein, was fr�her a.out war.
Nee, bei Windows existiert der Code auch nur einmal, wozu br�uchte ich sonst DLLs??? Das ist auch gerade der Witz bei DLLs wie commdlg.dll, in welcher der Code f�r die ganzen Standard-Dialoge (�ffen, Sichern, etc.) stecken. Da quasi alle Programme diesen Code benutzen spart man einiges an Speicher. (Mal ganz davon abgesehen, das man einheitliche Dialoge haben wollte)
Eric
On 17.11.00 Eric Schaefer (eric@gixgax.de) wrote:
Moin,
Nee, bei Windows existiert der Code auch nur einmal, wozu bräuchte ich sonst DLLs???
Siehe 20001118120439.A9846@rncmm2.urz.tu-dresden.de
Direkte Folgerungen und zusaetzliche Bemerkungen a) ("shared" != "dynamic") b) !("shared" ==> "dynamic") c) !("dynamic" ==> "shared")
Daraus, daß ein Programm denselben Code aus einer Lib lädt, wie ein anderes, kann man nicht schlußfolgern, daß es auch denselben Code im Main Memory zugreift, wenn er sich dort schon befinden würde. Soweit hatte ich die Experten in dcoul* verstanden, und daß W$ nicht sharen könnte.
H.
On Thursday 16 November 2000 18:57, Reinhard Foerster wrote:
On Wed, Nov 15, 2000 at 07:12:11PM +0100, Konrad Rosenbaum wrote:
Ich glaube hier sollte man was klaeren:
die Begriffe "shared lib", "shared object" und "DLL" sind synonym (fuer RTL II Fans: sie bedeuten das Gleiche).
Aha, das habe ich registriert.
nochmal ganz deutlich: shared lib = Datei im ELF Format mit Endung .so shared object = Datei im ELF Format mit Endung .so (so wie [s]hared [o]object) DLL = Synonym fuer shared Lib aus der M$-Welt
Als s.object bezeichnet man das Teil, wenn man es gerade kompiliert oder _nur_ zur Laufzeit laedt. Als s.lib bezeichnet man es, wenn es vom ELF-Loader im Kernel gerade geladen wird. Also nur Haarspalterei, da es sich um die selbe Datei handelt.
mit .so Dateien habe ich zwei Moeglichkeiten: a) sie per Headerdatei einbinden und den Linker einen Eintrag in mein Program machen lassen, der von Kern als "ladt das Ding fuer mich, weil ich zu faul dazu bin" interpretiert wird. b) ich oeffne sie per dlopen(3) und lasse mir (Funktions-)Pointer auf die Symbole darin geben und rufe die entsprechenden Pointer auf
Beide Methoden koennen bei ein und derselben .so ihre Berechtigung haben. (Z.B. kann Programm A sagen, ich brauche SSL auf jeden Fall und Programm B laedt SSL nur bei Bedarf.)
Die Unterscheidung ist also nicht s.object oder s.lib, sondern linken zur compile-Zeit oder zur Laufzeit.
Funktionen direkt aufzurufen. Beides arbeitet mit den selben Mechanismen, der Unterschied ist wann sie geladen werden und wie komfortabel es sich programmieren laesst.
Aha, zwischen den beiden (oder 3) "Synonymen" bestehen also doch deutliche Unterschiede. Das widerspricht deiner Aussage von oben. (fuer RTL-2 Fans: "sich widersprechen" bedeuted, daß man 2 Aussagen trifft, die nich beide gleichzeitig wahr sein kann.)
siehe oben.
Konrad
On Fri, Nov 17, 2000 at 04:59:01PM +0100, Konrad Rosenbaum wrote:
Als s.object bezeichnet man das Teil, wenn man es gerade kompiliert oder _nur_ zur Laufzeit laedt.
Als s.lib bezeichnet man es, wenn es vom ELF-Loader im Kernel gerade geladen wird.
Falsche Defi. Gegenbeispiel: Bei a.out-Linux gibt es auch shared libs und diese werden nicht von einem "ELF-Loader" in den Kernel geladen. q.e.q. Der Begriff "shared lib" sagt UEBERHAUPT NICHTS über das Wann und Wie des Linkens und Ladens aus. Shared sagt einfach nur, dass die Lib bei Nutzung durch mehrere Anwendungen nur einmal im Speicher rumlungert.
Du kannst also auch eine System mit shared libs bauen, die in jedem Binary (also mehrmals) vorhanden sind und trotzdem shared sind. Natuerlich ist das so unpraktisch, dass das kein Mensch macht. Zur Klaerung der Begriffe ist die Betrachtung aber sinnvoll.
Was du zu erklaeren versuchst ist eine "dynamisch ladbare Bibliothek" Das diese meist gleichzeitig auch shared lib ist, liegt aus praktischen Gruenden auf der Hand, ist aber nicht zwingend.
Also nur Haarspalterei, da es sich um die selbe Datei handelt.
Naja, so langsam wurde in diesem Thread alles durcheinanderegehauen.
mit .so Dateien habe ich zwei Moeglichkeiten: a) sie per Headerdatei einbinden und den Linker einen Eintrag in mein Program machen lassen, der von Kern als "ladt das Ding fuer mich, weil ich zu faul dazu bin" interpretiert wird. b) ich oeffne sie per dlopen(3) und lasse mir (Funktions-)Pointer auf die Symbole darin geben und rufe die entsprechenden Pointer auf
Der Witz bei Variante b) ist mMn, dass man eigentlich nur den Namen einer Funktion kennen muss (sowas wie ListFunctionNames()) und damit dann Funktionen laden kann, deren Namen zur Compilezeit des Hauptprogramms noch gar nicht bekannt waren. Das geht mit dem Mechanismus in a) nicht.
(ich habe Mechanismus b) noch nicht benutzt. Stimmt das, was ich hier gesagt habe? Stefan G.???)
Reinhard
Tag!
Am Freitag, 17. November 2000 19:57 schrieb Reinhard Foerster:
Der Witz bei Variante b) ist mMn, dass man eigentlich nur den Namen einer Funktion kennen muss (sowas wie ListFunctionNames()) und damit dann Funktionen laden kann, deren Namen zur Compilezeit des Hauptprogramms noch gar nicht bekannt waren. Das geht mit dem Mechanismus in a) nicht.
Da muß ich jetzt doch noch mal nachfragen, und damit die Unordnung hier erweitern :-) Eine shared lib kann doch mehr als ein shared object enthalten, oder? Ist zwar unüblich, zwei Klassen in einer Datei, aber machbar. Oder verwechsle ich hier Objektdefinitionen? Zu den unbekannten Namen: Das läßt sich ganz praktikabel mit Factories umgehen, solange die API der einzelnen Module zu vergleichen ist.
Josef Spillner
On Fri, Nov 17, 2000 at 05:52:24PM +0100, Josef Spillner wrote:
Da muß ich jetzt doch noch mal nachfragen, und damit die Unordnung hier erweitern :-) Eine shared lib kann doch mehr als ein shared object enthalten, oder? Ist
Wenn wir mal bei C-Libs bleiben mehrere Funktionen, ja. Das kannst du dir mit nm anschauen. Die Bezeichnung "shared objcect" habe wir in der Diskussion bisher fuer per dl*() importierte Dinge genommen. Aber du hast recht - das ist sehr unsauber, da dabei nichts "shared" sein muss.
zwar unüblich, zwei Klassen in einer Datei, aber machbar. Oder verwechsle ich hier Objektdefinitionen?
Es waren kein Objekte im Sinne von OO-Programmiersprachen gemeint. Häuser, Bäume, Funktionen usw. sind je nach Betrachtungsweise auch Objekte. Und um Funktioen ging es.
Zu den unbekannten Namen: Das läßt sich ganz praktikabel mit Factories
Nie gehört - das scheint ein Programmiersprachenspezifischer Slang zu sein.
umgehen, solange die API der einzelnen Module zu vergleichen ist.
Reinhard
On Saturday 18 November 2000 00:21, Reinhard Foerster wrote:
On Fri, Nov 17, 2000 at 05:52:24PM +0100, Josef Spillner wrote:
Da muß ich jetzt doch noch mal nachfragen, und damit die Unordnung hier erweitern :-) Eine shared lib kann doch mehr als ein shared object enthalten, oder? Ist
Wenn wir mal bei C-Libs bleiben mehrere Funktionen, ja. Das kannst du dir mit nm anschauen. Die Bezeichnung "shared objcect" habe wir in der Diskussion bisher fuer per dl*() importierte Dinge genommen. Aber du hast recht - das ist sehr unsauber, da dabei nichts "shared" sein muss.
Aber klar, weil dl*() dafuer sorgt, dass es sich "shared" verhaelt, also der zwete Prozess, der es laedt benutzt den selben physikalischen Speicher, wie der erste.
zwar unüblich, zwei Klassen in einer Datei, aber machbar. Oder verwechsle ich hier Objektdefinitionen?
OO und shlibs sind noch ein ganz eigenes Kapitel... das ist etwas komplizierter, als C-Funktionen (wegen des Name-Manglings; Loesung siehe unten).
Es waren kein Objekte im Sinne von OO-Programmiersprachen gemeint. Häuser, Bäume, Funktionen usw. sind je nach Betrachtungsweise auch Objekte. Und um Funktioen ging es.
Zu den unbekannten Namen: Das läßt sich ganz praktikabel mit Factories
Nie gehört - das scheint ein Programmiersprachenspezifischer Slang zu sein.
Ist Windows-Slang: eine Factory ist eine Funktion/Methode, die komplett initialisierte Instanzen einer Klasse zurueckgibt.
Im Falle von Klassen in shared libs wuerde man dann noch so eine Funktion definieren:
extern "C" MyClass* factory(){return new MyClass;}
Konrad
On Friday 17 November 2000 19:57, Reinhard Foerster wrote:
On Fri, Nov 17, 2000 at 04:59:01PM +0100, Konrad Rosenbaum wrote:
Als s.object bezeichnet man das Teil, wenn man es gerade kompiliert oder _nur_ zur Laufzeit laedt.
Als s.lib bezeichnet man es, wenn es vom ELF-Loader im Kernel gerade geladen wird.
Falsche Defi. Gegenbeispiel: Bei a.out-Linux gibt es auch shared libs und diese werden nicht von einem "ELF-Loader" in den Kernel geladen. q.e.q.
[das heisst q.e.d. - oder?]
Wer hat was von "in den Kernel" gesagt? Der ELF Loader sitzt nur im Kernel, legt die Daten aber in den Userspace.
Um ganz genau zu sein laedt der ELF-Loader nur ldlinux.so und die laedt dann den Rest vom Userspace aus.
Was auch nicht ganz korrekt ist, denn vorher wird die gesamte Page-Tabelle des Prozesses aufgeloest und mit den Daten aus ldlinux.so neu aufgebaut. Ausserdem werden alle Dateideskriptoren mit close-on-exec-Flag geschlossen (ausser std{in,out,err} meistens alle).
Der Begriff "shared lib" sagt UEBERHAUPT NICHTS über das Wann und Wie des Linkens und Ladens aus. Shared sagt einfach nur, dass die Lib bei Nutzung durch mehrere Anwendungen nur einmal im Speicher rumlungert.
Irgendwie versuchen wir hier mit unterschiedlichen Worten das selbe zu sagen...
Ganz am Rande: dieser Effekt tritt auf, weil die Lib per mmap geladen und dann schreibgeschuetzt wird (zumindest der ausfuehrbare Teil, der Rest lebt per MAPPRIVATE im copy-on-write Status).
Du kannst also auch eine System mit shared libs bauen, die in jedem Binary (also mehrmals) vorhanden sind und trotzdem shared sind.
(Deswegen _shared_ lib oder? ;-) )
Haeh? Erklaer mal anhand von Dateien und Funktionen was Du meinst.
Soweit ich das System kenne gilt: habe ich zwei identische so's (auf unterschiedlichen Inode, also mit eigenem Speicher auf der Platte), nennen wir sie A.so und B.so und ich lade in Programm X die A.so und in Y die B.so, dann koennen sie auch noch so gleich sein und ich habe doch zweimal Speicher verbraucht. Lade ich sowohl von X, als auch von Y die A.so, so habe ich fuer den schreibgeschuetzten Bereich(*1) nur einmal Speicher verbraucht und der schreibbare Bereich(*2) verdoppelt sich, sobald einer der Prozesse schreibend darauf zugreift.
(*1)Funktionen und Konstanten (*2)Variablen und Link-Pointer in der Symboltabelle (auch Variablen, aber versteckte)
!!Und das gilt sowohl, wenn Kernel+ldlinux.so die Arbeit machen, als auch, wenn ich libdl benutze. Ich sehe jetzt also wirklich keinen Unterschied ausser dem Zeitpunkt(*).
(*)Nur fuer Experten: mit libdl hat man etwas mehr Kontrolle ueber die Sichtbarkeit der Symbole, aber das tut hier nix zur Sache.
Natuerlich ist das so unpraktisch, dass das kein Mensch macht. Zur Klaerung der Begriffe ist die Betrachtung aber sinnvoll.
Erklaer mal.
Was du zu erklaeren versuchst ist eine "dynamisch ladbare Bibliothek" Das diese meist gleichzeitig auch shared lib ist, liegt aus praktischen Gruenden auf der Hand, ist aber nicht zwingend.
Wie jetzt? DLL (Du nennst es deutsch "dynamisch ladbare Bibliothek") und shared lib und shared object sind das selbe, die Begriffe sagen das selbe aus, sie haben den selben Zweck, die Dateien sehen gleich aus (beide koennen a.out oder WinDLL oder ELF oder xyz_et_cetera sein). Kurz: sieht aus wie Rollmops, schmeckt wie Rollmops, ist Rollmops. ;-)
Ich verstehe wirklich nicht, worauf Du hinaus willst.
Also nur Haarspalterei, da es sich um die selbe Datei handelt.
Naja, so langsam wurde in diesem Thread alles durcheinanderegehauen.
Bring mal Ordnung rein!
mit .so Dateien habe ich zwei Moeglichkeiten: a) sie per Headerdatei einbinden und den Linker einen Eintrag in mein Program machen lassen, der von Kern als "ladt das Ding fuer mich, weil ich zu faul dazu bin" interpretiert wird. b) ich oeffne sie per dlopen(3) und lasse mir (Funktions-)Pointer auf die Symbole darin geben und rufe die entsprechenden Pointer auf
Der Witz bei Variante b) ist mMn, dass man eigentlich nur den Namen einer Funktion kennen muss (sowas wie ListFunctionNames()) und damit dann Funktionen laden kann, deren Namen zur Compilezeit des Hauptprogramms noch gar nicht bekannt waren. Das geht mit dem Mechanismus in a) nicht.
(ich habe Mechanismus b) noch nicht benutzt. Stimmt das, was ich hier gesagt habe? Stefan G.???)
Im Grunde ist es richtig, aber Du solltest auch wissen, welche Parameter Du brauchst, sonst bekommst Du einen netten SIGSEGV (auch unter dem Pseudonym "signal 11" bekannt). Es funktioniert etwa so:
--------------------- #include <dlfcn.h>
... void *handle=dlopen("libNixWeiter.so",RTLD_GLOBAL|RTLD_NOW);
if(handle==NULL)/*is schiefgegangen, keine libNixWeiter vorhanden*/ exit(1);
void (*somefunc)()=dlsym(handle,"soEineFunktion");
if(somefunc!=NULL) /*rufen wir das Teil mal auf:*/ somefunc();
/*aus der Spuk:*/ dlclose(handle); ----------------------
Mit Variablen geht es aehnlich, Du must immer nur den richtigen Pointertyp (oder Cast) anwenden.
Nachteil der Sache: man kann sich ganz leicht in den Pointern verheddern und stolpert ueber Segfaults. Ausserdem wird das Debugging anspruchsvoller (zumindest fuer den Debugger).
Und: beim compilieren musst Du gewaltig mit Flags um Dich schmeissen, weil der Code bestimmte zusaetzliche Bedingungen erfuellen muss, damit es funzt (-fPIC ist noch das harmloseste ;-) ).
Und: bei C++ hoert der Spass auf! Die Symbole werden echt grausam (Beispiel gcc 2.7.3, main: main_PPci). (Es gibt auch dafuer Workarounds...)
Konrad
On Fri, Nov 17, 2000 at 10:47:24PM +0100, Konrad Rosenbaum wrote:
On Friday 17 November 2000 19:57, Reinhard Foerster wrote:
On Fri, Nov 17, 2000 at 04:59:01PM +0100, Konrad Rosenbaum wrote:
Als s.object bezeichnet man das Teil, wenn man es gerade kompiliert oder _nur_ zur Laufzeit laedt.
Als s.lib bezeichnet man es, wenn es vom ELF-Loader im Kernel gerade geladen wird.
Falsche Defi. Gegenbeispiel: Bei a.out-Linux gibt es auch shared libs und diese werden nicht von einem "ELF-Loader" in den Kernel geladen. q.e.q.
[das heisst q.e.d. - oder?]
ja, Tippfehler, sorry
Wer hat was von "in den Kernel" gesagt? Der ELF Loader sitzt nur im Kernel, legt die Daten aber in den Userspace.
Du hast gesagt "vom ELF-Loader im Kernel gerade geladen", und das ist numal keine Defi fuer shared fuer shared libs.
Der Begriff "shared lib" sagt UEBERHAUPT NICHTS über das Wann und Wie des Linkens und Ladens aus. Shared sagt einfach nur, dass die Lib bei Nutzung durch mehrere Anwendungen nur einmal im Speicher rumlungert.
Irgendwie versuchen wir hier mit unterschiedlichen Worten das selbe zu sagen...
Den Eindruck habe ich nicht.
Du kannst also auch eine System mit shared libs bauen, die in jedem Binary (also mehrmals) vorhanden sind und trotzdem shared sind.
(Deswegen _shared_ lib oder? ;-) )
aha
Haeh? Erklaer mal anhand von Dateien und Funktionen was Du meinst.
Boah, ich schreibe doch schon Romane.
Natuerlich ist das so unpraktisch, dass das kein Mensch macht. Zur Klaerung der Begriffe ist die Betrachtung aber sinnvoll.
Erklaer mal.
Habe ich eben gemacht. du hast den relevanten Teil nur nicht gequotet.
Was du zu erklaeren versuchst ist eine "dynamisch ladbare Bibliothek" Das diese meist gleichzeitig auch shared lib ist, liegt aus praktischen Gruenden auf der Hand, ist aber nicht zwingend.
Wie jetzt? DLL (Du nennst es deutsch "dynamisch ladbare Bibliothek") und shared lib und shared object sind das selbe, die Begriffe sagen das selbe aus, sie haben den selben Zweck, die Dateien sehen gleich aus (beide koennen a.out oder WinDLL oder ELF oder xyz_et_cetera sein).
Sorry, so langsam habe ich den Eindruck, dass du nicht lesen kannst oder willst. Oben steht von mir
Das diese meist gleichzeitig auch shared lib ist
wobei ^^^^^ das fuer "dynamisch ladbare Bibliothek" steht - OK?
Wie kannst du mir da unterstellen, das ich "dynamisch ladbare Bibliotheken" und shared libs als das gleiche darstelle, wenn ich doch extra hinschreibe, dass sie lediglich _meist_ zusammen auftreten. Ich habe in dem ganzen Thread dafuer geworben, diese beiden Begriffe auseinander zu halten. Und nun faengst du wieder von vorn an. Ich bekommem echt die Krise. Ohne ordentliches Lesen der Argumente anderer führt die Dikussion zu nichts.
Kurz: sieht aus wie Rollmops, schmeckt wie Rollmops, ist Rollmops. ;-)
Na toll.
(ich habe Mechanismus b) noch nicht benutzt. Stimmt das, was ich hier gesagt habe? Stefan G.???)Im Grunde ist es richtig, aber Du solltest auch wissen, welche Parameter Du brauchst, sonst bekommst Du einen netten SIGSEGV (auch unter dem Pseudonym "signal 11" bekannt). Es funktioniert etwa so:
Die Parameter muessen natuerlich dann genau wie die Namen der Funktionen ueber andere vordefinierte Funktionen abfragbar sein.
#include <dlfcn.h>
... void *handle=dlopen("libNixWeiter.so",RTLD_GLOBAL|RTLD_NOW);
if(handle==NULL)/*is schiefgegangen, keine libNixWeiter vorhanden*/ exit(1);
void (*somefunc)()=dlsym(handle,"soEineFunktion");
if(somefunc!=NULL) /*rufen wir das Teil mal auf:*/ somefunc();
/*aus der Spuk:*/ dlclose(handle);
Ja - das ist die Billig-Variante, bei der alle Funktionsnamen bekannt sein muessen. Dafuer wuerde ich nicht dl*() verwenden. Ich wollte dann z.B. ueber "soEineFunktion" ermitteln, was libNixWeiter.so noch so alles anbietet (Funktionsnamen+Parameter), davon dann wieder per dlsym() die Adressen bekommen und die Funktionen nutzen. Erst dann sehe ich eine Sinn in der Nutzung von dl*().
Reinhard
On Saturday 18 November 2000 00:49, Reinhard Foerster wrote:
On Fri, Nov 17, 2000 at 10:47:24PM +0100, Konrad Rosenbaum wrote:
Irgendwie versuchen wir hier mit unterschiedlichen Worten das selbe zu sagen...
Den Eindruck habe ich nicht.
nach dieser Mail ich auch nicht mehr.
Haeh? Erklaer mal anhand von Dateien und Funktionen was Du meinst.
Boah, ich schreibe doch schon Romane.
und Picasso hat grosse Bilder gemalt, deswegen erkennen trotzdem nur Insider, was er gemeint haben koennte. ;-)
Natuerlich ist das so unpraktisch, dass das kein Mensch macht. Zur Klaerung der Begriffe ist die Betrachtung aber sinnvoll.
Erklaer mal.
Habe ich eben gemacht. du hast den relevanten Teil nur nicht gequotet.
ich habe Deine Posting nochmal gelesen, also entweder bin ich zu bloed zum lesen oder es war nicht da oder es war nicht richtig formuliert. Such Dir eine Moeglichkeit aus.
Was du zu erklaeren versuchst ist eine "dynamisch ladbare Bibliothek" Das diese meist gleichzeitig auch shared lib ist, liegt aus praktischen Gruenden auf der Hand, ist aber nicht zwingend.
Wie jetzt? DLL (Du nennst es deutsch "dynamisch ladbare Bibliothek") und shared lib und shared object sind das selbe, die Begriffe sagen das selbe aus, sie haben den selben Zweck, die Dateien sehen gleich aus (beide koennen a.out oder WinDLL oder ELF oder xyz_et_cetera sein).
Sorry, so langsam habe ich den Eindruck, dass du nicht lesen kannst oder willst. Oben steht von mir
Das diese meist gleichzeitig auch shared lib ist
wobei ^^^^^ das fuer "dynamisch ladbare Bibliothek" steht - OK?
Wie kannst du mir da unterstellen, das ich "dynamisch ladbare Bibliotheken" und shared libs als das gleiche darstelle, wenn ich doch extra hinschreibe, dass sie lediglich _meist_ zusammen auftreten. Ich habe in dem ganzen Thread dafuer geworben, diese beiden Begriffe auseinander zu halten. Und nun faengst du wieder von vorn an. Ich bekommem echt die Krise. Ohne ordentliches Lesen der Argumente anderer führt die Dikussion zu nichts.
Ich habe von Dir nirgends eine Definition gefunden. Also definiere jetzt mal bitte ganz klar und deutlich, was bei Dir eine DLL, was ein s.o. und was eine s.l. ist. Du diskutierst hier wehement gegen meine Definition ohne wirklich eine eigene zu bringen - vielleicht gefaellt sie mir ja, aber ich wuerde sie gerne endlich mal kennenlernen. (Oder schick mir Datum und Zeile des Postings, in dem Du das definierst.)
Konrad
On Sat, Nov 18, 2000 at 08:32:47AM +0100, Konrad Rosenbaum wrote:
Ich habe von Dir nirgends eine Definition gefunden. Also definiere jetzt mal bitte ganz klar und deutlich, was bei Dir eine DLL, was ein s.o. und was eine s.l. ist. Du diskutierst hier wehement gegen meine Definition ohne wirklich eine eigene zu bringen - vielleicht gefaellt sie mir ja, aber ich wuerde sie gerne endlich mal kennenlernen. (Oder schick mir Datum und Zeile des Postings, in dem Du das definierst.)
Na gut. Wir haben also 3 Begriffe: Bibliothek, shared, dynamic
1. Das Bibliotheken sind ist unstrittig. DLLs, s.libs und s.objects sind alles Bibliotheken, g.h man kann sich von ihen funktionalitaet "ausleihen" um es mal auf deutsch zu sagen. 2. shared: ( Zitat aus 20001117195750.B7288@rncmm2.urz.tu-dresden.de) ---schnipp---- Der Begriff "shared lib" sagt UEBERHAUPT NICHTS über das Wann und Wie des Linkens und Ladens aus. Shared sagt einfach nur, dass die Lib bei Nutzung durch mehrere Anwendungen nur einmal im Speicher rumlungert. ---schnapp--- 3. dynamic: (wie das D in DLL) meine "Definition" dazu bestand lediglich aus einem Verweis auf Geschreibste voon dir: Dazu die zwei relevanten Abschnitte aus 20001117195750.B7288@rncmm2.urz.tu-dresden.de: ----schnipp----(konrad)
Als s.object bezeichnet man das Teil, wenn man es gerade kompiliert oder _nur_ zur Laufzeit laedt. Als s.lib bezeichnet man es, wenn es vom ELF-Loader im Kernel gerade geladen wird.
----schnapp---- ---schnipp--- (Reinhard, darauf antwortend) Was du zu erklaeren versuchst ist eine "dynamisch ladbare Bibliothek" Das diese meist gleichzeitig auch shared lib ist, liegt aus praktischen Gruenden auf der Hand, ist aber nicht zwingend. ---schnapp--- [ Sprich: Die in deinem Text gebrachten Argumente zu s.object und s.lib sind genau die, die das "dynamic" laden der Funktionalitaet aus einer Bibliothek beschreiben.]
Direkte Folgerungen und zusaetzliche Bemerkungen a) ("shared" != "dynamic") b) !("shared" ==> "dynamic") c) !("dynamic" ==> "shared")
mit != Ungleichheit ! Negation ==> Implikation
Üblicherweise unter Linux: * s.lib: shared, dynamic * s.object: shared, dynamic * DLL: gibts nicht, in Windows wahrscheinlich wie s.lib oder s.object nutzbar
Jetz bleibt fuer die Defi nur noch der UNterschied zwischen s.object und s.lib uebrig und den hast du ordentlich beschrieben. Nur das was ich dazu mit den zur Compilezeit nich nicht festgelegten Namen meinte, war dir erst unklar. DAzu schriebst du nun:
Dann musst Du den ganzen Krempel ja selbst in deine Funktion einprogrammieren! Das ist nun wirklich kompliziert gedacht. Einfacher sind Factories, was aber nur bei OO geht. Oder Du hast halt ein eindeutiges Interface definiert und wenn sich die dll nicht dran haelt wird sie eben in deinem Proggy nicht genutzt (AFAIK macht das Netscape so).
Ausserdem kannst Du Dir statt der Funktionsnamen dann auch gleich Pointer geben lassen (das waere dann sogar sicherer).
Aha. Jetz hast du mich verstanden. Ich will mal ein Beispiel mache, um den Sinn zu zeigen. Wir, die Firma "HardcoreSecurity AG" kurz "HCSAG" wollen ein Mailprogramm schreiben (natuerlich grafisch :) und Kryptokrempel einbauen. Wir wollen dem Nutzer freistellen, einen aus vielen symmetrischen Blockchiffren selbst auszuwählen.
Diesen Kryptoteil liefern wir gruppiert, als mehrere s.objects (also in mehreren .so-Files) aus. Damit müssen wir je nach Rechtslage im Land des Käufers nur ein paar .so-Files mehr oder weniger für die Kryptoalgos in die Kist mitliefern und nicht jedesmal das Programm neu linken. Auf der Festplatte des Nutzers sehen die dann z.B. so aus:
/opt/supermail/bin/supermail /opt/supermail/lib/symalgos/amistd.so /opt/supermail/lib/symalgos/made_by_hcsag.so /opt/supermail/lib/symalgos/other.so
In jede lib kommt eine Funktion namens char* GetSymAlgos() die alle symmetrischen Verfahren dieser Lib sals Kurznamen auflistet. Sie liefert: bei amistd.so "DES,3DES,AES" bei made_by_hcsag.so "DUALROT13,DONOTHING,XOR0,XOR1,REVERS) bei other.so: "IDEA,BLOWFISH,TWOFISH"
Fuer jeden Algo XXX *müssen* in der jeweiligen Lib noch einige Funktioen drin sein z.B. char* Crypt_XXX_GetDescription(char*) int Crypt_XXX_GetBlockSize(); int Crypt_XXX_DoCrypt(void *block, int blocksize, void* key, ...) int Crypt_XXX_DoDecrypt(void *block, int blocksize, void* key, ...) ...
Nun kann das E-Mail-Programm per opendir()+readdir() nachschauen, welche Kryptolibs installiert sind, und anhand dieser Infos eine tolle SelectBox aufwerfen in der sich der Nutzer einen der 9 Algos raussuchen kann. (Wir sorgen natuerlich dafür, dass die Algos aus made_by_hcsag.so ganz oben in der Liste stehen.)
Wie es dann weitergeht sollte klar sein. Das kann man nur mit sogenannten s.objects machen nicht mir s.libs.
Reinhard
On Sat, Nov 18, 2000 at 12:04:39PM +0100, Reinhard Foerster wrote:
Aha. Jetz hast du mich verstanden. Ich will mal ein Beispiel mache, um den Sinn zu zeigen. Wir, die Firma "HardcoreSecurity AG" kurz "HCSAG" wollen ein Mailprogramm schreiben (natuerlich grafisch :) und Kryptokrempel einbauen. Wir wollen dem Nutzer freistellen, einen aus vielen symmetrischen Blockchiffren selbst auszuwählen.
Diesen Kryptoteil liefern wir gruppiert, als mehrere s.objects (also in mehreren .so-Files) aus. Damit müssen wir je nach Rechtslage im Land des Käufers nur ein paar .so-Files mehr oder weniger für die Kryptoalgos in die Kist mitliefern und nicht jedesmal das Programm neu linken. Auf der Festplatte des Nutzers sehen die dann z.B. so aus:
/opt/supermail/bin/supermail /opt/supermail/lib/symalgos/amistd.so /opt/supermail/lib/symalgos/made_by_hcsag.so /opt/supermail/lib/symalgos/other.so
In jede lib kommt eine Funktion namens char* GetSymAlgos() die alle symmetrischen Verfahren dieser Lib sals Kurznamen auflistet. Sie liefert: bei amistd.so "DES,3DES,AES" bei made_by_hcsag.so "DUALROT13,DONOTHING,XOR0,XOR1,REVERS) bei other.so: "IDEA,BLOWFISH,TWOFISH"
Fuer jeden Algo XXX *müssen* in der jeweiligen Lib noch einige Funktioen drin sein z.B. char* Crypt_XXX_GetDescription(char*) int Crypt_XXX_GetBlockSize(); int Crypt_XXX_DoCrypt(void *block, int blocksize, void* key, ...) int Crypt_XXX_DoDecrypt(void *block, int blocksize, void* key, ...) ...
Nun kann das E-Mail-Programm per opendir()+readdir() nachschauen, welche Kryptolibs installiert sind, und anhand dieser Infos eine tolle SelectBox aufwerfen in der sich der Nutzer einen der 9 Algos raussuchen kann. (Wir sorgen natuerlich dafür, dass die Algos aus made_by_hcsag.so ganz oben in der Liste stehen.)
Wie es dann weitergeht sollte klar sein. Das kann man nur mit sogenannten s.objects machen nicht mir s.libs.
Geht auch, ohne daß man die Namen der Crypto-Funktionen kennt.
Voraussetzung: a) jeder Krypto-Algorithmus hat eine eigene Bibliothek. b) jede Bibliothek hat zusätzlich noch die Funktion getName(). c) alle Bibliotheken haben bestimmte Funktionen (die, die Reinhard genannt hat, aber ohne dieses komische "_XXX_" :))
Vorgehensweise: 1. Programm geht nach /opt/supermail/lib (häßlicher Pfad, seit wann benutzt du Suse?) 2. Programm liest alle Dateinamen 3. Program behandelt (alle auftretenden Fehler abfangend) alle Dateien als Krypto-Bibliotheken und ruft jeweils getName() auf. 4. Programm präsentiert Benutzer seine Auswahl. 5. Programm ruft die entsprechenden Funktionen in der ausgewählten Bibliothek auf.
Der einzige Nachteil, den ich in dieser Vorgehensweise sehe, ist die Tatsache, daß jeder Benutzer neue Krypto-Bibliotheken ohne großen Aufwand programmieren und einfügen kann, aber hier heißt ja keiner M$ :). Außerdem kann man das durch Hardkodieren der Bibliotheken im Hauptprogramm verhindern.
Reinhard
Ulf
On Sat, Nov 18, 2000 at 04:53:23PM +0100, Ulf Lorenz wrote:
Geht auch, ohne daß man die Namen der Crypto-Funktionen kennt.
Die musste man ja eben in meinem Beispiel nicht kennen. .Das war ja der Witz an der Sache.
Voraussetzung: a) jeder Krypto-Algorithmus hat eine eigene Bibliothek. b) jede Bibliothek hat zusätzlich noch die Funktion getName().
Genauso wie bei mir. (OK, ich habe sie gruppiert)
c) alle Bibliotheken haben bestimmte Funktionen (die, die Reinhard genannt hat, aber ohne dieses komische "_XXX_" :))
Ja. Wenn an die Algos nicht gruppiert wie bei mir, kann man die XXX weglassen. Da meine Funktionaname auch zur Laufzeit ermittelt wurden, ist das genau das gleiche wie bei dir. Eben ein snprintf() mehr.
Vorgehensweise:
- Programm geht nach /opt/supermail/lib (häßlicher Pfad, seit wann
benutzt du Suse?)
Ich glaube /opt/<programmname> ist der generische Pfad für 3rd party software.
- Programm liest alle Dateinamen
- Program behandelt (alle auftretenden Fehler abfangend) alle Dateien
als Krypto-Bibliotheken und ruft jeweils getName() auf. 4. Programm präsentiert Benutzer seine Auswahl. 5. Programm ruft die entsprechenden Funktionen in der ausgewählten Bibliothek auf.
Jetzt frage ich mich, was du ausser dem Weglassen der XXX anders gemacht hast als ich. Ich glaube ich sollte aufhören, umfangreiche Antworten auf irgendwelche Fragen zu geben. Es hat entweder keiner Lust, die Dinger zu lesen, oder ich druecke mich zu beschert aus. In beiden Faellen ist mein Geschreibse sinnlos - OK.
Der einzige Nachteil, den ich in dieser Vorgehensweise sehe, ist die Tatsache, daß jeder Benutzer neue Krypto-Bibliotheken ohne großen Aufwand programmieren und einfügen kann, aber hier heißt ja keiner M$ :).
Ist doch gut, wenn der Nutzer (oder Admin) das kann. Ich halte die Produkte von MS nicht gerade fuer ein Paradebeispiel von Software, die man als Nutzer einfach erweitern kann. Insofern kapiere ich den Verweis auf MS nicht.
Außerdem kann man das durch Hardkodieren der Bibliotheken im Hauptprogramm verhindern.
Als Sicherheitsstrategie???
Reinhard
On Sat, Nov 18, 2000 at 05:07:43PM +0100, Reinhard Foerster wrote:
On Sat, Nov 18, 2000 at 04:53:23PM +0100, Ulf Lorenz wrote: Jetzt frage ich mich, was du ausser dem Weglassen der XXX anders gemacht hast als ich. Ich glaube ich sollte aufhören, umfangreiche Antworten auf irgendwelche Fragen zu geben. Es hat entweder keiner Lust, die Dinger zu lesen, oder ich druecke mich zu beschert aus. In beiden Faellen ist mein Geschreibse sinnlos - OK.
Sorry, hatte die Hälfte deiner Mail wieder vergessen, als ich den Brief geschrieben habe :). Um's kurz zu machen, zumindest ich hab jetzt kapiert, was du willst.
Der einzige Nachteil, den ich in dieser Vorgehensweise sehe, ist die Tatsache, daß jeder Benutzer neue Krypto-Bibliotheken ohne großen Aufwand programmieren und einfügen kann, aber hier heißt ja keiner M$ :).
Ist doch gut, wenn der Nutzer (oder Admin) das kann. Ich halte die Produkte von MS nicht gerade fuer ein Paradebeispiel von Software, die man als Nutzer einfach erweitern kann. Insofern kapiere ich den Verweis auf MS nicht.
Sollte heißen, hier heißt keiner M$, also hat es auch keiner nötig, sich irgendwelche Gedanken über nicht erweiterbare Software zu machen. Tut mir leid, wenn ich um ein paar Ecken mehr gedacht habe als du.
Außerdem kann man das durch Hardkodieren der Bibliotheken im Hauptprogramm verhindern.
Als Sicherheitsstrategie???
Einige Leute finden das ja ganz toll (namentlich wieder M$). Security by Obscurity.
Reinhard
Ulf
On Saturday 18 November 2000 00:49, Reinhard Foerster wrote:
On Fri, Nov 17, 2000 at 10:47:24PM +0100, Konrad Rosenbaum wrote:
(ich habe Mechanismus b) noch nicht benutzt. Stimmt das, was ich hier gesagt habe? Stefan G.???)Im Grunde ist es richtig, aber Du solltest auch wissen, welche Parameter Du brauchst, sonst bekommst Du einen netten SIGSEGV (auch unter dem Pseudonym "signal 11" bekannt). Es funktioniert etwa so:
Die Parameter muessen natuerlich dann genau wie die Namen der Funktionen ueber andere vordefinierte Funktionen abfragbar sein.
Nenn mir bitte welche. Die einzige Moeglichkeit, die mir noch einfiele waere die libELF, aber da steht auch nix ueber Parameter drin.
Dreimal darfst Du raten, warum in C immer nur 1 Symbol mit einem Namen existieren darf und nicht mehrere wie in C++ (das ja bekanntlich scheusliche Symbolnamen in die Dateien eintraegt).
#include <dlfcn.h>
... void *handle=dlopen("libNixWeiter.so",RTLD_GLOBAL|RTLD_NOW);
if(handle==NULL)/*is schiefgegangen, keine libNixWeiter vorhanden*/ exit(1);
void (*somefunc)()=dlsym(handle,"soEineFunktion");
if(somefunc!=NULL) /*rufen wir das Teil mal auf:*/ somefunc();
/*aus der Spuk:*/ dlclose(handle);
Ja - das ist die Billig-Variante, bei der alle Funktionsnamen bekannt sein muessen. Dafuer wuerde ich nicht dl*() verwenden. Ich wollte dann z.B. ueber "soEineFunktion" ermitteln, was libNixWeiter.so noch so alles anbietet (Funktionsnamen+Parameter), davon dann wieder per dlsym() die Adressen bekommen und die Funktionen nutzen. Erst dann sehe ich eine Sinn in der Nutzung von dl*().
Dann musst Du den ganzen Krempel ja selbst in deine Funktion einprogrammieren! Das ist nun wirklich kompliziert gedacht. Einfacher sind Factories, was aber nur bei OO geht. Oder Du hast halt ein eindeutiges Interface definiert und wenn sich die dll nicht dran haelt wird sie eben in deinem Proggy nicht genutzt (AFAIK macht das Netscape so).
Ausserdem kannst Du Dir statt der Funktionsnamen dann auch gleich Pointer geben lassen (das waere dann sogar sicherer).
Oder faellt Dir irgendeine bessere Bibliothek als libdl ein?
Konrad
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Eric Schaefer -
Hilmar Preusse -
Josef Spillner -
Konrad Rosenbaum -
Reiner Klaproth -
Reinhard Foerster -
Stephan Goetter -
Ulf Lorenz