[Win32]Problème au chargement d'une DLL C++

Version imprimable

04/07/2006, 10h25
FamiDoo

[Win32]Problème au chargement d'une DLL C++

Bonjour,
J'ai développé une DLL en C++ mais lorsque dans 1 programme de test dans un autre langage je désire charger la DLL, ça ne marche pas.
J'ai pourtant fait la même chose qu'avec une autre DLL qui fonctionne elle très bien.
Je pense que c'est du au fait que ma solution contient 2 projet dont un qui génère un .lib qui va servir au 2e à générer la DLL !

La solution contient donc :
- Un projet static library
- Un projet DLL dépendant du premier

Ce problème peut-il être du au fichier de ressources .rc ?

Toute aide est la bienvenue.;)
04/07/2006, 10h33
Médinoc

Citation:

Envoyé par FamiDoo

ça ne marche pas.

http://www.phac-aspc.gc.ca/seniors-a...rystalball.gif
04/07/2006, 10h53
FamiDoo

Oui ça ne fonctionne pas, le programme me renvoie qu'il y a un problème au niveau du chargement de la DLL. Sans doute ne trouve-il pas de point d'entrée ?
04/07/2006, 11h31
Médinoc

Quel est l' "Autre langage" du programme ?
Ta DLL est-elle en C++ natif ou en .Net ?
Comment est l'interface de la DLL ? (C++ ou extern "C")
etc.
04/07/2006, 11h38
FamiDoo

L'autre langage c'est du windev mobile mais ceci a peu d'importance, le problème ne vient pas de là.
Sinon j'utilise extern C , et c'est du win32(tag du sujet ^^) donc du C++ natif.
04/07/2006, 11h41
Médinoc
Citation:

Envoyé par FamiDoo

Je pense que c'est du au fait que ma solution contient 2 projet dont un qui génère un .lib qui va servir au 2e à générer la DLL !

Donc, dans ta solution, tu as:
- Un projet static library
- Un projet DLL dépendant du premier
et hors de la solution, un projet application qui est ton programme de test dans un autre langage. C'est bien ça ?
04/07/2006, 11h44
FamiDoo

oui Médinoc, c'est tout à fait ça.
J'avais déjà eu le problème il y a peu avec un simple projet et j'avais réglé le problème mais là je sèche.
04/07/2006, 11h49
Médinoc

Tu devrais essayer un programme C++ pour tester.
D'abord tester avec un lien implicite vers la DLL (tu linkes avec le .lib généré par ton projet DLL), puis si ça ne marche pas, avec un lien explicite (là, tu pourras utiliser GetLastError() et FormatMessage() si LoadLibrary() échoue).
04/07/2006, 11h55
FamiDoo

on en parle dans la FAQ de loadlibrary ?
04/07/2006, 12h00
Médinoc

Je l'ignore, mais on en parle dans MSDN.

Un truc à savoir par contre, c'est que LoadLibrary() ne marchera pas si la bibliothèque contient des variables déclarées avec __declspec(thread).
04/07/2006, 14h35
FamiDoo

Apparemment ca ne fonctionne pas :

Citation:

HINSTANCE hinstLib;
MYPROC ProcAdd;
BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;

// Get a handle to the DLL module.

char * dl="srtw32p.dll";
int Size = MultiByteToWideChar (CP_ACP, 0, dl, -1, NULL, 0) ;
LPWSTR wUnicode = new WCHAR[Size] ;
MultiByteToWideChar (CP_ACP, 0, dl, -1, wUnicode, Size) ;

hinstLib = LoadLibrary(wUnicode);

// If the handle is valid, try to get the function address.

if (hinstLib != NULL)
{

MessageBox (NULL, TEXT("c'est bon"), TEXT("iPaqDev"), MB_OK);

Il ne m'affiche rien donc la librairie n'est pas chargée !

Code:

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
#include <windows.h>
#include <strsafe.h>
 
HINSTANCE hinstLib;
MYPROC ProcAdd;
BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;
 
// Get a handle to the DLL module.
 
TCHAR * szDll=TEXT("srtw32p.dll");
 
hinstLib = LoadLibrary(szDll);
 
if(hinstLib == NULL)
{
	TCHAR szBuffer[20];
	DWORD error = GetLastError();
	StringCbPrintf(szBuffer, sizeof(szBuffer), TEXT("Erreur n°%u"), error);
	TCHAR szErreur[80];
	FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, error, 0,
	 szErreur, 80, NULL
	 );
	MessageBox(NULL, szErreur, szBuffer, MB_OK | MB_ICONERROR);
}
else
{
	MessageBox (NULL, TEXT("c'est bon"), TEXT("iPaqDev"), MB_OK);
}

Qu'est-ce que ça t'affiche, quand tu remplaces ton code de chargement par celui-ci ?

05/07/2006, 08h35
FamiDoo

Salut, merci Médinoc.
Erreur n'°126 : module spécifié est introuvable.
05/07/2006, 08h52
FamiDoo

j'ai un fichier .def avec mes exports; le problème vient-il de la ?

POur exporter j'utilise __std_call comme pour mon autre DLL qui fonctionne très bien.
05/07/2006, 10h16
Médinoc

L'erreur 126 indique que le système n'a tout simplement pas trouvé le fichier .DLL.
Regarde dans l'aide de LoadLibrary() pour voir les emplacements où le .DLL doit être pour que le système le trouve.

Et __stdcall ne sert pas à exporter, c'est une calling convention. On peut tout-à-fait exporter des fonctions avec les autres calling conventions (__cdecl (par défaut) ou __fastcall)...
05/07/2006, 10h19
FamiDoo

Citation:

Regarde dans l'aide de LoadLibrary() pour voir les emplacements où le .DLL doit être pour que le système le trouve.

J'ai fait une autre DLL il y a peu, elle est appelée pourtant c'est exactement le même principe, sauf que c'est un projet DLL non dépendant d'un autre projet qui quant à lui génère 1 bibliothèque statique. Elle est située dans le même emplacement : "\\windows".

La DLL non trouvé vient surement du .def non ?
05/07/2006, 10h23
Médinoc

Non, ça vient de son emplacement et de son nom.
LoadLibrary() ne regarde pas dans la table d'exportation (sauf sans doute pour DllMain(), mais l'erreur serait autre, je pense...).

Vérifie bien le nom de la DLL, et fais une recherche de tous les emplacements des deux DLLs (celle qui marche et celle qui ne marche pas).

PS: Dynamic-Link Library Search Order
05/07/2006, 10h37
FamiDoo

les 2 dlls sont placés dans "\\windows" et nul part ailleurs, donc je ne pense pas que le problème vient de l'emplacement, plutôt du point d'entrée ou quelque chose de la sorte.
Surtout que si je modifie le nom de l'autre DLL, le programme ne la trouve pas.
05/07/2006, 10h42
Médinoc

Tu peux me donner les noms des DLLs en question telles qu'elles apparaissent dans "\\windows" ?
(d'ailleurs, c'est pas conseillé de les mettre là, si ce ne sont pas des DLLs système : Elles seraient bien mieux dans le répertoire de ton application.
05/07/2006, 10h47
FamiDoo

fonctionne
ne fonctionne pas
05/07/2006, 10h49
Médinoc

Code:

char * dl="srtw32p.dll";

Forcément, si on tape mal le nom... :roll:

PS: Ensuite, tu peux essayer de voir si ta DLL est valide en l'ouvrant avec Dependency Walker (depends.exe)...
05/07/2006, 10h52
FamiDoo

non j'avais testé en changeant le nom de la DLL également, mais aussi
05/07/2006, 11h10
FamiDoo

Citation:

PS: Ensuite, tu peux essayer de voir si ta DLL est valide en l'ouvrant avec Dependency Walker (depends.exe)...

Medinoc tu es mon sauveur ;) .
J'ai testé ton outil et en fait, j'ai 1 référence dans mon projet à une librairie que je créé auparavant ( ttw32.lib pour ne pas la citer ).
dans le .def c'était défini : library "ttw_dll_2005", j'ai remplacé par ttw32, puis j'ai récupéré le .lib pour mes dépendances et voila !

Merci beaucoup :merci: