Comment est ce que ça marche les .h et les .lib:
 
Que ce soit sous VisualC++ 6 ou sous n'importe quel compilateur:
On  fait un #include d'un .h et le compilateur va savoir ou aller chercher l'implémentation de cette fonction il va trouver lui même la bonne librairie?Comment fait-il???

il est très fort !

Tout dépend des compilo, mais la plus part du temps tu doit lui préciser quelle librairies additionnelles il doit utiliser le simple ajout du .h ne suffit pas

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

Ben justement c'est là que c'est fort,pour visual C++ v6 ,dans le setting le compilo à seulement le chemin de certaine librairie (genre user,kernel...) mais il est loin d'avoir toute celle présentent dans les repertoires d'installation de visual!!!!
comme par exemple la librairie implémentant les fonctions déclarées dans stdio.h!!!!!

Mais personne n'a jamais dit que visual était un bon compilo

un .h != un .lib  
 
tu peux avoir trente .h implémentés dans une seule .dll, soit un seul .lib à linker.
 
dans ton cas, stdio.h & co, c'est la lib C standard, implémentée dans une dll : MSVCRT.DLL (qui veut dire qq chose comme Microsoft Visual C RunTime ...).  
 
à chaque .lib correspond une .dll, tu peux regarder les fonctions exportées avec dependency walker (depends.exe dans visual studio\Common\Tools)

euh... tu peus me rappeller vite fait le lien exact entre une dll est une librairie? C'est du genre: l'appli se sert de la lib pour invoquer les fonctions de la dll,nan???

oui je ne m'y connais pas des masses là-dedans ...
 
tu as deux types de .lib : le premier contient du code, le second contient les méthodes d'accès aux fonctions de la dll. c'est de cette manière qu'en MFC, tu peux linker statiquement ou dynamiquement.  
statiquement = le code du .lib statique que tu utilises dans ton programme est recopié dans ton .exe.
dynamiquement = le .lib sert à charger la .dll et à trouver les pointeurs vers les fonctions dont tu te sers.
 
dans ton cas, le .lib est dynamique : tu utilises par ex la fonction TextOut() de gdi.dll - le code généré contiendra un pointeur vide vers la fonction. lors du lancement de l'exe, la dll sera chargée et les références utilisées par ton code seront patchées par windows, qui remplacera le pointeur vide par le pointeur vers la fonction chargée de la dll.
 
quand tu inclus un .h, ça marche car le .lib fait sûrement partie des .libs utilisés par défaut dans chaque projet. pour tester autre chose, appelle une fonction directx : la compilation marchera nickel, et au link tu auras un 'unresolved external' car le linker ne sait pas où trouver la référence. rajoute le .lib de directx à ton projet, le linker saura où trouver la définition de la fonction et pourra générer le code.
 
ce qui me fait penser que tu n'as pas l'air de saisir autre chose : ce n'est pas le compilateur qui génère le .exe, c'est le linker. le compilateur compile le code (il se sert des .h pour savoir comment générer les appels aux fonctions), le linker résoud les liens (il se sert des .lib pour savoir comment appeler les fonctions).