Discussion :

[MegaSoft]

Bonjour,

Je suis sur un problème tout bête, mais je n'y arrive pas, donc je vous le soumet en vous remerciant d'avance pour vos réponses :

Je suis avec Visual Studio, je n'utilise pas le framework .net, et je tente de charger une DLL avec la fonction

LoadLibrary("laDll.dll");

mais en testant le handle renvoyé, je me rend compte que mon chargement a échoué, donc, j'appelle la fonction

GetLastError;

Là, je reçoit un joli DWORD, mais mon problème, est que j'aimerai bien savoir quel est ce numéro d'erreur !

J'ai essayé en vain de l'afficher via la fonction MessageBox

Is everyone can help me ?

[screetch]

voila comment afficher l'erreur avec un beau message (dans ta langue natale)

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
 
char *errorMessage;
if(::FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
                    NULL,
                    ::GetLastError(),
                    0,
                    (LPTSTR)&errorMessage,
                    0,
                    NULL))
{
            (void)MessageBox(0, errorMessage, "Erreur", MB_ICONERROR | MB_OK);
            (void)LocalFree(errorMessage);
}
else
{
            (void)MessageBox(0, "Meme pas reussi a recuperer le message", "Erreur", MB_ICONERROR | MB_OK);
}

[MegaSoft]

mais j'ai le regret de t'annoncer qu'au premier abord, ta solution a pour seul effet de figer mon application...

je vais me pencher un peu plus sur ce que tu as marqué, pour comprendre le truc (même si c'est suffisamment limpide au premier abord)

je précise que je suis dans le code d'une Dll, peut-être est-ce à cause de cela que ça ne marche pas ?

Merci quand même.

[screetch]

ah tiens bizarre, enfin je reste a l'ecoute si tu arrives a trouver l'erreur!

[MegaSoft]

Après quelques tests, il s'avère que ton code n'était responsable de l'arrêt de fonctionnement de mon application... ça m'aurait étonné aussi vu comment il est simple !

Je vais donc t'expliquer mon but plus en détails :

Je doit faire une application en C++ qui se sert d'une DLL en C++ qui se sert d'une DLL en Delphi, en gros c'est ça.

Le problème est que ma DLL en C++ refuse de charger la DLL en Delphi, alors que l'application en C++, elle veut bien charger la DLL en Delphi.

Voici des codes de test :

L'Application en C++

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <windows.h>
 
int main() {
	HMODULE hinstDLL;
	MessageBox(0,"Chargement de la DLL...","Suivi",0);
	hinstDLL=LoadLibrary("SimpleDll.dll");
	FreeLibrary(hinstDLL);
	hinstDLL=LoadLibrary("simpledllcpp.dll");
	FreeLibrary(hinstDLL);
 
	return 0;
}

Rien d'extraordinaire...

La DLL en Delphi : SimpleDll.dll
Ce n'est pas la vraie, c'est juste pour tester

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
library Convert;
uses dialogs;
Const
DevEuro=6.55957;
function ConvertEuro(Montant:double):double; stdcall;
begin
Result:=Montant*DevEuro;
end;
function ConvertFranc(Montant:double):double; stdcall;
begin
Result:=Montant/DevEuro;
end;
exports
ConvertEuro,
ConvertFranc;
begin
  ShowMessage('Project1 :: Initialisation');
{partie initialisation de la dll}
end.

La Dll en C++ : simpledllcpp.dll
Générée par Visual Studio 2005, je n'ai modifié que le DllMain

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
22
23
24
25
26
27
28
29
30
31
32
33
// simpledllcpp.cpp : Defines the entry point for the DLL application.
//
#include "stdafx.h"
 
#ifdef _MANAGED
#pragma managed(push, off)
#endif
 
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	HMODULE hinstDLL;
	MessageBox(0,(LPCWSTR)"",(LPCWSTR)"",0);
	hinstDLL=LoadLibrary((LPCWSTR)"SimpleDll.dll");
	char *errorMessage;
	if(::FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,NULL,::GetLastError(),0,(LPTSTR)&errorMessage,0,NULL))
	{
		(void)MessageBox(0, (LPCWSTR)errorMessage,(LPCWSTR)"Erreur",MB_ICONERROR | MB_OK);
		(void)LocalFree(errorMessage);
	}
	else
	{
		(void)MessageBox(0, (LPCWSTR)"Meme pas reussi a recuperer le message", (LPCWSTR)"Erreur", MB_ICONERROR | MB_OK);
	}
	FreeLibrary(hinstDLL);
	return TRUE;
}
 
#ifdef _MANAGED
#pragma managed(pop)
#endif

[screetch]

Il se peut que ca plante dans l'initialisation de la Dll delphi (pour une raison quelconque ca plante avec le C++ de la Dll mais pas avec le C++ du programme)

donc c'est l'appel a LoadLibrary qui lance l'initialisation, et la PAF! pastèque.

Pour voir ci c'est ca mets des messages au debut et a la fin de l'initialisation et verifie que tu vois les deux messages. Si ca plante entre les deux messages, essaye de rapprocher les messages jusqu'a ce que tu aies encadre l'execution qui plante et tu auras l'identité du bug.

Exemple :

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
22
23
24
 
library Convert;
 
uses dialogs;
 
Const
   DevEuro=6.55957;
 
function ConvertEuro(Montant:double):double; stdcall;
begin
   Result:=Montant*DevEuro;
end;
function ConvertFranc(Montant:double):double; stdcall;
begin
   Result:=Montant/DevEuro;
end;
exports
   ConvertEuro,
   ConvertFranc;
begin
   ShowMessage('Project1 :: Initialisation');
   {partie initialisation de la dll}
   ShowMessage('Project1 :: Initialisation OK!!!');
end.

et resserre les deux ShowMessage jusqu'a ce que tu encadres la ligne qui plante.

Si les deux dialogues marchent c'est que le bug n'est pas dans cette initialisation

[MegaSoft]

mais j'y ai pensé, et le premier message ne s'affiche même pas !

De plus, dans l'initialisation de la Dll en Delphi, il n'y a que 3 registerWindowMessage, donc l'isolement a été fait très rapidement sans succès...

En fait, quand je charge la Dll en Delphi directement dans le programme en C++, ça marche sans problème, contrairement au cas quand je la charge dans la Dll en C++. Ton bout de code indique "le module spécifié est introuvable", du moins dans mes tests, car dans la vrai appli, il n'indique rien du tout, et le tout se "freeze" au moment du LoadLibrary...

En ce qui concerne mes tests, peut-être est-ce un problème de conversion entre le "SimpleDll.dll" et l'argument en (LPCWSTR) que demande le LoadLibrary ?

[screetch]

j'ai du mal a suivre le probleme

1) si tu charges la DLL dans le programme, ca marche
2) si tu le charges depuis ta DLL C++, alors tu vois la boite de dialogue
3) dans quel cas ca freeze?

[MegaSoft]

C'est simple, mais c'est vrai que j'ai pu m'emmêler les pinceaux...

Récapitulons :

Je fais une application en C++ qui charge une Dll en C++, et cette dernière charge une Dll en Delphi.

L'application est faite, et je ne peut pas la modifier.
La Dll en C++ est en partie faite, idem pour la Dll en Delphi.

Lorsque j'ai voulu faire la connection entre les deux Dll, ben pouf !


Donc, après quelques tests infructueux, comme je nageais dans le potage de C++, ben j'ai décidé d'isoler le problème et de faire des programmes plus simples.

Dans ces tests, la Dll en Delphi se charge sans problème dans le programme en C++, mais ne se charge pas dans la Dll en C++.

Et, c'est dans la vraie application que le tout se fige au moment du LoadLibrary dans la Dll en C++ (de toute manière, je ne peut pas le mettre dans l'application).

Voilà

J'espère avoir été assez clair, et merci pour le temps que tu prends pour me répondre !

[screetch]

Donc si je comprends bien, lorsque tu charges la DLL dans un programme de test (cf plus haut qui appelle load library)
alors tu as un message d'erreur

si tu fais ca depuis ton vrai programme, au lieu de voir la boite de dialogue tout part en sucette

tu as plusieurs possibilites mais c'est plutot des suppositions malheureusement :
- as tu des warning sur les lignes d'appel ?
- remplace

Code :

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

1
2
 
LoadLibrary("dll");

par

Code :

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

1
2
 
LoadLibrary(_T("dll"));

- Le code d'initialisation de la dll est execute plusieurs fois selon le type de "load".
Donc dans le DllMain, verifie le parametre ul_reason_for_call
si celui ci vaut quelque chose comme DLL_REASON_ATTACH alors execute le code sinon ca peut valoir autre chose pour une autre type d'init.
fais un switch de ce gout :

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
22
23
24
25
26
27
28
29
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
    switch(ul_reason_for_call)
    {
    case DLL_REASON_ATTACH:
    {
	HMODULE hinstDLL;
	MessageBox(0,(LPCWSTR)"",(LPCWSTR)"",0);
	hinstDLL=LoadLibrary((LPCWSTR)"SimpleDll.dll");
	char *errorMessage;
	if(::FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,NULL,::GetLastError(),0,(LPTSTR)&errorMessage,0,NULL))
	{
		(void)MessageBox(0, (LPCWSTR)errorMessage,(LPCWSTR)"Erreur",MB_ICONERROR | MB_OK);
		(void)LocalFree(errorMessage);
	}
	else
	{
		(void)MessageBox(0, (LPCWSTR)"Meme pas reussi a recuperer le message", (LPCWSTR)"Erreur", MB_ICONERROR | MB_OK);
	}
	FreeLibrary(hinstDLL);
    }
    break;
    default:;
    }
    return TRUE;
}

- remplace tous les (LPCWSTR)chaine par des _T(chaine)


- ou/et passe ton programme en mode Multi-Byte character encoding au lieu de Unicode (proprietes generales du projet)

[MegaSoft]

Bien que je me débrouille pas mal en Delphi et en VB, le c++, c'est pas trop ma tasse de thé...

Donc... "warning sur ligne d'appel" <- kézaco ?

Sinon, il me sort un classique "identifiant non reconnu" lorsque je tente le _T(xxx), je vais essayer de trouver quel est l'include qui correspond.

Je sais que le DllMain est appelé plusieurs fois, mais cela m'importe peu, car c'est juste un test, et je ne pense pas que cela ait une incidence sur mon cas.

Quant au multibyte character... je cherche encore...



Sinon, j'ai fait quelques avancées :

J'ai réussi à faire s'éxecuter l'initialisation de la Dll en Delphi depuis la Dll en C++, mais en testant le Handle renvoyé... ben c'est toujours pas bon...

Pour y parvenir, j'ai juste remplacé LoadLibrary((LPCWSTR)"SimpleDll.dll") par LoadLibraryA((LPCSTR)"SimpleDll.dll")...

[screetch]

Ok je vais essayer d'etre plus clair ^^

tu as deux facons d'utiliser la lib API windows, une marche en ANSI (c'est a dire que les caracteres sont codes sur 1 octet)
l'autre en Unicode

selon tes reglages de projet tu peux utiliser les bibliotheques soit en version ANSI soit en version UNICODE.

Windows fournit deux implementations pour la plupart des fonctions qui prennent des chaines :
- LoadLibraryA (ANSI)
- LoadLibraryW (je crois que c'est avec un W comme WORD mais je suis pas sur, soit 2 octets, c'est peut etre W comme WIDE ou alors c'est pas W, j'en sais rien je m'en sers jamais)

les chaines C sont ANSI c'est a dire que si tu ecris "toto" alors chaque lettre prend 1 octet
Il y a un moyen d'ecrire "toto" en UNICODE, c'est d'ecrire L"toto" (oui avec un L devant en dehors de la chaine)
Selon les reglages du programme tu peux avoir a utiliser des chaines ANSI ou UNICODE. Il existe une macro dans les headers Windows qi permet de declarer une chaine soit ansi soit unicode selon le type de projet : c'est la macro _T("chaine statique") qui rajoute ou pas le L devant la chaine pour la passer en unicode.
Cette macro est dans le fichier <tchar.h>
donc si tu veux supporter les deux, tu peux passer par le type TCHAR au lieu de char (une chaine sera alors soit char chaine[] soit wchar_t chaine[] donc soit ANSI soit UNICODE selon ton projet, et les chaines statiques doivent etre dans la macro _T("chaine") pour en faire soit des chaines ANSI soit des chaines UNICODE



Le defaut que je recommande pour pas casser les burnes des gentils programmeurs que nous sommes et qui n'ont jamais fait de mal a personne, c'est de passer immediatement le projet en ANSI et de se contrebalancer des chaines UNICODE. Rien n'est vraiment pret dans le C pour l'unicode, alors quitte a faire un truc stupide et qui fait mal, autant se flageller avec des cactus. Ca sera plus productif et cafera moins mal que de supporter les TCHAR.



Tu peux donc aller dans les proprietes de ton projet (clic droit sur le projet, proprietes). Normalement tu seras dans un onglet qui est intitulé GENERAl, si tu n'y es pas clique sur GENERAL a gauche.

il y a uen case en bas (deux cases au dessus de la derniere je crois) qui indique "Character Set" (j'ai la version english de VStudio, desole). Tu peux choisir entre "UNICODE character set" (berk, reberk, bereberk!!!) ou Multi-Byte Character Set. Eloigne toi de l'unicode character set comme d'un reste de chili froid!!!!


Ensuite, retire toute les betises de (LPWCSTR) et laisse les char*



Par "warning sur ligne d'appel", je voulais te demander si le compilateur avait indiqué un avertissement sur la ligne ou tu appelles LoadLibrary. Si tu te trompes dans le format de chaine (entre UNICODE et ANSI) alors le compilateur doit refuser de compiler. Donc retire tous les (LPCWSTR) ou (LPWCSTR) ou je sais plus et si ca ne compile pas, c'est que la fonction utilisee n'est pas la bonne version (c'est a dire UNICODE).

[MegaSoft]

Merci pour cette explication, j'y voit maintenant un peu plus clair dans tout ce charabia de LPCSTR & co...

Donc, avant de lire ton message j'avais trouvé comment passer en Multi-byte et effectivement, ça aide beaucoup...

De plus, j'ai réussi à charger ma Dll en Delphi et à en sortir une function !

Mais mon problème est le même que celui qui m'a amener sur ce forum...

Ma function de test est une fonction toute simple qui renvoie un entier qui vaut 128, après avoir affiché un message (ce qu'elle affiche)...

Comment faire pour que ce Int soit lisible ?
Comment le convertir en LPCSTR ?

En fait le but est de renvoyer une chaîne, et c'est ce que je vais tester maintenant...

Merci d'avance...

Edit : J'ai oublié, non je n'ai pas de Warning sur les appels

[screetch]

HAAAAAAAAAN stooooooooooooooooop

il est impossible de renvoyer une string PASCAL (ou Delphi) vers le C++ directement!

les string pascal sont des objets vaec des champs toussa, ca respecte une convention de passage de paranetre tordue.

La seule chose que le C++ peut gerer est le char*

ta fonction doit donc renvoyer un PCHAR

Code :

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

1
2
3
4
5
6
7
8
 
function fonctionDeTest(param : Integer) : PCHAR
var
   temporary : string;
begin
   temporary = IntToStr(param);
   result := PCHAR(temporary);
end

Mais ca ne s'arrete pas la

deja il te faut trouver la fonction IntToStr. Ca c'est un probleme delphi, je sais pas ce que c'est.

De plus, comme je l'ai bien ecrit dans la fonction, la chaine temporary est TEMPORAIRE, elle sera detruite a la fin de la fonction, avant de rendre la main au C++, ce qui fait que le PCHAR va etre moisi!

pour remplir des chaines, j'ai peur qu'il y ait peu de choix, il faut que C++ alloue le buffer, donne le buffer a Delphi (avec la taille) et Delphi remplit le buffer.

Les seules choses renvoyees par Delphi que C++ peut utilser sont les types de base qui ont la meme representation (float => single, double => double, PAS les extended delphi, char* => PCHAR, int => INTEGER, short => WORD...)

tu vas galerer !

[MegaSoft]

J'ai fait mes petits tests en prenant en compte ce que tu as dit...

Effectivement, passer un shortstring comme prévu est impossible, j'ai donc changé en PCHAR dans la Dll en Delphi et là paf ! ça marche !

Je peux donc appeler une fonction de la Dll en Delphi, et récupérer le Résultat dans la Dll en C++, ce qui est ce que je voulais !

Mais... (pourquoi il y a toujours un mais ?)

En revenant sur l'application initiale, ben, je me retrouve avec le même problème qu'avant, le "freeze" à l'appel de LoadLibrary...

Je pense que quelques précisions s'impose...

Ce que j'appelle l'application en C++, c'est Eudora
Ce que j'appelle la Dll en C++, c'est un de ses plugins
Ce que j'appelle la Dll en Delphi, c'est une bibliothèque de fonctions qu'on veut implanter à Eudora, mais pas que à Eudora

Voilà tout est dit

As-tu une idée sur pourquoi ça gèle au chargement de la Dll ?

[screetch]

alors la cette fois ci... aucune idee.

peux tu lancer ta Dll dans visual en l'attachant au processus Eudora et voir ce que le CPU est en train de faire ?

si je parle chinois dis moi ^^

[MegaSoft]

tu parles Cambodgien... c'est à moitié compréhensible.

Lancer la Dll dans visual en l'attachant au processus d'Eudora, là ça va

Je lance Eudora, j'ouvre Visual avec la Dll en C++, et je fait Debug>Attach to Process>Eudora.exe et hop ! (dis-le moi si je me trompe)

par contre , voir ce que le CPU fait... euh peut-être

je n'ai que Output qui marque des trucs, pas de "CPU" au quelque chose se rapprochant en vue... c'est où stp ?

[Albenejean]

le module spécifié est introuvable

Une idée toute stupide: préciser le chemin complet de la DLL...

[MegaSoft]

mais j'y ai déjà pensé, et cela n'arrange pas les choses

de plus, maintenant, si j'avais un message d'erreur qui s'affichait, je serais assez content, mais il n'y a rien, vu que l'application se "fige" au moment du LoadLibrary

[screetch]

Ok c'est pas si mal ^^

alors pour attacher au processus il y a un peu plus simple, tu vas dans les proprietes du projet, et dans debuggage tu remplis les champs application a lancer et parametres avec Eudora (si tu connais la ligne de commande pour lancer Eudora). Ca te permet de lancer Eudora automatiquement et des que ta DLL sera chargee Visual sera "liee" dessus, en quelque sorte. Sinon attacher au processus marche aussi, mais il faut reussir a s'attacher au processus avant que ca ne plante

Ensuite, dans le menu de Visual C++ il y a un onglet Debug tout en haut. Si tu deroules, tu verras "Exceptions..."

cliques dessus.

Tu verras des lignes et des checkbox a droite. Elles sont tous decochees par defaut. Coche les toutes (ca devrait etre par defaut c'est un vrai scandale!!!!!!)


Voila maintenant que ca s'est fait tu peux t'attacher au processus. Deux possibilites :
- mettre un "breakpoint" avant le load library et faire du pas a pas jusqu'a ce que ca crashe
- lancer direct comme un boucher. Si ton appli crashe tu auras un diagnostic, si il est perdu dans une boucle infinie (c'est de ca que je parlais en voyant ce que fait le CPU) tu peux cliquer sur "Pause" pour stopper temporairement l'execution, et inspecter la call stack. Ca devrait te dire ce qui ne va pas : en tous cas ca devrait te dire OU il y a un probleme.