Hallo und vielen Dank Reiner , so weit ich informiert bin shared libs sind dafür da um den Speicherbedarf und ladezeit der Bibliotheken gering zuhalten, da diese von mehrere Programmen parallel benutzt werden können. Selbst bei der Windofs versionen hat man ständig bis vor kurzem die VB-Bibliotheken gleich mit dem programm liefern müssen, da diese von version zu version unterschiedlich waren. Dies hat den hintergrund, dass der linker so genannte Symbol adressen berechnet und festgehalten hat, jetzt geht man her und ändert den Bibiothek so stimmen die alle adressen nicht mehr und daher können die programme ohne damaligen (Linkzeit) bibliothek nicht funktionieren. Diese wird noch klarer wenn man bei bilden eines bibliothekes Listing mit erzeugt und nach kurze änderung es vergleicht. Aber das mit dem nachliefern der Teile als so genannten Komponents (M$) ist was anderes. Da diese über Interface ansprechbar sind und der Linker merkt sich ein Nummer (Interface ID) und spricht diese anhand sein eindeutigen ID , welches unter M$ registry wieder zufinden ist. hier kann man auch gleich nachschlagen welche Interfaces noch zu einem Bibliothek freigegeben sind. Diese zugriff auf Interfaces geschieht nur im Laufzeit und nicht bei Linken des programmes. Wenn man Sharedlibraries auf diesem weg einsetzen kann, dann habe das gefunden wasich seit lange Zeit suche. Eine frage noch hast du mal versucht auf diese weise vorzu gehen? Ich meine erst ein bibliothek bilden, dann das programm linken. Jetzt wird das bibliothek geändert , und neu gebildet. die frage lautet jetzt ob das programm ohne neu zulinken funktioniert ? ???? wennja dann braucht man ja das Programm bei Update eines programmes nicht mit zuliefern oder ? vielen herzlichen dank Mohammad Am Montag, 20. Januar 2003 09:10 schrieb Rinke, Reiner:
Hallo Mohammed, die beschriebene Funktionalitaet (Austausch von Funktionalitaet ohne Neukompilation) wird ja z.T. auch von DLLs (auf Win-Plattformen) bzw. shared object libraries (auf UNIX-Plattformen) abgedeckt: und diese Mechanismen sind etabliert, standardisiert und der Portieraufwand ist begrenzt. Habe damit jedenfalls gute Erfahrungen gemacht.
-----Original Message----- From: mohammad Gharbalchi [mailto:mohammad@ghbss.de] Sent: Sonntag, 19. Januar 2003 19:36 To: suse-programming@suse.com Subject: Re: ATL/COM -> LINUX
seine projekte benutzt hat, profitieren von so nem technologie, den brauchst nur den komponent zu erweitern/koregieren und schon der fehler ist auch bei alten projekten sofort koregiert ohne die neu zu übersetzen :-)
ich such e nach eine Technologie um das selbe unter Linux zuhaben. und wenn so etwas nicht gibt, wäre ein gutes grund um so was zu schreiben. (Würde mich daran machen)
Omniorb, kenne ich. IMHO auch bei Suse dabei. Mag' mich aber auch Irren (kann auch debian sein :)).
Bye
Andre
Hallo , bei ATL/COM gehts eigentlich darum die Objekte anstatt direkt anzusprechen tut man es bei s.g. Nummern welche über ein geheimen weg (M$ :-( ) dazu führen dass man ein objekt erzeugt und diese nur über bestimmte ( bei entwicklung der Komponente frei gegebene ) Interfaces ansprechen kann. Da diese kommunikation über s.g. IDs ( Nummern) läuft ist man nicht an festen adressen (linker) gebunden und kann jeder Zeit (sogar dynamisch Laufzeit) aktuelle Komponenten erzeugen und einsetzen. d.h. man hat zwar total getrennte teile die unabhängig von ein ander entwickelt unter verteilt werden können. Eine gute beispiel dafür wäre der einsatz von IE in Formularen und dialogen, wenn man diese als COM-Objekt einsetzt und nacher IE updated , braucht man gar nichts mehr tun das geschieht dann automatisch. oder auch diese Dialog würde auf verschiedene umgebungen unterschiedlich mächtig oder fehlerhaft sein (je nach installierten externen Komponenten)
hoffe hat dir geholfen , wenn nicht können wir es weiterhin versuchen
schöne Grüsse Mohammad