probleme sur api

bonjour a tous voila j'ai un petit souci de compilation avec une api voila le code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <stdio.h> #include <stdlib.h> #include<windows.h>   int main(int argc, char *argv[]) { LPCSTR *bu[100]; FindFirstVolume(&bu,100); system("PAUSE"); return 0; }

---

j'obtien cette erreur bizarre

Compilateur: Default compiler
Building Makefile: "C:\Users\miki\Desktop\Makefile.win"
Exécution de make...
make.exe -f "C:\Users\miki\Desktop\Makefile.win" all
gcc.exe -c tes.c -o tes.o -I"C:/Dev-Cpp/include"

gcc.exe tes.o -o "test.exe" -L"C:/Dev-Cpp/lib"

tes.o(.text+0x45):tes.c: undefined reference to `FindFirstVolume'
collect2: ld returned 1 exit status

make.exe: *** [dddd.exe] Error 1

Exécution terminée

j'ai était faire un chtit tour dans winbase et la fonction FindFirstVolume y et bien déclarer alors si quelqu'un pouvait m'éclairer sur le pourquoi du comment de l'erreur de compilation ça serai sympa merci d'avance

Je n'ai pas Windows mais suis surpris par ton code, un programmeur Windows confirmera mais est ce qu'il ne faudrait pas plutôt écrire :

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <stdlib.h> #include <windows.h>   int _tmain (void) { TCHAR bu[100]; FindFirstVolume (bu,100); system ("PAUSE"); return 0; }

---

?

Effectivement le code de nicolas.sitbon est meilleur.

Juste je modifierais (afin de m'affranchir des versions unicode/non unicode)

Code:

---

FindFirstVolume (bu, sizeof(bu) / sizeof(bu[0]));

---

Sinon, pour ton problème de link, il faut lier avec la librairie Kernel32.lib.

Voir ici pour plus d'info.

Merci d'avoir répondu , oui je doit l'avouer je débute alors dessole pour le code un peu fouillis, sinon c'est quoi la différence entre le code de Nicolas.sitbon a savoir juste le int _tmain (void) par rapport a la fonction main classique je débute je le répète si vous pouviez m'expliquer merci par avance en attendant je teste le code de Nicolas.sitbon merci pour vos explications

si je ne dis pas de bêtise, je passe un (TCHAR*) alors que toi tu passes un (TCHAR***), or cette fonction prend en premier paramêtre un LPTSTR soit un (TCHAR*).

Citation:

---

Envoyé par chuko

tes.o(.text+0x45):tes.c: undefined reference to `FindFirstVolume'
collect2: ld returned 1 exit status

---

Bien que ce soit une fonction bien connue de l'api Win32, même en ajoutant libKernel32.a (kernel32) au projet, je n'ai pas cette fonction avec MinGW. Bizarre...

oui je me demande si ce n'est pas un beug ou un problème du a dev c++ c'est quand même bizarre étant donne que la fonction est déclarer dans winbase.Encore un chose Emmanuel Delahaye peut tu m'eclairer sur cette histoire de unicode et non unicode car j'ai vu cela sur la msdn mais je n'ai pas comprit merci par avance.

Citation:

---

Envoyé par chuko

Encore un chose Emmanuel Delahaye peut tu m'eclairer sur cette histoire de unicode et non unicode car j'ai vu cela sur la msdn mais je n'ai pas comprit merci par avance.

---

Oui, pourquoi moi ?

Les chaines C standard classiques utilisent un tableau de char.
Les chaines C standard étendues utilisent un tableau de wchar_t. C'est requis par les codages étendus comme Unicode, qui supportent toutes les langues écrites du monde, et même le 23 caractères du Klingon...

Microsoft, par un jeu astucieux de macros permet décrire du code portable qui permet de coder dans un mode ou dans un autre en foncion de de la configuration, et ce sans modifier le code source(_tmain(), TCHAR etc.)

lol oui enfin je te demandai car tu l'a mentionner pour mon souci j'ai trouver la réponse grâce a la reponse trouver sur un autre forum je poste cette derniere pour explication

FindFirstVolume() n'est disponible que dans Windows 2000 et suivants. Il faudra donc permettre au compilateur de la reconnaitre en ajoutant avant les includes:
#define _WIN32_WINNT 0x0500

apres cela ça marche impec merci a tous pour toutes vos explications et pour le temps que vous m'avez accorder

Citation:

---

Envoyé par chuko

lol oui enfin je te demandai car tu l'a mentionner pour mon souci

---

Non, c'est Nicolas...

Citation:

---

FindFirstVolume() n'est disponible que dans Windows 2000 et suivants. Il faudra donc permettre au compilateur de la reconnaitre en ajoutant avant les includes:
#define _WIN32_WINNT 0x0500

---

Argh, oui, j'ai changé de machine, j'ai oublié ce détail...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <stdio.h> #include<windows.h>   int main (void) { char bu[256]; FindFirstVolume (bu, sizeof bu); printf ("bu = '%s'\n", bu);   return 0; }

---

Code:

---

1 2 3 4 5

bu = '\\?\Volume{7079e993-8c31-11dc-84e6-806e6f6e6963}\'   Process returned 0 (0x0) execution time : 0.011 s Press any key to continue.

---

Citation:

---

Envoyé par Emmanuel Delahaye

Non, c'est Nicolas...

Argh, oui, j'ai changé de machine, j'ai oublié ce détail...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <stdio.h> #include<windows.h>   int main (void) { char bu[256]; FindFirstVolume (bu, sizeof bu); printf ("bu = '%s'\n", bu);   return 0; }

---

Code:

---

1 2 3 4 5

bu = '\\?\Volume{7079e993-8c31-11dc-84e6-806e6f6e6963}\'   Process returned 0 (0x0) execution time : 0.011 s Press any key to continue.

---

---

pour rebondir sur le code de ram_0000 :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <stdio.h> #include <windows.h> int main (void) { char bu[256]; FindFirstVolume (bu, sizeof bu / sizeof *bu); printf ("bu = '%s'\n", bu); return 0; }

---

ça ne mange pas de pain et ça fait une chose de moins pour être TCHAR compliant.

Citation:

---

Envoyé par Emmanuel Delahaye

Les chaines C standard étendues utilisent un tableau de wchar_t. C'est requis par les codages étendus comme Unicode, qui supportent toutes les langues écrites du monde, et même le 23 caractères du Klingon...
etc.)

---

C'est une blague ?

[edit] apres une courte recherche je m'autoréponds :
"oui oui c'est bien vrai, mais sous linux dans la zone privée"
ca va aller dans Windows c'est mal ca :aie:

Au sujet de "pourquoi une erreur d'include fait foirer l'édition de liens" : C'est une histoire de convention d'appel. gcc présuppose une fonction retournant int, avec la convention d'appel __cdecl (donc nommée "_FindFirstVolume"), alors que les fonctions Windows utilisent la convention d'appel __stdcall, le "vrai" nom de la fonction est donc "_FindFirstVolume@8" (sur un système 32 bits).

D'où l'importance de ne pas oublier d'activer les warnings sous gcc. Si les warnings étaient activés, tu aurais eu un message "implicit declaration of FindFirstVolume".

Citation:

---

Envoyé par Médinoc

Au sujet de "pourquoi une erreur d'include fait foirer l'édition de liens" : C'est une histoire de convention d'appel. gcc présuppose une fonction retournant int, avec la convention d'appel __cdecl (donc nommée "_FindFirstVolume"), alors que les fonctions Windows utilisent la convention d'appel __stdcall, le "vrai" nom de la fonction est donc "_FindFirstVolume@8" (sur un système 32 bits).

D'où l'importance de ne pas oublier d'activer les warnings sous gcc. Si les warnings étaient activés, tu aurais eu un message "implicit declaration of FindFirstVolume".

---

Non. Ca, c'est le nom C++. Les noms C sont FindFirstVolumeA et FindFirstVolumeW selon que l'on est en Ansi ou en Wide characters (unicode). En fait, FindFirstVolume est une macro. Le nom réel est placé en fonction de la définition de la macro UNICODE.

L'absence de header fait que la macro n'est pas traduite.

Par contre, ce qui faisait que la fonction n'était pas déclarée (pas de prototype) malgré l'inclusion de <windows.h>, était l'absence de définition de la version de Windows utilisée.

Citation:

---

Envoyé par Emmanuel Delahaye

Non. Ca, c'est le nom C++

---

Je ne pense pas que ce soit de ça que Médinoc voulait parler mais que Visual C++ décore le nom des fonctions C __stdcall exportées avec __declspec(dllexport). Quand on ne veut pas décorer le nom de la fonction (pour que la DLL soit utilisable depuis un autre langage par exemple ou pour n'importe quelle autre rasion), il faut exporter la fonction à l'aide d'un fichier DEF. Les DLLs de Windows exportent les fonctions sans décoration de nom or à la compilation, Visual C++ décore toujours le nom des fonctions __stdcall. Les fichiers .obj contiennent donc toujours des fonctions décorées, c'est pourquoi les libs d'importation de Visual C++ utilisent toujours les noms décorés (indépendamment de ce qui se passe dans la DLL, JMP et CALL nécessitent comme opérande une adresse et non le nom d'une fonction ...).

Citation:

---

Envoyé par Emmanuel Delahaye

Par contre, ce qui faisait que la fonction n'était pas déclarée (pas de prototype) malgré l'inclusion de <windows.h>, était l'absence de définition de la version de Windows utilisée.

---

Ca personne n'a été contre.

EDIT (Précisions) : La décoration se fait de la manière suivante :
Pour les fonctions C : Nom de la fonction + décoration stdcall.
Pour les fonctions C++ : Nom de la fonction + décoration C++ + décoration stdcall.

Citation:

---

Envoyé par Melem

EDIT (Précisions) : La décoration se fait de la manière suivante :
Pour les fonctions C : Nom de la fonction + décoration stdcall.
Pour les fonctions C++ : Nom de la fonction + décoration C++ + décoration stdcall.

---

OK. Une journée où on apprend rien est une mauvaise journée.