Discussion :

[FamiDoo]

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.

[Médinoc]

ça ne marche pas.

[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 ?

[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.

[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.

[Médinoc]

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 ?

[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.

[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).

[FamiDoo]

on en parle dans la FAQ de loadlibrary ?

[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).

[FamiDoo]

Apparemment ca ne fonctionne pas :

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 !

[Médinoc]

Code batard C/C++ non-testé :

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
#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 ?

[FamiDoo]

Salut, merci Médinoc.
Erreur n'°126 : module spécifié est introuvable.

[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.

[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)...

[FamiDoo]

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 ?

[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

[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.

[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.

[FamiDoo]

fonctionne
ne fonctionne pas