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