DLL en C++ pour Windows et Linux

On Mon, 1 Mar 2004 19:11:13 +0100, "Monzer Youssef"
<monzer.youssef@tiscali.fr> wrote:

je cherche à écrire une dll en C++ ANSI qu'on puisse utiliser à la fois sous
Windows et sous Linux ou autre plateforme.

Ça me paraît impossible -- à moins de compiler le code pour Windows et
pour Linux, et de mettre les deux ensemble en bidouillant. Cf
fr.comp.os.ms-windows.programmation (et l'équivalent Linux) pour avoir
tous les détails bien gore...

--
;-)

Monzer Youssef wrote:

Salut tout le monde,
Bonjour.

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...)
Les librairies dynamiques existent sous Linux. Ca s'appelle des .so.

. Comment faire alors en sorte que mon
programme soit compilable en une "librairie dynamique" et utilisable
sous windows et Linux ou autre???
Pour commencer, pourquoi vouloir en faire une librairie dynamique

exactement?

Ensuite, ca risque d'être assez compliqué car les modèles des DLL et des .so
sont très différents : une DLL n'exporte que les symboles que tu spécifies
(généralement à l'aide d'extensions non standard dans le source :
__declspec(dllexport) et consort), alors qu'un .so exporte automatiquement
tous les symboles publics

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.
Ceci dit tu peux toujours avoir une source commune, mais le travail autour,
pour la chaine de compilation, l'environnement, etc... risque d'être assez
important et assez crade (avec pleins de #ifdef dans tous les sens).

Une DLL doit elle obligatoirement avoir un point d'entrée?
<spécifique Windows> Il y a une fonction DllMain, mais le compilo en génère

une pour toi si ton code n'en a pas. Et ce n'est pas "point d'entrée" au
sens où tu l'entends. </spécifique>

Si oui
peut on utiliser la fonction main comme un point d'entrée???
Non : la logique d'une librairie est totalement différente : il n'y a pas de

point d'entrée au sens "première fonction exécutée".

Arnaud

Merci infiniment pour toutes ces précisieuses informations ;) ...
Donc si je comprends bien il vaut mieux faire un travail pour chaque
plateforme?!

Pouvez vous me conseiller des sites où l'on traite des dlls en long, en
large en détail pour bien
maitriser ce concept, qui, je trouve, n'est pas très bien documenté
(notamment constaté
par mes infructueuses recherches sur le moteur google...)

Encore une fois merci a tous pour toutes vos précisions et je suis biensur
toujours ouvert
à d'autres...


"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message de
news:40439c80$0$28137$636a15ce@news.free.fr...

Monzer Youssef wrote:

Salut tout le monde,
Bonjour.

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...)
Les librairies dynamiques existent sous Linux. Ca s'appelle des .so.

. Comment faire alors en sorte que mon
programme soit compilable en une "librairie dynamique" et utilisable
sous windows et Linux ou autre???
Pour commencer, pourquoi vouloir en faire une librairie dynamique

exactement?

Ensuite, ca risque d'être assez compliqué car les modèles des DLL et des
.so

sont très différents : une DLL n'exporte que les symboles que tu spécifies
(généralement à l'aide d'extensions non standard dans le source :
__declspec(dllexport) et consort), alors qu'un .so exporte automatiquement
tous les symboles publics

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.
Ceci dit tu peux toujours avoir une source commune, mais le travail
autour,

pour la chaine de compilation, l'environnement, etc... risque d'être assez
important et assez crade (avec pleins de #ifdef dans tous les sens).

Une DLL doit elle obligatoirement avoir un point d'entrée?
<spécifique Windows> Il y a une fonction DllMain, mais le compilo en

génère

une pour toi si ton code n'en a pas. Et ce n'est pas "point d'entrée" au
sens où tu l'entends. </spécifique>

Si oui
peut on utiliser la fonction main comme un point d'entrée???
Non : la logique d'une librairie est totalement différente : il n'y a pas

de

point d'entrée au sens "première fonction exécutée".

Arnaud

"Monzer Youssef" <monzer.youssef@tiscali.fr> a écrit ...

Salut tout le monde,

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???
Comme le signale Arnaud Debaene, il existe les objets partagés, .so, sous

Linux.
Il semble que Borland propose des solutions pour gérer Dll et .so en
parallèle, ou convertir des Dll en .so, mais je crois que ce n'est pas
immédiat :-(.
Voyez Kylix3 (version Open Source libre pour Linux), qui impose un
compilateur et certainement au moins C++Builder pour travailler en parallèle
sous Windows.
C++BuilderX quant à lui gère plusieurs compilateurs, sous Windows, Linux et
Solaris. C'est certainement proche de l'idéal pour vous, ça coute 11 euros,
mais la version 1.0 actuelle est un peu beta de chez beta. Personnellement,
j'adore, mais c'est à vous de voir. Les sites intéressant sont par exemple
ceux de Borland (étonnant, non?), Diffus'log et Developpez.com (l'aventure
commence par Google).

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???
Une DLL doit avoir un dllMain et un dllEntryPoint, mais peu importe, il y a

quelques autres contraintes, votre question est un peu prématurée. Il vous
faudra une documentation Windows pour étudier le mécanisme de l'écriture et
du chargement des DLL. Vous partirez certainement d'un squelette de DLL. De
toutes façons, votre outil de développement doit intégrer les libs windows
(windows.h) et le lieur être à même de générer un .DLL. Par exemple, outre
le produit cité plus haut, DevC++4 vous propose de créer un projet DLL, soit
en C, soit en C++. En fait, il génère des squelettes pour un projet DLL et
pour un projet de test de la DLL.

Pierre

Monzer Youssef wrote:

Merci infiniment pour toutes ces précisieuses informations ;) ...
Donc si je comprends bien il vaut mieux faire un travail pour chaque
plateforme?!
Oui en non : ton source peut fondamentalement rester le même.

Pouvez vous me conseiller des sites où l'on traite des dlls en long,
en large en détail
Pars de là et suis tous les liens :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_libraries.asp?frame=true

Mais encore une fois : Pourquoi veux-tu faire des librairies dynamiques
exactement ?

Arnaud

"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:<40439c80$0$28137$636a15ce@news.free.fr>...

Monzer Youssef wrote:

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...)

Les librairies dynamiques existent sous Linux. Ca s'appelle des .so.

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. Et le concepte existe
depuis prèsqu'autant que je me souviens : je l'au vu en 1978 sur
Perkin-Elmer OS 32, et évidemment, ça fait partie de Sun OS depuis le
début.

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.

L'utilité aujourd'hui en est bien moindre, et correspond à des
sémantiques du programme bien précises. La première question à poser,
alors, c'est pourquoi est-ce qu'on veut une DLL ?

. Comment faire alors en sorte que mon programme soit compilable en
une "librairie dynamique" et utilisable sous windows et Linux ou
autre???

Pour commencer, pourquoi vouloir en faire une librairie dynamique
exactement?

Tout à fait.

Ensuite, ca risque d'être assez compliqué car les modèles des DLL et
des .so sont très différents : une DLL n'exporte que les symboles que
tu spécifies (généralement à l'aide d'extensions non standard dans le
source : __declspec(dllexport) et consort), alors qu'un .so exporte
automatiquement tous les symboles publics

Sauf qu'on peut aussi utiliser un fichier à part (un .def ?) pour les
symboles à exporter sous Windows, ce qui fait que les sources Windows et
Unix seront identiques (et le .def serait ignoré par le compilateur
Unix), et on peut aussi limiter les symboles qu'on importe sous Unix,
lors de l'appel à dlopen. Dans la pratique, soit au moyen des macros
pour les mots clés d'extension, soit au moyen d'un fichier .def, et en
prêtant un peu d'attention à ce qu'on fait, il est tout à fait possible
à faire des objets dynamiques qui sont à peu près portable. Mais le
comment dépend largement à ce qu'on veut faire avec les objets
dynamiques.

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++ ; 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.

Ceci dit tu peux toujours avoir une source commune, mais le travail
autour, pour la chaine de compilation, l'environnement, etc... risque
d'être assez important et assez crade (avec pleins de #ifdef dans tous
les sens).

Je ne vois pas le moindre besoin d'un #ifdef. En revanche, c'est certain
que la chaîne de production (les makefiles, etc.) risque d'être fort
différente. Mais ça c'est vrai même sans les objets dynamiques. (J'avais
un exemple simple avant -- il n'y avait qu'une fonction qui différait
entre Windows et Solaris. Mais la version Windows semble s'être perdue
lors de l'installation de Windows XP à la place de Windows NT sur ma
machine.)

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

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.

--
;-)

"Fabien LE LEZ" <gramster@gramster.com> a écrit ...

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.
Une caractéristique des Dll sous Windows, qui rappelons-le peuvent contenir

des fonctions mais également des ressources pures, est qu'elles sont
projetées (c'est comme ça que je traduis "mapped") dans l'espace d'adressage
de chaque processus client. Cette possibilté leur est exclusive, et il
faudra en parfois en écrire pour utiliser normalement les possibilités de
l'OS: c'est par exemple dans une Dll que doit être écrite toute fonction de
callback fournie à Windows. Pour les librairies dynamiques partagées des
autres OS, je suis incompétent.
Ceci dit, en dehors de ces cas imposés par l'API Windows (hook clavier,
parfois utile, par exemple), et de cas un peu spéciaux, je ne vois que des
emmerdements à tirer de l'utilisation de Dll, tout comme de celle de la base
de registre (les .ini fonctionnent très bien).
Pierre

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.

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. On peut aussi citer bien sûr:
- la réalisation de plugins.
- l'injection de code dans un processus tierce.
- .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.

<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.

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
- 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 threading : que se passe-t-il pendant le chargement d'un module
vis-à-vis des threads du programme?
- <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.

Arnaud

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?

Arnaud