Salut tlm
 
J'aurais besoin d'aide pour la creation de dll.
Je ne sais pas comment ca fonctionne, et malgre le msdn j'arrive a me perdre.
Je ne sais pas quel mode d'export je dois utiliser, etc...
Si quelqu'un avait des infos ce serait sympa
 
Merci

alors, deux mode de DLL :
 
Run-time Linking et Load Time Linking
 
les deux voulant dire ce qu'ils veulent dire, et je te conseillerais la deuxieme, moins lourde (mais parfois pas utilisable, bref)
 
Load Time, la DLL est charge automatiquement au lancement de ton prog . si pas trouvable t'as la petite boite
 
Run time, c toi qui fait le chargement, a grand renfort de LoadLibrary et GetProcAdress .  
C plus lourd, mais par exemple ca te permet de faire un moteur 3d utilisant ogl et d3d (sans pour autant devoir code deux moteurs !=, vu que c toi qui choisi quelle DLL utiliser..bref )  
 
Ben sinon, c tout simple a faire, le mieux c'est de faire un project visual "DLL that exports symbols" et dans le code genere t'aura des indications sur comment ca marche (c tout con)
Tu peux exporter ce que tu veux, classe, fonctions etc etc
Tout est decrit dans le code genere
 
donc t'as un .h partage par la DLL et les prog l'appelant, + une DLL (le resultat de la compil) + un.lib (utilise par l'appelant)
 
Ca te fais une joli DLL LoadTime qui va bien
 
vala !
 
 
PS : N'exporte que ce dont tu as besoin, question de clean quoi

[edtdd]--Message édité par chrisbk--[/edtdd]

Ben en fait je dois faire des dll pour un prog dont j'ai pas les sources.
Tu me conseilles quelle mode de DLL ?
 
Putain j'suis completement paumé sur le coup la

Load Time generalement est OK dans 99.99% des cas
sauf si il faut pouvoir choisir entre 2 DLL faisant la meme chose mais de maniere differente

donc
file->new project->DLL->DLL that exports some symbols

Pauvre GodBout, tu sais plus ou t'en est du coup ! et c plutot normal, parce qu'y m'semble que t'as mal compris la question chrisbk. T'expliquerai pas plutot comment utiliser une dll là !?? Non, pour faire un dll, je peux rien faire, g jammais essayé, ms j'voulais juste dire qu'y m'semble que la réponse de chrisbk est a côté sur ce coup là (ce qui remet pas en cause le fait qu'au fil des topics,tu m'a l'air de plutot maitriser chrisbk...)

Ton dernier post, ça serai plus ça.Les autres sont Hors sujet ... non ?

non g pas l'impression d'etre a cote de la plaque mais bon ....
 
note deux trois trucs que g oublier :
 
en run time tu ne peux exporter que des fonctions
en bidouillant tu peux sortir des classes (enfin, des structures avec des fonctions, et dans la DLL ca derive en classe, genre si tu veux un exemple parce que la je suis pas clair, demande)
 
-la memoire alloue par la DLL doit etre desallouer par la DLL
-ne fait transiter aucun pointeur sur des FILE * et consort de la DLL au programme appelant sinon...kaboum

 
 
je decris les deux types de DLL existant
je pense que Mr godbout avait trouver comment dire a visual de faire une DLL, oder ?

Mais ce dont tu parles en fait, c plutot au niveau du chargement de la dll... En fait, c du chargement dynamique ou static, dont tu parles, non ?
Si c ça, y me semble qu'on à pas à s'en occuper pendant qu'on construit la dll, c juste qd on veux l'utiliser qu'on gère ça, non ?

le choix du type de DLL depend des besoins
si tu veux faire des plug in, fo du run time, sinon du loadtime suffit
 
C'est a mon gout la seule chose a reflechir quand tu fais une DLL, car le reste du code ne differe en rien du code normal.
 
Juste savoir quelles sont les fonctions qui doivent etre accessible de l'exterieur. Celles ci doivent etre exportes

pourquoi ne pas tout exporter !?
pour la même raison qu'en objet y faut pas tout mettre en public... sinon c l'bordel !?

Ben pour l'instant j'en suis a choisir entre un truc du genre ___dllexport et un .DEF pour faire je sais pas trop koi.
Chris je cale rien a ce que tu me dis
 
mais c'est surement parce que j'en suis qu'au tout debut

bon, alors faisons tout con (desole je me suis ptet un peu enflammer)
 
 
donc : new project->DLL that export some symbols
ddd comme nom de projet
 
tu va avoir un fichier ddd.h . c'est le .h partage entre DLL et prog appelant avec au debut :
 
 
#ifdef DDD_EXPORTS
#define DDD_API __declspec(dllexport)
#else
#define DDD_API __declspec(dllimport)
#endif
 
 
tout ca, tu touches pas. seulement quand tu veux qu'une fonction soit appelable a partir du prog, tu fais :
 
 
DDD_API void pouet();
 
right?
et ailleurs dans ta DLL :
void pouet()
{
printf("pouet" );
}
 
 
 
 
ou :
class DDD_API Pouet  
{
..blah
}
 
si tu veux qu'une classe tout entiere soit appelable depuis un prog
 
pour le reste, tu codes tes fonctions exactement de la meme facon
 
pas besoin de .def avec ce systeme
 
a la sortie tu aura :
1 DLL
1 LIB a inclure dans le prog appelant
 
c plus clair ?

ouais la c'est deja plus clair !
Je vais essayer tout ca.
Merci

Moi j'ai pas acces au gros programme qui va appeler cette dll.
Il va donc falloir linker le lib.
Mais une fois que ce sera fait, est ce qu'il faudra recompiler le gros programme a chaque fois que la dll aura change ?

heuh attends
 
explique moi bien comment le gros programme va appeler cette DLL ....
 
Parce que avec la loadtime (les exports) fo pouvoir relinker le tout
+evidemment coder les bouts qui appeleront la DLL (enfin, fo bien qu'elle servent, cette petite)
 
Ou y'a un systeme de plug in ou chaipaskoi ?
 
(non quand la DLL change tu n'as pas besoin de tout relinker, sauf si tu rajoutes des fonction exportees)

Logiquement, c le principe des dll, de constituer un "bout de programme" complètement indépendant des ton gros programme. Donc, non, y a forcément moyen de ne pas recompiler ton prog. ça j'en suis sur ! par contre, je te dis ça parce que c logique, ms j'peux pas t'aider plus !

 
Effectivement, si je refile le nouveau lib avec ca devrait passer, j'y avais pas pense

 
Pour le gros prog je sais pas du tout, je pense qu'ils vont linker avec le lib, c'est pas comme ca que ca marche ?

si si, c ok
 
pis fo qu'ils appellent ta DLL, aussi  
 
(genre si tu fais des fonctions, elles marchent mieux quand elle sont apelle )

chrisbk a écrit a écrit : si si, c ok   pis fo qu'ils appellent ta DLL, aussi     (genre si tu fais des fonctions, elles marchent mieux quand elle sont apelle )

forcement  
 
Mais je pensais que quand tu linkais la lib il prenait aussi la dll.
J'ai compile une dll qui devrait me faire une messagebox quand j'appelle une fonction que j'ai faite, mais comment je fais alors pour linker la dll et le lib ?
Le lib je sais qu'il faut aller dans project->settings->link.
Mais je sais pas ou il faut que j'aille mettre mon lib (le rep)
 
(j'ai mis le lib dans le rep de vc ou y a tous les lib et le dll dans system32)

[edtdd]--Message édité par Godbout--[/edtdd]

J'ai reussi mais je sais pas si c'est la facon la plus simple parce que c'est un sacre bordel !
 
J'ai recopie mon fichier d'entete ou il y avait les declarations de fonctions de la dll, et je l'ai mis dans le projet ou j'ai fait mon exe.
Et y a fallu que je declare un pointeur pour pointe sur une fonction, que je fasse un loadlibrary, getProcAddress,...
 
Bref tout un bordel koi !

houla
 
sacre bordel oui
 
normalement dans l'appelant tu as le .h inclu (comme tu as fait)
et ce programme utilise le .lib cree pour la DLL  
 
 
pour ajouter le file tu fait "add File to project" et c ok
 
normalement t'as pas besoin de LoadLibrary and cie
 
si tu veux je peux te fair un faux exemple a la con

 
J'vais reessayer un autre projet avant.
Merci

C'est bon j'ai capte le truc.
Maintenant y a plus qu'a reflechir normalement

Godbout a écrit a écrit : C'est bon j'ai capte le truc. Maintenant y a plus qu'a reflechir normalement

 
YES WE DID IT !

 
??? Je crois que je n'ai pas tout compris. Je m'explique:
 
1. Je trouve que tu te compliques beaucoup la vie.
Déjà, c'est à mon avis inutile et dangeureux de faire générer du code par visual c++. Donc un new->project->dll et puis 'an empty dll project'. Au moins tu exportes ce que tu veux exporter. Si tu ne sais pas comment faire, c'est de toute façon TRES risqué de laisser faire le logiciel à ta place puisque tu ne sais même pas quel va être le résultat.
 
2.
[citation] alors, deux mode de DLL: Run-time Linking et Load Time Linking[/citation]
ce n'est pas tout à fait vrai. Ce sont 2 façons différentes de charger la dll, mais la dll peut être la même, pour peu que les symboles nécessaires aient été exportés (dans le cas du C tout au moins, on ne peut pas importer une classe définie dans une dll si on fait un chargement dynamique (LoadLibrary et...) alors que c'est possible si on compile le programme appelant avec le .lib de la dll).
 
3.
[citation]
-la memoire alloue par la DLL doit etre desallouer par la DLL
-ne fait transiter aucun pointeur sur des FILE * et consort de la DLL au programme appelant sinon...kaboum
[/citation]
j'ajouterais: attention, pour le c++: la STL de microsoft a des problemes avec les dll (des correctifs existent).
 
4.
[citation]si tu veux faire des plug in, fo du run time, sinon du loadtime suffit[/citation]
euh, c'est pas l'inverse?
Parce que un plug-in, ca veut dire que tu peux en rajouter, en enlever, etc... donc forcement le programme n'est pas compilé avec tes '.lib'. Donc je ne vois pas comment cela peut marcher dans le sens ou tu le dis.

je ne suis pas d'accord . Visual te genere tres tres peu de code, code inutile soitdit au passage, c juste educatif
Note que c grace a ce bout de code que je vois a peu pres comment m'en servir
 
Il exporte pas grand chose, et faire le menage dure 2s
ce qui est sympa c qu'il te fait tous le  
 
#ifdef DDD_EXPORTS
#define DDD_API __declspec(dllexport)
#else
#define DDD_API __declspec(dllimport)
#endif
 
sans que tu ai a y reflechir
 
 

 
je te dirais ne jamais l'avoir tenter...
 
Par contre il me semble qu'il faut etre prudent avec les fonction exportees et bien mettre  
 
extern "C"
{
  void pouet();
}
 
histoire de pas avoir de soucis quand tu link en run time
Tu confirmes  ? (g lu ca qqpart, j'ai pas essayer autrement)
 
 

 
Ben c'est bien ce que je dis
si tu veux des plug in, fo du run time (LoadLibrary, GetProcAdress & cie.... c du run time ca), pisque pas de .lib (loadTime)

Je tiens juste a dire au passage que je ne fait jamais generer du code par Visual C++, d'une part parce que les variables, etc.. ne sont pas ecrites de la meme maniere que je les ecris, et parce que c'est vrai qu'on ne sait pas trop ce qu'il fait.
Dans le cas la comme l'a dit chris ca ne genere pas grand chose, juste de quoi montrer comment exporter une fonction, une variable, ou encore un classe.

oui et non. en c++, à partir du moment où tu exportes une fonction, elle est visible. Mais le compilateur c++ fait de la "décoration de nom" pour le nom des fonctions et des variables que tu exportes. Il y a deja eu de sposts à ce sujet. En résumé, c'est parce que en c++, plusieures classes peuvent avoir une fonction du même nom, et de plus, la même fonction peut avoir plusieurs prototypes. ex: int fonction1(int a); et int fonction1(char c); Or quand tu fait un chargement dynamique avec LoadLibrary puis GetProcAddress, tu ne passes que le nom de la fonction. En c++, le nom ne suffit pas. (exporte une fonction C++ et regardes ce que tu as à l'interface (avec Visual Studio, il y a un outil qui est fourni qui s'appelle "Depends.exe" qui permet de voir les fonctions exportées d'une dll et toutes les dépendances de cette dll par rapport à d'autres)).
Donc, pour l'interface de la dll, il est préférable d'avoir des fonctions en C. Et pour les fonctions C, il faut un extern "C".
 

excuses moi, c'est moi qui avait mal compris

Godbout > elle doit marcher comment ta Dll ?
 
parce que normalement c'est l'exe qui depend de la Dll, mais on peut faire l'inverse, et j'ai l'impression que c'est ton cas...
Si c'est le cas tu dois avoir un .lib et un (ou des) .h venant de l'exe. Tu choisit un projet DLL et dans le projet tu inclus le .lib et les .h...
 
je ne sais pas si j'ai ete claire...

 
Salut BENB,  
 
Je te rassure, tu as ete tres clair (d'autant plus qu'a force de bidouiller je commence a comprendre).
Mais pour le moment c'est vrai que au niveau du projet je suis moi meme encore un peu dans le flou.
 
Tout ce que je sais c'est qu'il y a un gros programme auquel il faudra ajouter des fonctions. Je ne peux pas toucher au programme (j'ai meme pas les sources).
Les createurs de ce programme vont faire des fonctions, dans une dll, qui devraient pouvoir permettre de rajouter des menus, des onglets, etc...
Et je devrais normalement me servir de cette dll pour moi meme faire une dll qui sera utilisee par le gros programme.
 
Moi non plus je sais pas si j'ai ete clair sur le coup la...

D'ailleurs je ne sais meme pas si de leur cote ils ont un lib ?

par pure curiosite, c koi le gros programme ? il seraquoi ?

Ben c'est un programme vendu a des cuisinistes, pour faire leurs demonstrations aux clients, leurs commandes, devis, etc..

A mon avis ta Dll sera chargee par un loadlibrary (son nom sera trouve a partir d'un fichier de conf) tu devrai te conformer a une API, c'est a dire avoir des fonctions qui aurront un nom donne et qui seront retrouvee a partir de ce nom...
 
Autre possiblite tu dois faire un composant COM...
 
Ou alors heriter d'un objet de l'exe...

ouais mais le load library il serait a mettre dans le gros programme nan ?
Parce qu'apparemment il ne faudrait pas trop toucher au code (a part mettre des include obligatoires).
 
Pour les composants COM je ne connais pas, ils m'en ont pas parle

Absolument, de toute maniere ta Dll doit etre appellee par leur prog, c'est donc a eux de te dire comment...
de toute evidence tu devra respecter une API, c'est dire mettre des methodes en respectant les noms dans ta DLL c'est tout...
Le Pb peu venir des conventions de nommages... ces methodes ne doivent pas etre en C++ mais en C ou en C++ avec un extern 'C' devant, enfin c'est a eux de te dire ce que tu peut faire et comment... Pour toi c'est simplement un projet Dll (RunTime linking suivant le denomination chrisbk) enfin a mon avis...

 
Arf, la denomination chrisbk
 
bah c pas moi qui ai appelé ca comme ca, hein ? y'a bien deux maniere de charger une DLL....
 
une un peu relou mais qui te permet de bricoler (run time) et une moins ouverte mais toute simple a mettre en oeuvre
 
bon mon ptit god (je peux ? ) reste en loadtime, la comme tu fais avec le .lib+.dll et ca sera ...formidable
 
(laisse tomber cette histoire de fichier de conf, win se demerdera comme un grand...
il sait ce qu'il faut importer, et de quelle DLL . genre dans une commande dos tape :  
dumpbin monexe.exe /IMPORTS  
Suprise surpise .... enfin, ca marche que pour le loadtime ca)
 
++