Discussion :

[MogDeChNord]

J'ai créé une API dans une DLL (at_xpedite.dll) et les fonctions ne fonctionnent pas correctement lorsqu'elles sont appellées depuis mon programme de test alors qu'elles fonctionnent très bien si je les copie dans le code de mon prog de test.

--Code DLL--

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[xip_fax.h]
[...]
#ifdef __cplusplus
  extern "C" {
#endif
AT_XPEDITE_API int XIP_FAX_WriteOutputMode(FILE* dest, char* mode);
#ifdef __cplusplus
  };
#endif
[...]
 
[xip_fax.c]
[...]
int XIP_FAX_WriteOutputMode(FILE* dest, char* mode) {
  char toWrite[XIP_LINE_SIZE+1] = "";
  unsigned int size = 0;
  size = sprintf(toWrite, "OUTPUTMODE %s", mode);	
  if(fwrite(toWrite, 1, size, dest) != size) return XIP_ERROR;
  return XIP_SUCCESS;
}
[...]

-- Code Test --

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int main(int argc, char* argv[]) {
  int ret = 0;
  FILE* xipFile ;
 
  if((xipFile = fopen("c:\\_temp_\\file.xip.txt", "wt")) == NULL) {
    return FAX_XPD_ERROR;
  }
 
  ret = XIP_FAX_WriteOutputMode(xipFile, "standard");
  fclose(xipFile);
}

J'ai droit à un beau "Unhandled exception in test.exe (NTDLL.DLL): xxx Access violation"

En mode débug j'ai remarqué que les fonction de base ne fonctionnait même pas:
"unsigned int size = 0" ne m'initialize par la variable (en tout cas pas à 0)
"sprintf()" ne copie pas toujours la chaine demandé (toujours la même)
"strlen()" retourne des noombre abérrant (19 normalement)

D'où cela peut-il venir (je viens de rebooter au cas où !) ?

[farscape]

salut,
ta dll ne tourne pas dans le meme thread que le prog principal ,donc ton handle de fichier d'apres moi n'est pas valide dans la dll.
si tu fais un dll avec des fonctions d'écriture sur flux etc ... fait une fonction d'ouverture/création du flux dans la dll ou le handle du flux est local à la dll.
Comme ça ta dll est vraiment indépendante.

[MogDeChNord]

Cela pourrait peut-être poser problème mais il y a déjà des chose bizarre avant même de faire le fwrite:

L'affectation de "size" ne fonctionne même pas !

[BertrandA]

ta dll ne tourne pas dans le meme thread que le prog principal donc ton handle de fichier d'apres moi n'est pas valide dans la dll.

Mouais, en gros tu prétends que les données d'un thread ne sont pas accessibles à un autre thread dans le même processus ?
Alors les critical sections ne servent à rien !
Sauf erreur, une DLL se trouve dans un module distinct, mais ce module est mappé dans l'espace adressable du processus père.
Je pense que cela devrait fonctionner tel quel... sauf si les modules utilisent 2 versions différentes de la librairie standard du C !
VC++ propose différentes DLL pour la librairie standard du C : single threaded / multithread avec ou sans les symboles de debug.
Si l'application utilise une version single threaded et la DLL une version multithread : badaboum.
On se retrouve en effet avec 2 modules qui manipulent chacun un descripteur de fichier différent.

Et bien évidemment en mode debug, utiliser la DLL compilée en version debug...

[MogDeChNord]

Finalement t'avait raison !

Les autres problèmes venaient d'ailleurs !

[Pucpood]

N'y aurait-il pas un problème de convention d'appel (manière dont les paramètres sont passés à la fonction de la DLL) ?

[MogDeChNord]

Pas à ma connaissance

[farscape]

salut ,ta pense à l'alignement memoire ?

[MogDeChNord]

En fait, le problème devait venir d'une histoire de contexte différents (je ne connais pas bien la config VS6) entre le prog de test et la DLL. Ainsi, comme le disait farscape, faire les opération d'ouverture/fermeture dans la DLL résolvait mon pb.

Cependant, pour d'autres raisons, les prototypes des fonctions de mon API ont changé afin d'être plus générique. Je n'aurais donc plus de manipulation de descripteur de fichier à manipuler et donc plus ce genre de soucis:

char* XIP_FAX_WriteOutputMode(char* dest, char* mode);

Maintenant c'est une API se charge uniquement de "traduire" la chaine de caractère. L'écriture du fichier se fera lors d'une seconde étape. On se réserve ainsi la possiblité d'utiliser ces chaines manipulées dans un buffer/sortie standart/fichier en fonction des projets.

Merci du coup de main.