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 -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
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
On Mon, 2003-01-20 at 16:03, mohammad Gharbalchi wrote:
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. Nicht nur, ...
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. Das ist ein wesentlicher Unterschied zw. Unix/Linux und Windows ;)
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. Ich nehme an Du beziehst Dich auf DLLs (Auch diese gab es mal unter Linux - Zu Zeiten von libc4, IIRC; Dateiextension *.sa).
Was hier unter "Shared-Libs" gemeint ist, bezeichnen manche als DSO (Dynamically Shared Objects; Dateiextension *.so). Sie sind nicht nur "shared" sondern auch dynamisch, d.h. sie werden nicht nur (wie DLLs) zwischen mehreren Programmen im Speicher geteilt, sondern zusätzlich noch erst beim Programmstart vom dynamischen Linker (man ld.so, man ldd) dem Programm hinzugebunden.
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. Wie bei Linux Shared-Libs.
Wenn man Sharedlibraries auf diesem weg einsetzen kann, dann habe das gefunden wasich seit lange Zeit suche. Wenn es "nur" um den Aspekt "Interface" geht, ja (Vgl info libtool).
Eine frage noch hast du mal versucht auf diese weise vorzu gehen? Ich meine erst ein bibliothek bilden, dann das programm linken. Ja, täglich ;) Das ist der Normalfall.
Jetzt wird das bibliothek geändert , und neu gebildet. die frage lautet jetzt ob das programm ohne neu zulinken funktioniert ? ???? Mit Shared-Libs, sofern sich das Interface der Lib nicht inkompatibel geändert hat, ja. (Siehe info libtool, Stichwort Versioning).
wennja dann braucht man ja das Programm bei Update eines programmes nicht mit zuliefern oder ? Du meinst, Du tauscht die Bibliothek unterhalb eines Programmes aus, und das Programm funktioniert weiterhin? Dann ja.
Ralf
Hallo , vielen herzlichen dank jetzt weiss ich auch wo ich anfangen soll :-) bin nämlich ziemlich neu bei Linux-Programmirung aber habe lange Zeit unter Windows entwickelt. wenn da referencen gibt , bücher oder so was ähnliches würde mich sofort daran machen. viel danke noch mal an alle besonders an ' Ralf ' Bis dann Mohammad Am Montag, 20. Januar 2003 17:01 schrieb Ralf Corsepius:
On Mon, 2003-01-20 at 16:03, mohammad Gharbalchi wrote:
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.
Nicht nur, ...
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.
Das ist ein wesentlicher Unterschied zw. Unix/Linux und Windows ;)
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.
Ich nehme an Du beziehst Dich auf DLLs (Auch diese gab es mal unter Linux - Zu Zeiten von libc4, IIRC; Dateiextension *.sa).
Was hier unter "Shared-Libs" gemeint ist, bezeichnen manche als DSO (Dynamically Shared Objects; Dateiextension *.so). Sie sind nicht nur "shared" sondern auch dynamisch, d.h. sie werden nicht nur (wie DLLs) zwischen mehreren Programmen im Speicher geteilt, sondern zusätzlich noch erst beim Programmstart vom dynamischen Linker (man ld.so, man ldd) dem Programm hinzugebunden.
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.
Wie bei Linux Shared-Libs.
Wenn man Sharedlibraries auf diesem weg einsetzen kann, dann habe das gefunden wasich seit lange Zeit suche.
Wenn es "nur" um den Aspekt "Interface" geht, ja (Vgl info libtool).
Eine frage noch hast du mal versucht auf diese weise vorzu gehen? Ich meine erst ein bibliothek bilden, dann das programm linken.
Ja, täglich ;) Das ist der Normalfall.
Jetzt wird das bibliothek geändert , und neu gebildet. die frage lautet jetzt ob das programm ohne neu zulinken funktioniert ? ????
Mit Shared-Libs, sofern sich das Interface der Lib nicht inkompatibel geändert hat, ja. (Siehe info libtool, Stichwort Versioning).
wennja dann braucht man ja das Programm bei Update eines programmes nicht mit zuliefern oder ?
Du meinst, Du tauscht die Bibliothek unterhalb eines Programmes aus, und das Programm funktioniert weiterhin? Dann ja.
Ralf
Hallo, On Mon, 20 Jan 2003 at 19:22 (+0100), mohammad Gharbalchi wrote:
Hallo , vielen herzlichen dank jetzt weiss ich auch wo ich anfangen soll :-) bin nämlich ziemlich neu bei Linux-Programmirung aber habe lange Zeit unter Windows entwickelt. wenn da referencen gibt , bücher oder so was ähnliches würde mich sofort daran machen.
vielleicht hilft Dir erstmal http://tldp.org/HOWTO/Program-Library-HOWTO/.
Am Montag, 20. Januar 2003 17:01 schrieb Ralf Corsepius:
On Mon, 2003-01-20 at 16:03, mohammad Gharbalchi wrote: [...]
Gruß, Bernhard -- "Mankind invented the atomic bomb, but no mouse would ever construct a mousetrap." -- Albert Einstein
participants (4)
-
Bernhard Walle -
mohammad Gharbalchi -
Ralf Corsepius -
Rinke, Reiner