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.

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+,

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.

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.
 

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 ?

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+,

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+,

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

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

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.

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

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 :