Discussion :

[Bart_lx]

Bonjour,

Je développe actuellement une dll et un programme l'utilisant sur WinCe5.0.
J'ai donc déveloper une appli entière en premier lieu pour me familiariser avec le SDK, créé les fonctions dont j'aurai besoin et les utiliser, aucun probleme.

J'ai ensuite passer les fonctions dans une dll, et créé une appli qui charge la dll pour utiliser les fonctions exportées.

Je me retrouve avec un probleme lors de tout appel a une fonction qui recois un pointeur ou une référence.

/* Fonction dans la dll */
int NBGTest(int *ptr)
{
*ptr = 1985;
return 0;
}

/*Appel dans le programme */
void OnBnClickedButton5()
{
int *t = new int;
*t = 5;
pfn_test(t);
}

Le pointeur a l'arrivé dans la fonction de la dll n'est pas initialisé, comme si le passage par pointeur (ou par référence, j'ai tester meme probleme) posé probleme.

Je précise que j'ai déveloper une dll du meme type sous Xp sans aucun probleme au niveau des appels de fonctions. Ma dll est bien chargée, les fonctions sont egalement bien chargées. En mode débug, en mode pas a pas j'arrive jusqua la fonction de la dll ou le pointeur vaut :
0x00000000 ... comme si le pointeur qui arrive en entré est différent de celui envoyé.

Auriez vous une idée quand à la raison de cette réinitialisation de variable ou le fait que les deux ariables de concordent pas ?

Merci de m'avoir lu, n'hésiter pas à demander plus de précisions.

[Médinoc]

Vérifie s'il n'y a pas une erreur bizarroïde au niveau de la convention d'appel (genre, la fonction définie avec une certaine convention d'appel, et le pointeur de fonction déclaré avec une autre...).

[Bart_lx]

Je t'avourai que j'ai un peu de mal a faire des recherches efficaces avec un sujet qui ressemble à ça :
wince 5.0 dll pointeur
wince 5.0 passage par pointeur dll

Surtout que le probleme est assez spécial et difficile à transcrire simplement.

Pour info je charge la dll avec :
LoadLibrary("lib.dll");
et les fonctions :
GetProcAdress(DLL_Function_init)GetProcAddress(hDll,_T("NBGInit"));

[Médinoc]

Montre-moi le prototype exact des fonctions et des typedefs de pointeurs, s'il te plait.

[Bart_lx]

J'ai reelement fait la fonction de test linker plus haut et le plantage apparait meme avec un passage de pointeur sur un entier. Je te joins les proto et les variables :
---------------------------------------------------
/* APPLI, chargement de la fonction de la dll */

typedef int (WINAPI *DLL_Function_test) (int *ptr); // Declaration de la fonction de la dll dans l'appli
pfn_test = (DLL_Function_test)GetProcAddress(hDll,_T("NBGTest")); // Chargement de la fonction dans l'appli


/* Appel a la fonction de test */
void OnBnClickedButton5()
{
int*t = new int; //<--- Initialisation de mon pointeur
*t = 5;
pfn_test(t); // <--- envoi de l'adresse du pointeur
delete t;
}

---------------------------------------------------
/* DLL */

int NBGTest(int *ptr) // <-- recupération du pointeur
{
*ptr=1989; // <-- A cet endroit, le pointeur ptr vaut null
return 0;
}

---------------------------------------------------

*EDIT : Au moment de l'affection de *ptr=1989; l'appli "plante" bizarrement elle ne quitte pas, on dirait que l'erreur et récuperer, et on ressort direct dans la boucle du Main de l'appli MFC

De plus apres tests, il s'avere que tout passage par valeur via l'appli, se trouve "corrompu" à l'arrivé dans la dll.
J'ai modifier la fonction de test pour la faire prendre en entrée deux int.
pfn_test(6,3);

à l'arrivé, dans la dll, le programme ne recoit pas 6 et 3, mais 3 et 0.
Il ya apparement un probleme au niveau de la pile, ou au niveau de la mémoire.

J'ai également une fonction qui envoie une structure pour initialiser la structure dans la dll.
J'envoie les parametres 1 2 3 4 5 (sous forme de struct)
à l'arrivé, je recois 2 3 4 5 1.
J'ai l'impression que certain éléments de la mémoire s'inverse lors du passage par la dll. Je continu les recherches...

[Médinoc]

Comme je le pensais, il y a conflit de convention d'appel:
Le pointeur est déclaré WINAPI (c'est-à-dire __stdcall) mais pas la fonction...

[Bart_lx]

Aurais tu une solution envisageable ? Je ne comprend pas vraiment le probleme.

[Médinoc]

Simple: Soit tu modifies la DLL pour que ses fonctions soient en __stdcall, soit tu supprime WINAPI dans la déclaration des pointeurs de fonction...

[Bart_lx]

Je te remercie avant tout de répondre sur ce sujet.

J'ai modifié les pointeurs de fonction, le probleme reste identique, par contre j'ai fait de nouveaux tests.

J'ai créé une fonction qui prend en parametre, deux entiers.
int NBGTest(int a,int b);

Donc je la charge dans mon appli, pas de souci, je fais un appel à cette fonction
du genre :
pfn_test(6,3);

En mode débug, je m'aperçois qua l'arrivé la mémoire s'est "décaller" de 8 octets.
A savoir :
pfn_test(6,3);
En mode pas à pas, quand j'arrive dans ma fonction NBGTest, le premier parametre est à 3 (au lieu de 6) le second est a 0 (au lieu de 3) et "this" est à 6 (valeur du premier parametre).
L'image en link permet de voir le pas a pas en arrivé de la fonction test.
Les valeurs des entiers sont elles bien codées sur le bon nombre d'octets ?




Je continue mes recherches et reste à l'affut de ce sujet.

[Médinoc]

Houlà!

Tu ne m'avais jamais parlé de fonctions (non-statiques) dans des classes C++!
Dans ce cas, le type de pointeur est complètement "off". Il faut des "pointeurs de fonctions membres".

Ou plutôt, modifier la DLL pour que ces fonctions soient hors de la classe ou statiques.

[Bart_lx]

Alors la je dis Bravo et Merci Monsieur .


J'ai utiliser le wizard VS pour creer ma DLL, en supprimant tout ce qui est créer de base par le wizard et en mettant les fonctions sans classe, ça marche impeccable.

Du coup une question me vient à l'esprit : A QUOI SERT LES FONCTIONS CREEES PAR LE WIZARD -_-.

Et une autre : Pourquoi le fait de mettre mes fonctions dans une classe fonctionne sous XP mais pas sous CE, et pourquoi le probleme qui en ressort est un décalement de mémoire.

En tout cas je te remercie d'avoir mis le doigt sur ce point.

A suivre

[Médinoc]

1. Ça dépend du Wizard. Pour une DLL absolument normale, sans MFC ni rien, je pense que ce sont des exemples.
2. Sans doute parce qu'il y a un code de vérification quelque part dans XP, ou que l'éditeur de liens exporte le symbole différemment. Si tu regardes le lien de ma signature, tu verras qu'il y a un peu partout du code pour "rattrapper" certaines erreurs de convention d'appel...