je cherche à écrire une dll en C++ ANSI qu'on puisse utiliser à la fois sous
Windows et sous Linux ou autre plateforme.
Je sais que normalement une DLL est une spécificité de Windows (enfin c'est
que je crois...) . Comment faire alors en sorte que mon programme soit
compilable en une "librairie dynamique" et utilisable sous windows et Linux
ou autre???
Une DLL doit elle obligatoirement avoir un point d'entrée? Si oui peut on
utiliser la fonction main comme un point d'entrée???
c'est par exemple dans une Dll que doit être écrite toute fonction de callback fournie à Windows. Où as-tu vu çà? Tu penses peut être aux DLLs de hook qui sont injectées
dans
tous les processus? Oui da.
Généralisation outrancière de ma part, je le crains ... Pierre
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit ...
Pierre Maurette wrote:
"Fabien LE LEZ" <gramster@gramster.com> a écrit ...
On 2 Mar 2004 00:57:57 -0800, kanze@gabi-soft.fr wrote:
c'est par exemple dans une Dll
que doit être écrite toute fonction de callback fournie à Windows.
Où as-tu vu çà? Tu penses peut être aux DLLs de hook qui sont injectées
dans
tous les processus?
Oui da.
Généralisation outrancière de ma part, je le crains ...
Pierre
c'est par exemple dans une Dll que doit être écrite toute fonction de callback fournie à Windows. Où as-tu vu çà? Tu penses peut être aux DLLs de hook qui sont injectées
dans
tous les processus? Oui da.
Généralisation outrancière de ma part, je le crains ... Pierre
James Kanze
Fabien LE LEZ writes:
|> On 2 Mar 2004 00:57:57 -0800, wrote:
|> >La première question à poser, alors, c'est pourquoi est-ce |> >qu'on veut une DLL ?
|> La principale utilité des DLL que je vois, du moins sous Windows, |> c'est le cas où l'éditeur de l'exécutable n'est pas |> l'éditeur de la DLL. Exemples : plug-ins, codecs vidéo, ou |> même l'API Win32.
Il y a en fait plusieurs utilisations tout à fait intéressantes ; je ne veux pas dire qu'elles sont sans intérêt. En revanche, il y a aussi beaucoup de monde qui fait des DLL sans raison particulière, et la meilleur façon de s'y prendre dépend de ce qu'on veut en faire.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Fabien LE LEZ <gramster@gramster.com> writes:
|> On 2 Mar 2004 00:57:57 -0800, kanze@gabi-soft.fr wrote:
|> >La première question à poser, alors, c'est pourquoi est-ce
|> >qu'on veut une DLL ?
|> La principale utilité des DLL que je vois, du moins sous Windows,
|> c'est le cas où l'éditeur de l'exécutable n'est pas
|> l'éditeur de la DLL. Exemples : plug-ins, codecs vidéo, ou
|> même l'API Win32.
Il y a en fait plusieurs utilisations tout à fait intéressantes ;
je ne veux pas dire qu'elles sont sans intérêt. En revanche, il y
a aussi beaucoup de monde qui fait des DLL sans raison particulière,
et la meilleur façon de s'y prendre dépend de ce qu'on veut en
faire.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> >La première question à poser, alors, c'est pourquoi est-ce |> >qu'on veut une DLL ?
|> La principale utilité des DLL que je vois, du moins sous Windows, |> c'est le cas où l'éditeur de l'exécutable n'est pas |> l'éditeur de la DLL. Exemples : plug-ins, codecs vidéo, ou |> même l'API Win32.
Il y a en fait plusieurs utilisations tout à fait intéressantes ; je ne veux pas dire qu'elles sont sans intérêt. En revanche, il y a aussi beaucoup de monde qui fait des DLL sans raison particulière, et la meilleur façon de s'y prendre dépend de ce qu'on veut en faire.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
James Kanze
(Arnaud Debaene) writes:
|> wrote in message |> news:...
|> > Je ne connais pas de système où on peut réelement linker |> > les bibliothèques dynamiquement. Ce que Windows appelle un DLL, |> > ce n'est rien d'autre qu'un fichier objet sorti d'une fusion (au |> > moyen d'une édition de liens) de plusieurs objets originaux.
|> Oui et non : en tout cas pour les DLLs, on peut véritablement |> charger dynamiquement le module (LoadLibrary) et faire un "link" au |> runtime (c'est à dire l'association d'un symbole avec une |> adresse) via GetProcAddress.
Je sais, mais ce n'est pas une bibliothèque. Le caractèristique qui définit une bibliothèque, c'est que l'édition de liens n'en extrait que le minimum de ce qu'il faut. Avec une DLL (comme avec un SO sous Unix), c'est du tout ou rien -- exactement comme avec n'importe quel autre fichier objet.
|> > L'utilité au départ était d'économiser de la place |> > disque (et à un moindre dégrée, de la place en mémoire |> > centrale) et faisant partager une partie du programme entre |> > plusieurs programmes -- d'où le nom « shared object » |> > (.so) dans la communité Unix.
|> Aujourd'hui, l'intérêt principal de mon point de vue est |> l'économie de RAM.
Seulement dans le cas où il y a beaucoup de programmes qui utilisent la même DLL et qui s'exéctuent au même temps. C'est sans doute une des justifications (mais pas la seules) pour que l'API de Windows même soit une DLL. Ce n'est pas une raison de saucissoner une application quelconque en des DLLs.
|> On peut aussi citer bien sûr: |> - la réalisation de plugins. |> - l'injection de code dans un processus tierce.
Certes, mais la façon qu'on s'y prend n'est pas pareil selon le cas. Sans savoir pourquoi il veut faire une DLL, c'est difficile à lui dire la meilleur façon de s'y prendre.
|> - .NET utilise également les modules comme frontière de |> sécurité : Chaque module (ou assembly) possède un certain |> nombre de "credentials" liés a son emplacement physique, au fait |> qu'il soit signé ou pas, etc... qui permettent de définir (via |> une politique configurable) ce que le code dans l'assembly à le |> droit de faire ou pas. C'est assez pratique pour un applet |> s'exécutant dans une page web par exemple.
Intéressant. C'est un aspect que je ne connais pas.
|> <snip> |> > Sauf qu'on peut aussi utiliser un fichier à part (un .def ?) |> > pour les symboles à exporter sous Windows,
|> Très lourd en pratique si l'on exporte des classes : il faudrait |> mettre dans le .def les noms manglés de tous les symboles publics |> de la classe. C'est là qu'on sent le très lourd passé "C" |> des DLLs.
Comme j'ai dit, tout dépend de ce qu'on veut faire. Dans mon cas, j'ai fait un espèce de plug-in, avec un seul point d'entrée (qui renvoyait une usine singleton). Dans ce cas-là, un .DEF est impeccable. S'il s'agit de faire une API rélativement complexe, j'imagine que l'autre solution s'impose.
|> > > Ensuite, aussi bien les .so que les DLLs sont conçues pour |> > > une approche essentiellement "C", ce qui veut dire qu'un certain |> > > nombre de comportements du C++, comme les appels des |> > > constructeurs et destructeurs des objets globaux, |> > > l'initialisation du runtime, etc... sont entièrement |> > > définis par l'implémentation et très différentes |> > > d'un cas à l'autre : tout cela rend un portage à mon avis |> > > assez délicat.
|> > Je ne suis pas sûr de te suivre ici. Le concepte d'un objet |> > dynamique est étranger à la norme C aussi bien qu'à la |> > norme C++
|> Tout à fait : mais c'est encore plus embêtant en C++ à |> cause des constructeurs et destructeurs des objets à durée de |> vie statique dans un module dynamiques (quand sont-ils appelés ?)
|> > ; dans les deux |> > cas, les « phases de traduction » (qui comprend l'édition de liens) est |> > quelque chose qui a lieu avant l'execution. Tout ce qui concerne les |> > objets dynamiques dépend donc de l'implémentation.
|> > Dans le cas de Windows et de Solaris (et je suppose que c'est |> > général sous Unix, même si Posix n'en parle pas), un |> > fichier objet contient des ségments de code qui doivent être |> > exécuté lors du démarrage ou de l'arrêt. Dans les deux |> > cas, la fonction de chargement d'un objet dynamique (dlopen sous |> > Posix, LoadLibrary sous Windows) execute le code de démarrage ; |> > dans le cas de Solaris, dlclose execute aussi bien le code |> > d'arrêt (les destructeurs) -- je n'ai pas vérifié le cas |> > sous Windows, mais ça ne m'étonnerait pas que c'est le |> > cas-là aussi.
|> C'est bien le cas, mais reste des questions : |> - de l'ordre d'appels des constructeurs / destructeurs au sein d'un |> module
Tu n'as pas besoin des DLL pour avoir des problèmes là. Ce n'est pas défini, un point, c'est tout.
|> - du fait que l'ordre de chargements des modules n'est pas |> défini, on peut avoir des problèmes de dépendance entre |> objets à durée de vie statiques.
Du fait que l'ordre de l'execution des initialisations des modules n'est pas définie, qu'il s'agit des chargements dynamiques ou non, on peut avoir des problèmes.
|> - du threading : que se passe-t-il pendant le chargement d'un module |> vis-à-vis des threads du programme?
Ça, en revanche, c'est un vrai problème qui me tracasse. Aussi bien sous Unix que sous Windows.
|> - <troll> il y a aussi bien sûr la question de l'export de |> templates :) </troll>
|> Et surtout, tous ces aspects ne sont pas normalisés, donc peuvent |> varier d'un environnement à l'autre.
Surtout, je constate qu'en règle générale, la spécification des interfaces propriètaires est moins complète que celle des normes.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> kanze@gabi-soft.fr wrote in message
|> news:<d6652001.0403020057.1c1238bb@posting.google.com>...
|> > Je ne connais pas de système où on peut réelement linker
|> > les bibliothèques dynamiquement. Ce que Windows appelle un DLL,
|> > ce n'est rien d'autre qu'un fichier objet sorti d'une fusion (au
|> > moyen d'une édition de liens) de plusieurs objets originaux.
|> Oui et non : en tout cas pour les DLLs, on peut véritablement
|> charger dynamiquement le module (LoadLibrary) et faire un "link" au
|> runtime (c'est à dire l'association d'un symbole avec une
|> adresse) via GetProcAddress.
Je sais, mais ce n'est pas une bibliothèque. Le caractèristique
qui définit une bibliothèque, c'est que l'édition de liens n'en
extrait que le minimum de ce qu'il faut. Avec une DLL (comme avec un SO
sous Unix), c'est du tout ou rien -- exactement comme avec n'importe
quel autre fichier objet.
|> > L'utilité au départ était d'économiser de la place
|> > disque (et à un moindre dégrée, de la place en mémoire
|> > centrale) et faisant partager une partie du programme entre
|> > plusieurs programmes -- d'où le nom « shared object »
|> > (.so) dans la communité Unix.
|> Aujourd'hui, l'intérêt principal de mon point de vue est
|> l'économie de RAM.
Seulement dans le cas où il y a beaucoup de programmes qui utilisent
la même DLL et qui s'exéctuent au même temps. C'est sans doute
une des justifications (mais pas la seules) pour que l'API de Windows
même soit une DLL. Ce n'est pas une raison de saucissoner une
application quelconque en des DLLs.
|> On peut aussi citer bien sûr:
|> - la réalisation de plugins.
|> - l'injection de code dans un processus tierce.
Certes, mais la façon qu'on s'y prend n'est pas pareil selon le cas.
Sans savoir pourquoi il veut faire une DLL, c'est difficile à lui
dire la meilleur façon de s'y prendre.
|> - .NET utilise également les modules comme frontière de
|> sécurité : Chaque module (ou assembly) possède un certain
|> nombre de "credentials" liés a son emplacement physique, au fait
|> qu'il soit signé ou pas, etc... qui permettent de définir (via
|> une politique configurable) ce que le code dans l'assembly à le
|> droit de faire ou pas. C'est assez pratique pour un applet
|> s'exécutant dans une page web par exemple.
Intéressant. C'est un aspect que je ne connais pas.
|> <snip>
|> > Sauf qu'on peut aussi utiliser un fichier à part (un .def ?)
|> > pour les symboles à exporter sous Windows,
|> Très lourd en pratique si l'on exporte des classes : il faudrait
|> mettre dans le .def les noms manglés de tous les symboles publics
|> de la classe. C'est là qu'on sent le très lourd passé "C"
|> des DLLs.
Comme j'ai dit, tout dépend de ce qu'on veut faire. Dans mon cas,
j'ai fait un espèce de plug-in, avec un seul point d'entrée (qui
renvoyait une usine singleton). Dans ce cas-là, un .DEF est
impeccable. S'il s'agit de faire une API rélativement complexe,
j'imagine que l'autre solution s'impose.
|> > > Ensuite, aussi bien les .so que les DLLs sont conçues pour
|> > > une approche essentiellement "C", ce qui veut dire qu'un certain
|> > > nombre de comportements du C++, comme les appels des
|> > > constructeurs et destructeurs des objets globaux,
|> > > l'initialisation du runtime, etc... sont entièrement
|> > > définis par l'implémentation et très différentes
|> > > d'un cas à l'autre : tout cela rend un portage à mon avis
|> > > assez délicat.
|> > Je ne suis pas sûr de te suivre ici. Le concepte d'un objet
|> > dynamique est étranger à la norme C aussi bien qu'à la
|> > norme C++
|> Tout à fait : mais c'est encore plus embêtant en C++ à
|> cause des constructeurs et destructeurs des objets à durée de
|> vie statique dans un module dynamiques (quand sont-ils appelés ?)
|> > ; dans les deux
|> > cas, les « phases de traduction » (qui comprend l'édition de liens) est
|> > quelque chose qui a lieu avant l'execution. Tout ce qui concerne les
|> > objets dynamiques dépend donc de l'implémentation.
|> > Dans le cas de Windows et de Solaris (et je suppose que c'est
|> > général sous Unix, même si Posix n'en parle pas), un
|> > fichier objet contient des ségments de code qui doivent être
|> > exécuté lors du démarrage ou de l'arrêt. Dans les deux
|> > cas, la fonction de chargement d'un objet dynamique (dlopen sous
|> > Posix, LoadLibrary sous Windows) execute le code de démarrage ;
|> > dans le cas de Solaris, dlclose execute aussi bien le code
|> > d'arrêt (les destructeurs) -- je n'ai pas vérifié le cas
|> > sous Windows, mais ça ne m'étonnerait pas que c'est le
|> > cas-là aussi.
|> C'est bien le cas, mais reste des questions :
|> - de l'ordre d'appels des constructeurs / destructeurs au sein d'un
|> module
Tu n'as pas besoin des DLL pour avoir des problèmes là. Ce n'est
pas défini, un point, c'est tout.
|> - du fait que l'ordre de chargements des modules n'est pas
|> défini, on peut avoir des problèmes de dépendance entre
|> objets à durée de vie statiques.
Du fait que l'ordre de l'execution des initialisations des modules n'est
pas définie, qu'il s'agit des chargements dynamiques ou non, on peut
avoir des problèmes.
|> - du threading : que se passe-t-il pendant le chargement d'un module
|> vis-à-vis des threads du programme?
Ça, en revanche, c'est un vrai problème qui me tracasse. Aussi
bien sous Unix que sous Windows.
|> - <troll> il y a aussi bien sûr la question de l'export de
|> templates :) </troll>
|> Et surtout, tous ces aspects ne sont pas normalisés, donc peuvent
|> varier d'un environnement à l'autre.
Surtout, je constate qu'en règle générale, la spécification
des interfaces propriètaires est moins complète que celle des
normes.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> > Je ne connais pas de système où on peut réelement linker |> > les bibliothèques dynamiquement. Ce que Windows appelle un DLL, |> > ce n'est rien d'autre qu'un fichier objet sorti d'une fusion (au |> > moyen d'une édition de liens) de plusieurs objets originaux.
|> Oui et non : en tout cas pour les DLLs, on peut véritablement |> charger dynamiquement le module (LoadLibrary) et faire un "link" au |> runtime (c'est à dire l'association d'un symbole avec une |> adresse) via GetProcAddress.
Je sais, mais ce n'est pas une bibliothèque. Le caractèristique qui définit une bibliothèque, c'est que l'édition de liens n'en extrait que le minimum de ce qu'il faut. Avec une DLL (comme avec un SO sous Unix), c'est du tout ou rien -- exactement comme avec n'importe quel autre fichier objet.
|> > L'utilité au départ était d'économiser de la place |> > disque (et à un moindre dégrée, de la place en mémoire |> > centrale) et faisant partager une partie du programme entre |> > plusieurs programmes -- d'où le nom « shared object » |> > (.so) dans la communité Unix.
|> Aujourd'hui, l'intérêt principal de mon point de vue est |> l'économie de RAM.
Seulement dans le cas où il y a beaucoup de programmes qui utilisent la même DLL et qui s'exéctuent au même temps. C'est sans doute une des justifications (mais pas la seules) pour que l'API de Windows même soit une DLL. Ce n'est pas une raison de saucissoner une application quelconque en des DLLs.
|> On peut aussi citer bien sûr: |> - la réalisation de plugins. |> - l'injection de code dans un processus tierce.
Certes, mais la façon qu'on s'y prend n'est pas pareil selon le cas. Sans savoir pourquoi il veut faire une DLL, c'est difficile à lui dire la meilleur façon de s'y prendre.
|> - .NET utilise également les modules comme frontière de |> sécurité : Chaque module (ou assembly) possède un certain |> nombre de "credentials" liés a son emplacement physique, au fait |> qu'il soit signé ou pas, etc... qui permettent de définir (via |> une politique configurable) ce que le code dans l'assembly à le |> droit de faire ou pas. C'est assez pratique pour un applet |> s'exécutant dans une page web par exemple.
Intéressant. C'est un aspect que je ne connais pas.
|> <snip> |> > Sauf qu'on peut aussi utiliser un fichier à part (un .def ?) |> > pour les symboles à exporter sous Windows,
|> Très lourd en pratique si l'on exporte des classes : il faudrait |> mettre dans le .def les noms manglés de tous les symboles publics |> de la classe. C'est là qu'on sent le très lourd passé "C" |> des DLLs.
Comme j'ai dit, tout dépend de ce qu'on veut faire. Dans mon cas, j'ai fait un espèce de plug-in, avec un seul point d'entrée (qui renvoyait une usine singleton). Dans ce cas-là, un .DEF est impeccable. S'il s'agit de faire une API rélativement complexe, j'imagine que l'autre solution s'impose.
|> > > Ensuite, aussi bien les .so que les DLLs sont conçues pour |> > > une approche essentiellement "C", ce qui veut dire qu'un certain |> > > nombre de comportements du C++, comme les appels des |> > > constructeurs et destructeurs des objets globaux, |> > > l'initialisation du runtime, etc... sont entièrement |> > > définis par l'implémentation et très différentes |> > > d'un cas à l'autre : tout cela rend un portage à mon avis |> > > assez délicat.
|> > Je ne suis pas sûr de te suivre ici. Le concepte d'un objet |> > dynamique est étranger à la norme C aussi bien qu'à la |> > norme C++
|> Tout à fait : mais c'est encore plus embêtant en C++ à |> cause des constructeurs et destructeurs des objets à durée de |> vie statique dans un module dynamiques (quand sont-ils appelés ?)
|> > ; dans les deux |> > cas, les « phases de traduction » (qui comprend l'édition de liens) est |> > quelque chose qui a lieu avant l'execution. Tout ce qui concerne les |> > objets dynamiques dépend donc de l'implémentation.
|> > Dans le cas de Windows et de Solaris (et je suppose que c'est |> > général sous Unix, même si Posix n'en parle pas), un |> > fichier objet contient des ségments de code qui doivent être |> > exécuté lors du démarrage ou de l'arrêt. Dans les deux |> > cas, la fonction de chargement d'un objet dynamique (dlopen sous |> > Posix, LoadLibrary sous Windows) execute le code de démarrage ; |> > dans le cas de Solaris, dlclose execute aussi bien le code |> > d'arrêt (les destructeurs) -- je n'ai pas vérifié le cas |> > sous Windows, mais ça ne m'étonnerait pas que c'est le |> > cas-là aussi.
|> C'est bien le cas, mais reste des questions : |> - de l'ordre d'appels des constructeurs / destructeurs au sein d'un |> module
Tu n'as pas besoin des DLL pour avoir des problèmes là. Ce n'est pas défini, un point, c'est tout.
|> - du fait que l'ordre de chargements des modules n'est pas |> défini, on peut avoir des problèmes de dépendance entre |> objets à durée de vie statiques.
Du fait que l'ordre de l'execution des initialisations des modules n'est pas définie, qu'il s'agit des chargements dynamiques ou non, on peut avoir des problèmes.
|> - du threading : que se passe-t-il pendant le chargement d'un module |> vis-à-vis des threads du programme?
Ça, en revanche, c'est un vrai problème qui me tracasse. Aussi bien sous Unix que sous Windows.
|> - <troll> il y a aussi bien sûr la question de l'export de |> templates :) </troll>
|> Et surtout, tous ces aspects ne sont pas normalisés, donc peuvent |> varier d'un environnement à l'autre.
Surtout, je constate qu'en règle générale, la spécification des interfaces propriètaires est moins complète que celle des normes.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
