Bonjour,
 
Je cherche à utiliser une DLL dans un programme en C, fournie pour l'utilisation d'un matériel spécifique; n'étant pas très au point sur ce sujet, j'ai cherché de la doc là-dessus mais je n'ai pas trouvé les infos qui me seraient utiles (notamment les infos de base).  
 
Avant même l'utilisation de la DLL en question, pour me faire la main, j'ai essayé de réaliser un exemple. Mais il me manque la base pour savoir si mon exemple correspond à la réalité.  
 
Déjà, qu'est-ce qu'une DLL, à part une bibliothèque logicielle (compilée, n'est-ce pas ?) Quels sont les similitudes et différences avec une API ? Qu'est-ce qu'elle a de différent vis-à-vis d'un fichier d'entête (.h) "classique" ? Le seul début de réponse que j'ai trouvé à ce sujet est qu'à priori, les fonctions de la DLL dont on a besoin doivent être chargées en RAM (?)

une dll c'est une bibliothèque qui à la particularité d'être chargée au démarrage de l'application et liée à l'application à ce moment là  
contrairement à une libraire statique inclue dans le programme au moment de la compilation
http://en.wikipedia.org/wiki/Linker

une API c'est juste un ensemble de fonction dont le nom et les arguments et leur action et défini dans un document.
les dll ou les librairies statiques peuvent contenir une implementation d'une API.

Un en-tête contient juste les déclarations des fonctions, il dit juste au compilateur cette fonction existe et prend tels arguments, c'est ensuite à l'édition de lien que les appels à ces fonctions sont remplacées par des adresses réelles.

Oui mais si tu as codé correctement ton programme pour utiliser la DLL ça se fait tout seul au lancement du programme.
 
 
enfin si tu as un niveau suffisant en anglais:
http://en.wikipedia.org/wiki/Dynamic-link_library
très complet avec pleins de références en bas de page.

Merci pour ces réponses très claires    
 
Sinon quels sont les avantages et inconvénients d'une DLL à chargement implicite et à chargement explicite ?
 
Sauf erreur, les différences qui existent entre les deux c'est que, dans le cas d'une DLL à chargement explicite, le code n'est pas nécessairement (pas du tout ?) portable, mais que l'occupation mémoire de la DLL est géré par le programme qui l'utilise, alors que dans le cas d'une DLL à chargement implicite, le code est potentiellement portable mais que l'ensemble des fonctions exportées par la DLL sont chargées en mémoire du début à la fin... (je me trompe ?)
 
Qu'existe-t-il comme autres différences ?

Elle est chargée quand le progrmme en a besoin. Ca peut-être longtemps après le chargement du programme. Cela peut-être longtemps avant si un autre programme en a eu besoin.
 

Une API Windows (pour les autres API c'est peut-être différent) n'est pas un ensemble de fonctions, c'est UNE fonction, écrite en C, incluse dans Windows et documentée par M$. Les API résident physiquement dans des DLL (user32.dll, par exemple).
 

Cela dépend de la DLL. Si c'est une DLL du noyau, il n'y a pas besoin de demander son chargement, mais si c'est une DLL maison, alors il faut demander son chargement (que Windows ne fera pas s'il voit qu'elle est déjà chargée en mémoire) avec l'API LoadLibrary().

 
C'est un ensemble de choses pouvant être:
Des structures de données.
Des fonctions et procedures.
Des classes et méthodes.
Des protocoles.
Et ce n'est pas nécessairement écrit en C, même si un prototype C, utilisable pour linker, est fourni.
 
Une API peut être réduite a une fonction, mais en général ce n'est pas le cas.
Et en ce qui concerne windows, in wikipaedia veritas:  

L'API Windows est constituée d'un paquet d'apis relativement indépendantes, par exemple l'API Direct X.
A+,

Merci pour toutes vos réponses...
 
J'ai cependant une question (importante) restée sans réponse : quelle est la différence entre une librairie dynamique à chargement explicite et à chargement implicite ?

La différence réside dans le fait que pour un chargement explicite, il faut inclure dans le programme l'appel à LoadLibrary(), GetProcAddress(), et FreeLibrary() alors que ce n'est pas nécessaire si le chargement est implicite.
En général pour les DLL que l'on crée soi-même, le chargement est explicite, donc on fait les trois appels dans le programme appelant.

J'avais pu noter cette différence mais, en fait, ma question est plutôt de connaître l'intérêt d'une méthode plutôt que de l'autre. Je veux dire, il est préférable de gérer le chargement de sa DLL plutôt que de laisser ça à Windows ? Si oui, pourquoi ?
 
J'ai une autre question, encore plus fondamentale celle-là : la DLL dont je dois me servir exporte des fonctions dont le type de la valeur de retour est "bool", mon compilateur (C) fait donc un peu la tête... Faut-il que je passe à un compilateur C++ ?    
 

Avec LoadLibrary(), on est certain que la DLL sera chargée. Cela évite d'avoir à se poser des questions en fonction de la version de Windows ou d'autres paramètres. Et si on fait LoadLibrary() alors que ce n'est pas utile, alors tout marche quand même. Mais, pour les DLL hyper communes, du genre user32.dll, c'est inutile de le faire.
 
Souvent les booleans sont en fait des integers. Mais ce serait mieux si la DLL retournait des integers.

En général vaut mieux laisser Windows faire ça, car le code est nettement plus simple.
 
Il peut tout de même y avoir un intérêt à charger la dll soit même : lorsqu'on veut proposer des fonctionnalités facultatives. Par exemple ton programme peut tourner sans une certaine dll, mais si elle est présente, ça permet d'offrir quelques fonctionnalités supplémentaires. Cette dll pour une raison ou une autre est difficile à distribuer (payante, lourde, compliquée à installée, etc ...).  
 
Si tu utilise la liaison dynamique normale, ton programme imposera que cette dll soit présente dès le démarrage, même si on n'utilise pas les fonctions de cette dll. Avec LoadLibrary, tu pourra simplement afficher un message si la dll n'est pas trouvée. Mais bon, ça va être lourd à gérer dans le code, puisqu'en général les dll ne sont pas prévues pour être ouverte à la main.
 
Par exemple avec gcc, c'est le genre de code que j'écris pour rediriger de manière transparente toutes les fonctions vers des pointeurs. C'est le plus "simple" que j'ai pu trouvé et je trouve que c'est encore super lourd.
 

Oui mais dans le cas où Windows gère tout seul le chargement en mémoire, il peut y avoir un problème lors de l'utilisation de la DLL sur un OS proche mais suffisamment différent pour poser potentiellement problème (au hasard Windows Vista ). En d'autres termes, le code n'est pas "tellement" portable d'un OS (de même type) à un autre... Je me trompe ?
 
Sinon, en fait, pour clarifier les choses, l'utilisation de la DLL propriétaire dont j'ai besoin repose sur le fait que je puisse la mettre en oeuvre via une autre DLL de ma conception. Tout ceci pour permettre l'utilisation d'une caméra sous LabVIEW (qui n'accepte pas comme valeur de retour un pointeur sur fonction, d'où l'intérêt de ma DLL, qui jouerait le rôle d'interface). Ceci se résume comme suit :
 
| Caméra | <=> | DLL caméra | <=> |Ma DLL| <=> |LabVIEW
 
Les fonctions exportées par la DLL de la caméra sont, pour une bonne partie, écrites en C++, ce qui fait hurler mon compilateur (GCC). La question que je me pose c'est donc est-ce que les DLL ne sont écrites qu'en C ? D'ailleurs, lorsque je crée un projet de DLL dans cet IDE, il ne me laisse pas le choix du langage...

Ta DLL, tu dois l'écrire avec labWindows non ?
Si oui, alors oui, il ne s'agit que d'un compilateur C. Pas de C++.
Cependant, pas de problème particulier normalement à utiliser des DLL écrites en C++.
 
Edit : pour la caméra, tu utilises NI Vision ?

Pas nécessairement avec LabWindows. Moi j'utilise Code::Blocks comme IDE actuellement.
 
En fait, je découvre totalement LabVIEW, je n'utilise donc pas NI Vision pour mon application, tout au moins pour l'instant.
 
En fait, le problème que je rencontre avec LabVIEW, c'est qu'il ne gère pas les pointeurs sur fonction comme valeurs de retour de fonctions, je dois donc passer par une DLL perso pour interfacer les deux. Les

Utiliser une DLL compilée avec un compilo A dans un programme compilé avec un compilo B, ca a toujours été périlleux: Un exemple de problème rencontré: le compilo A installe son handler d'erreur en cas de division par zero. Le compilo B aussi.  
Le programme se lance => handler de div par 0 du comp A installé
Il appelle le dll qui execute du code => handler de div par 0 du comp B installé, qui masque le précédent.
Le code principal de l'appli (pas de la dll) fait une division par 0 => handler de div par 0 du comp B appellé. Bref on appelle un pointeur, mais dans le mauvais espace d'adressage (celui de l'appli et non celui de la DLL) d'ou plantage.
Bon, en virant la div par 0 du code principal, le probleme disparait, mais ca donne une idée de ce a quoi il faut faire gaffe.
Si mes souvenirs sont bons, de plus, le compilo A (Metaware) fonctionnait en addressage 32 bits, sous windows 3.1 et le compilo B etait celui de Microsoft, en 16 bits donc.
A+,

Mais le fait de d'utiliser une DLL qui a été compilé avec un compilateur X dans un programme que l'on compile avec un compilo Y c'est pas justement le cas habituel ? En règle général, on ne sait pas avec quel compilo notre DLL a été compilée, je me trompe ?

C'est pour cela que en environnement professionnel, les vendeurs de dll payantes te proposent parfois la dll compilée avec plusieurs versions du compilo
Disons qu'entre la théorie et la pratique, y'a parfois un décalage.
Mais c'est vrai qu'en général, l'interopérabilité est assez bonne.

A+,

Sauf que là, il s'agit justement d'une DLL pro, donnée à contrecœur par le constructeur pour éviter que l'on puisse se passer de son propre logiciel d'acquisition, donc les infos ne sont pas toutes au RdV...

Bon, j'ai réussi à compiler la DLL constructeur...    
 
Maintenant, j'ai un autre souci : à priori, l'image acquise par la caméra est stockée dans un tableau 1D au moyen d'un pointeur.
 

 
Ne reste donc que le pointeur pImageData pointeur vers l'adresse de la case mémoire où est stocké la valeur du premier pixel de l'image ainsi que la taille allouée au stockage de l'image acquise. C'est là que se situe le problème : je ne peux utiliser un tableau à taille variable comme en C++ (où C99):

 
Voici un exemple de la façon dont le problème d'allocation de mémoire peut être réglé en C++, selon le SDK :

NB : Dans mon appli, je ne me sers que d'une caméra monochrome, le calcul de nombre de canaux de couleurs est donc superflu...
NB : nombre de bits/pixel = 12 bits, width = 660, height = 492.
 
A quoi sert le "+3" et le "& -4" (pour ce dernier, masquage ?) ?
 
J'envisage donc une solution de ce genre-là :

 
Qu'en pensez-vous ?

Ouais et tant mieux, les VLA d eplus de 128K font planter les systemes en general. C'ets la plaie c'ets truc, à ne pas utiliser
 
 

c'est une astuce pr  calculer le multiple de 4 strictement supérieur à  width * colorChannels
 

n'oublie pas le free qui va avec à la fin

Tu peux détailler ? l'intérêt de la chose par exemple ?
 

 
J'y pensais, mais ma pseudo-solution n'est qu'une illustration de principe.

L'intérêt de la chose est que si ce n'est pas un multiple de 4, alors les données ne sont pas "alignées" et cela ne marche pas.

 
Les bitmaps sous Windows doivent avoir les lignes paddés sur 32bits pour être manipulés avec GDI ou GDI+.

Merci de vos réponses.
 
La question c'est donc "pourquoi 4" (je pense qu'un truc essentiel m'échappe d'où ma non-compréhension de l'intérêt de l'astuce...) (c'est juste pour que la manipulation des valeurs se fasse sur des mots de 4 bits ?)
 
D'ailleurs, la représentation de l'image s'effectue bien en RGB vu le code, non ? (sauf que moi, j'utilise une cam monochrome donc il n'existe qu'une seule information, celle du contraste entre noir et blanc (j'imagine qu'il ne s'agit pas strictement de la luminance ?))
 
Le stockage des données s'effectue dans un tableau 1D vu la façon dont l'allocation de mémoire est faite, autrement dit si je veux afficher mon image, il me faut afficher ça de cette façon :  
 
1ère ligne -> retour à la ligne -> 2e ligne  -> etc... (et non pas colonne par colonne on est d'accord ?)

Pourquoi aligner les début de ligne sur 4 octets ? Parce que c'est plus rapide sur les architectures 32-bit (CPU et/ou chip de la carte graphique), car sinon le microprocesseur est obligé de faire un masquage pour ne récupérer qu'à partir du deuxième, troisième ou quatrième octet dans son registre de 32 bits.

A propos de l'alignement des débuts de lignes, j'ai du mal à voir l'intéret de l'astuce.
 

 
Si on décompose chaque étape de cette ligne de code, on s'aperçoit que si Width est multiple de 4, on retrouve widthBytes = (((Width*2) + 3) & -4) = (Width*2).
 
Pour que ce soit plus clair, prenons un exemple avec Width = 660 (donc multiple de 4) :

 
Maintenant avec Width = 663 (donc non multiple de 4) :

 
Bon d'accord, dans un cas où Width est multiple de 4, la valeur est identique au début et à la fin et dans un cas non-multiple la valeur est modifiée ; l'intérêt du changement ne me paraît pas évident...

Ce n'est pas une question d'intérêt, mais de nécessité. Essayez votre progrmame avec une longueur de 663 et s'il ne marche pas (comme je le suppose), essayez avec l'alignement sur 664 (et il devrait marcher).

 
Justement, je ne peux pas le tester comme ça, mes fonctions devant être appelées sous LabVIEW pour pouvoir récupérer les images acquises. J'essaye de comprendre sans exécution pour l'instant mais effectivement ce n'est pas des plus simples... Du coup, si une âme charitable pouvait m'expliquer point par point ce qui se passe, cela m'aiderait beaucoup.

Plus que de nécessité, je dirais d'optimisation. Enfin, ça reste encore à prouver que c'est toujours utile à l'heure actuelle. Pour autant que je me souvienne cette contrainte date de la préhistoire : Windows 3.1 au plus. Par compatibilité ascendante, Microsoft n'avait pas trop d'autre choix que de garder cette contrainte. Cela dit, c'est pas la mort non plus. Perso j'aligne ça avec un code du genre :