Version imprimable
Bonjour,
Apres avoir parcouru des tutoriaux qui apprennent à faire des trucs supers durs, et les menus de Vc++ qui proposent des options plus compliqué les unes que les autres, je pose ma question simple pour etre sur d'avoir fait comme il faut :
J'ai 3 fichiers :
- chose.h
- chose.dll
- chose.lib
Je veux m'en servir :( je met les choses ou et je fais quoi dans les options du projets (je travaille sous visual c++ 2005 express) ?
(Apparemment le C++ je maitrise pas :D )
(en supposant que les trois fichiers soient bien faits)
- Tu inclus (avec #include) chose.h dans les fichiers sources qui doivent utiliser les fonctions de la DLL.
- Soit en copiant le fichier dans le répertoire du projet
- Soit en spécifiant un chemin absolu ou relatif complet dans le #include
- Soit en tripotant les "Addidional include directories" dans les options du projet
Après cette étape, la compilation de chaque fichier source doit marcher.- Tu lies le .lib au projet.
- Soit en ajoutant dans un fichier source "#pragma comment(lib, "chose.lib")" (mais ça ne marche que sous visual)
- Soit en ajoutant chose.lib aux options du projet (sous VS2005 : Project properties -> Configuration properties -> Linker -> Input -> Additional dependencies)
Après cette étape, l'édition de liens doit marcher.- Il faut que la DLL soit accessible lors de l'éxécution
- Par exemple, dans le même répertoire que l'exécutable
- Dans un répertoire spécifié dans la variable d'environnement PATH
Pour plus d'infos : Dynamic-Link Library Search Order
Après cette étape, l'exécution doit marcher.
Avec cela, normalement, ça devrait marcher.
Bon rien à faire en Express, pas trouvé, je suis passé en normal et ca a marché direct sans rien faire ^^
Merci pour tout :) je vais enfin pouvoir commencer à coder :)
Bon :) dans mon combat contre les Dll je cherche encore à comprendre quelques petites choses (oki j'ai menti, ENORMEMENT de choses).
En 2 petites interrogations :
1/ Ce que j'ai compris et dont je ne suis pas sur :
Depuis une dll qqconque, coucou.dll , une entete coucou.h est construit et on intégrera celle ci dans notre projet. Cette entete coucou.h doit contenir des fonctions qui feront référence au fonction de la dll, ainsi qu'à sa structure de donnée.
On pourra donc trouver sur internet plusieurs entete coucou.h qui feront référence à la meme dll (ouh la "faire référence" je paris que c une expression employé pour un autre emploi :/ )
2/ Ou trouve t on les descriptions de ces dll ? ou trouve t on les entete associé à ces dll ? Par exemple je suis à la recherche d'une entete et de la description de la dll pour HID.dll et je ne trouve nul part qqchose qui semble officiel. Il me semble pourtant que c une dll windows.
Y a t il des entete hid.h officiel (je demande par la meme occasion)
Merci de toutes les informations que vous pourrez m'apporter
Tu ne trouveras pas toujours un en-tête par DLL.
Les DLLs .Net n'en ont pas besoin (tout est inclus dedans sous forme de méta-données), les "Composants COM" n'en ont pas non plus s'ils utilisent des interfaces connues (sinon, ils ont une bibliothèque de types).
Quant aux DLLs de Windows, elles ont généralement des en-têtes différents: Les fonctions du Registre sont déclarées dans winbase.h et se trouvent dans advapi32.dll. Les fonctions socket se trouvent dans wsock32.dll et ws2_32.dll, mais sont déclarées dans winsock.h et winsock2.h, etc.
Donc pour enrichir ma culture Dll et lever le brouillard de mon incompréhension, comment sont utilisées par un programme C/C++ les Dll auxquelles aucunes entete n'est associée ?
Vous parlez de méta donnée, mais comment y a t on acces ? une dll au bloc note c pas top à regarder :D
Pour les DLLs .Net, je ne sais pas trop : Le framework et le compilateur font leur cuisine pour que ça marche. Par contre, cela oblige à compiler la DLL et l'avoir à portée de main lors de la compilation (contrairement aux DLL conventionnelles ou le header (et optionnellement le .lib d'importation) suffisent).
Pour les Composants COM, c'est plus compliqué. Déjà, on n'accède à un objet que par des Interfaces, définies dans un header ou dans une bibliothèque de types. Il existe un grand nombre d'interfaces "Communes", ou connues dans un domaine: Pour une extension de l'explorateur qui affiche un onglet supplémentaire dans la boîte de dialogue "Propriétés", l'objet COM doit supporter l'interface IPropertySheetHandler. Et TOUT objet doit absolument supporter l'interface IUnknown.
Ensuite, les seules choses qui manquent pour créer un objet, ce sont son ID de classe (CLSID) et le chemin de sa DLL. Le chemin de la DLL est toujours dans la base de registre (HKEY_CLASSES_ROOT\CLSID\{...}\InprocServer32), l'ID de l'objet dépendant de l'utilisation:
- Pour un programme qui doit utiliser un objet bien précis (par exemple, "je veux l'objet pour changer les propriétés de l'Active Desktop", on utilise un header dans lequel le CLSID de l'objet est déclaré "en dur". Dans notre exemple, CLSID_ActiveDesktop est déclaré dans shlobj.h sous Windows). Dans ce cas là, un .h doit être livré avec la bibliothèque pour donner le CLSID de l'objet (encore qu'il y a des moyens de controurner, avec le ProgID et des fonctions comme ClsidFromProgid).
- Pour les PropertySheetHandlers, on se doute bien qu'on ne doit pas recompiler explorer.exe pour qu'ils marchent. Aussi, explorer se contente de lire une liste de CLSID dans une clé de la base de registre, et crée un objet pour chaque CLSID lu.
Une fois qu'on a le CLSID d'un composant COM, il suffit d'un appel à CoCreateInstance() pour que le système regarde dans la base de registre, y lise le chemin de la DLL qui contient le composant, charge la DLL, crée l'objet et retourne une interface vers cet objet.