DLL m�lange export C et C++

J'ai une DLL fourni par un tiers (un cor�en que j'ai aussi contact� et dont j'attends la r�ponse)

DLL �crite en Visual C++
Il fournisse des projets Visual C++ complet, cela m'a bien aid� d'ailleurs (m�me si je comprends pas du tout comment il fait pour inclure les fichiers lib et tout �a)

Evidemment en C++Builder, j'ai du bidouill� les fichier .H pour que cela compile
La 1�re DLL n'exporte que du C non d�cor�, �a c'est OK, j'ai d�j� fait bcp de dev avec

La 2nd DLL exporte du C non d�cor� et C++ d�cor�es, l� j'ai un petit probl�me

Pour les fonctions C, pas de soucis, j'ai mis extern "C", le linkage passe !
Sauf pour 4 fonctions C++, il n'indique que le nom de la fonction dans le message d'erreur genre

Citation:

---

[ILINK32 Erreur] Error: 'MaFonction' externe non r�solu, r�f�renc� depuis ...

---

Pour les fonctions C++, je me suis dit, faisons pareil avec extern "C++", effectivement, je vois une diff�rence sur le message d'erreur, il �num�re les fonctions avec le prototype complet avec la convention d'appel mais sans le type de retour comme

Citation:

---

[ILINK32 Erreur] Error: '__stdcall MaFonction(long)' externe non r�solu, r�f�renc� depuis...

---

J'ai g�n�r� le fichier lib depuis la DLL avec implib, il est inclu dans le projet
j'utilise un douzaine de fonction, seule 4 se montrent p�nible

Dependency Walker me donne les noms d�cor�s et j'ai bien la bonne concordance de type !

Exemple pour MaFonction

Code:

---

1 2 3 4

// Dans la DLL : ?MaFonction@@YGHPAJ@Z // Dans le .H BOOL __stdcall MaFonction(LONG *p);

---

J'ai donc essay� la m�thode de impdef : Using Visual C++ DLLs with C++Builder
Le ? dans le nom de la fonction lui pose probl�me :

Citation:

---

Error ...e.def(4): Invalid character in .DEF file

---

Pas de bol !

Je passe donc � Coff2Omf !
L�, c'est pas mieux, par d�faut, il ne g�n�re que quelques fonctions sur une centaine, je joue avec les options, le fichier lib est d�j� plus complet mais l� aucune fonction n'est li� !

Mais comment utilis� une DLL MSVC++ en C++Builder !

1) Je pense que les fonctions C++ visual sont de toutes fa�ons incompatibles avec Builder. IMPLIB est utile pour appeler les fonctions C, mais pour les fonctions C++, m�me si on arrive � r�soudre les probl�mes de d�corations, �a plante ensuite � l'ex�cution.

2) Si �a peut t'aider, il existe aussi un petit utilitaire pour g�n�rer un .lib OMF, un .def ou un .h: http://denis.beru.free.fr/Download/ConvLib.exe (sans garantie)

Salut ShaiLeTroll
je ne suis pas d'accord avec les propos de 10_GOTO_10

Citation:

---

Je pense que les fonctions C++ visual sont de toutes fa�ons incompatibles avec Builder. IMPLIB est utile pour appeler les fonctions C, mais pour les fonctions C++, m�me si on arrive � r�soudre les probl�mes de d�corations, �a plante ensuite � l'ex�cution.

---

en effet la pluspart des plant�es proviennent de l'emploi de mauvaise convention d'appel (thiscall,fastcall.stdcall,cdecl)

pour ma part dans des dll mixtes(c,c++) j'adopterais la stat�gie suivante

• Function C
  importation statique via Implib puis emploi statique de la librairie cr�e par Implib
  l'emploi dynamique reste �galement valable, dans ce cas pas besoin de librairie d'importation
• Function C++
  utilisation dynamique via la paire LoadLibrary et GetProcAdress
  la d�claration des fonctions peut se faire via les functions (undecorate)
  ex :
  
  Code:

  ---

  1 2 3 4 5 6 7

  typedef long (__cdecl *MYDLLFUNC)(unsigned int *,unsigned int *); MYDLLFUNC ImpFuncDLL; HINSTANCE hinstDLL= LoadLibrary("H:\\Program Files\\Microsoft Platform SDK\\Bin\\mssnapr.dll"); ImpFuncDLL= (MYDLLFUNC)GetProcAddress(hinstDLL, "?GetPropSheetCharSizes@@YAJPAI0@Z"); // et finalement aprés utilisation un petit FreeLibrary(hinstDLL);

  ---

  un petit bout de code servant � (undecorate) les fonctions c++
  
  Code:

  ---

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  DWORD OtionMaks=SymSetOptions(SYMOPT_UNDNAME); char Buffer[255]; try { DWORD BuffLength= UnDecorateSymbolName( Edit1->Text.t_str(),//contient les fonctions décorées commencant par un ? Buffer, 255, UNDNAME_COMPLETE); if(BuffLength==0) RaiseLastOSError(); Edit2->Text=Buffer; // on affiche la fonction (undecorate) } catch(EOSError&E) { ShowMessage(E.Message); }

  ---

cdlt

Pour le GetProcAddress\LoadLibrary, venant de Delphi, j'y avais pens� (voir mail plus bas que j'ai envoy� � l'auteur), c'est m�me la seule m�thode que je pratiquais jusqu'� pr�sent !
Je n'aime pas le chargement statique, cela rend d�pendant mon programme, bon l� �a va, c'est une DLL qui encapsule le tout et mes DLL je ne les charge qu'en dynamique et via une Factory pour un lazy loading !
Inutile de charger une DLL si on ne l'utilise pas, surtout que la DLL cor�enne en charge 8 autres et 12 threads !

je l'ai d'ailleurs simplifi� via des macros, car toutes mes DLL (sorte de drivers) respecte les m�mes interfaces

Code:

---

1 2	#define GetProcAddress_GeHardwareProviderInterface(X) (LPFN_GetHardwareProviderInterface)GetProcAddress(X, "GetHardwareProviderInterface") typedef IHardwareProvider* (WINAPI *LPFN_GetHardwareProviderInterface)();

---

dans ma factory, l'appel est donc tr�s simple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

AnsiString DLLPath = IncludeTrailingPathDelimiter(DLLDirectory) + NewDLLName; if (FileExists(DLLPath)) { DLLData->LoadInThreadID = GetCurrentThreadId(); StrCopy(DLLData->DLLName, DLLPath.c_str()); DLLData->DLLHandle = _WINDOWS_::LoadLibrary(DLLPath.c_str());   if (DLLData->DLLHandle) { LPFN_GetHardwareProviderInterface GetHardwareProviderInterface = GetProcAddress_GetHardwareProviderInterface(DLLData->DLLHandle); if (GetHardwareProviderInterface) DLLData->HardwareProviderIntf = GetHardwareProviderInterface();

---

Ensuite, je n'utilise plus jamais la fonction mais l'interface (et sous-interface)


Peux-t-on m�langer chargement statique et dynamique ?
En terme d'espace m�moire ?
Surtout que j'utilise une douzaine de fonction, en fait elle font parti d'un ensemble, la premi�re va me cr�er un contexte d�ex�cution, ensuite j'utilise son handle comme param�tre des autres fonctions !
J'ai un doute sur un m�lange !
Si je dois partir sur un chargement dynamique, je le ferais � 100% pour cette DLL, cela fait un peu de code mais j'ai l'habitude !

Sinon, j'ai fait le bourrin (j'ai tent� avant de devoir faire un chargement dynamique)
J'ai bidouill� mon fichier d'alias g�n�r� par IMPDEF

Code:

---

1 2 3 4 5 6

LIBRARY LIB_MACHIN.DLL   EXPORTS ; use this type of aliasing ; (Borland name) = (Name exported by Visual C++) LIB_FonctionBidule = ?LIB_FonctionBidule@@YGHJJJP6GXKHK@ZPADK@Z

---

le ?LIB_, il n'aime pas, j'ai mis � la place LLIB_
J'ai g�n�r� le fichier LIB avec IMPLIB
J'ai ouvert ce fichier LIB avec un �diteur Hexa, j'ai remplac� les LLIB_ par ?LIB_, j'ai link� et hop �a fonctionne !

l'utilisation d'un fichier d'alias ne doit probablement que servir qu'� �a et le comble c'est qu'il ne supporte pas le 1er caract�re de d�coration VC++ !
Pourant mon IMPLIB est de 2009 (celui fourni avec XE2), il devrait conna�tre le ? !
�trange, de la mauvaise volont� cher MS et CodeGear ?

Citation:

---

Hello,

Sorry for my poor english

I integrate your SDK
I drive your hardware with "hardware.DLL"
That is OK ! Excellent Demo and Documentation !

I need convert Type1 File to Type2 in Real Time
I use "tool.dll" in "package version ... censure"
I use fonction LIB_GetHandle, LIB_OpenStream, LIB_SetMode, LIB_Convert ... and 8 another functions
It's more difficult, i read your Corean documentation with google translate, i not found english doc ?!

But 30 fonctions are c++ decorated in this tool.DLL
I use C++Builder 2007 (or Delphi)
This Microsoft decoration has not supported
I add extern "c++" or extern "c"

?LIB_GetHandle@@YGHPAJ@Z
?LIB_ReleaseHandle@@YGHJ@Z
?LIB_StopConvert@@YGHJ@Z
?LIB_Startonvert@@YGHJPADP6GXJJJPAH0@ZJ@Z

with extern c
[ILINK32 Erreur] Error: 'MaFonction' external not resolve...

with extern c++
[ILINK32 Erreur] Error: '__stdcall MaFonction(long)' external not resolve...

How integrated this fonctions with name mangling in C++Builder 2007 ?
I generated the file lib from the DLL implib (executable of borland, lib from MS is not supported)
I tried a DEF file with alias IMPDEF but char ? is refused by implib for original name !

LIBRARY tool.DLL

EXPORTS
LIB_GetHandle=?LIB_GetHandle@@YGHPAJ@Z
LIB_ReleaseHandle=?LIB_ReleaseHandle@@YGHJ@Z
LIB_StartConvert=?LIB_StartConvert@@YGHJPADP6GXJJJPAH0@ZJ@Z
LIB_StopConvert=?LIB_StopConvert@@YGHJ@Z

implib : Error ....def(4): Invalid character in .DEF file
If i delete ? char, implib make the lib file but wrong name

How to fix this?

Monday, I would replace static linking with calls dynamically via LoadLibrary and GetProcAddress, I hope this will solve the problem

---

sa r�ponse franchement pitoyable, m�me pas capable d'utiliser son correcteur orthographique pour taper un e-mail correct en anglais !
En m�me temps, pas de surprise c'est notre offre "premier prix" !
j'ai �t� surpris de voir un SDK aussi bien fichu pour un matos si "cheap" !

Citation:

---

would you mind telling me where you are from and more infomationa bout yoru coampny? so i can arrange someone to contat withyou soon ?

---

Salut ShaiLeTroll
je trouve excellent ta mani�re g�n�rique de charger en m�moire les diff�rents fonctions contenues dans une dll via des interfaces
mais comment fait-tu avec les diff�rentes conventions d'appels (thiscall,fastcall.stdcall,cdecl) ?
je ne l'ai pas remanqu�e dans le bout de code d�livr�
cdlt

note que j'ai mis WINAPI

Code:

---

1 2	#define WINAPI __stdcall

---

La g�n�ricit� se limite � MES DLL parce que j'ai mis ce syst�me en place !
C'est un pompage du mod�le COM qui lui passe par 4 exports standard,
DllCanUnloadNow, DllGetClassObject, DllRegisterServer et DllUnregisterServer, moi j'ai juste un �quivalent pour DllGetClassObject, je n'ai pas d'enregistrement et je g�re manuellement la lib�ration (le COM g�re un compteur d'interface qui doit d�charger automatiquement la DLL ou l'EXE si l'on a plus d'instance dessus)

Je n'ai jamais trouv� en COM comment faire pour charger dynamiquement une DLL via son NOM et pas par le GUID pour instancier ses Interfaces sans devoir l'installer !
C'est ce qui me g�ne le plus avec le COM, c'est le d�ploiement certes facile avec RegSvr32, mais on est oblig� de cr�er une classe GUID diff�rente pour chaque DLL et c'est assez p�nible de g�rer la m�me interface dans plusieurs TLB (il faut la recopier � chaque fois, c'est tr�s moche)

En fait, j'ai pour principe de toujours faire une classe d'encapsulation des DLL, que ce soient mes DLL ou des DLL tiers, je ne les utilises jamais directement, ainsi si je change de DLL, je n'ai qu'� refaire le wrapper en esp�rant pouvoir refournir la m�me interface !
Parfois, il est n�cessaire d'assouplir la classe d'encaspulation, on peut s'en sortir avec un Pattern Adapter
D'ailleurs, je pratique souvent le couplage Factory\Registry qui finalement s'apparante � une Patten Strategy

Mon chargement g�n�rique est li� � l'architecture que j'ai mis en place, toutes les DLL "Hardware" que j'ai cr�� pour piloter diff�rent type de p�riph�rique respecte le m�me exports, � par le fichier DEF que je dois faire pour chaque projet, la premi�re �tape c'est la cr�ation d'un fichier contenant ceci

Code:

---

1 2 3

EXPORTS GetHardwareProviderInterface GetHardwareLastError

---

Pour l'impl�mentation de ces deux fonctions, j'inclus une unit� toute pr�te "HardwareAbstractExports.cpp" dont le .H contient ceci

Code:

---

1 2 3 4 5 6

extern "C" { // Exportation non décorée par Extern "C" ! IHardwareProvider* WINAPI GetHardwareProviderInterface(); THardwareInterfaceErrorType WINAPI GetHardwareLastError(); }

---

le code �tant commun

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

IHardwareProvider* WINAPI GetHardwareProviderInterface() { IHardwareProvider* Result = NULL;   if (CHardwareAbstractDLLExports::FInstance) Result = CHardwareAbstractDLLExports::FInstance->GetHardwareProviderInterface();   return Result; }   //--------------------------------------------------------------------------- THardwareInterfaceErrorType WINAPI GetHardwareLastError() { THardwareInterfaceErrorType Result = shwieIncompleteDLL;   if (CHardwareAbstractDLLExports::FInstance) Result = CHardwareAbstractDLLExports::FInstance->GetHardwareLastError();   return Result; }

---

FInstance est d�clar� ainsi !

Code:

---

static CAbstractDLLExports* FInstance;

---

et CAbstractDLLExports::GetHardwareProviderInterface utilise en interne une m�thode abstrait GetHardwareProviderInstance

Code:

---

/*abstract*/virtual THardwareAbstractProvider* GetHardwareProviderInstance() = 0;

---

IHardwareProvider devient le nouveau point d'entr�e, l'API GetHardwareProviderInterface est utilis� une seule fois, maintenant que l'on a l'interface, on a acc�s toutes les fonctionnalit�s de la DLL de Hardware !

Le Main de la DLL est toujours comme ceci
Note que la variable est du type h�rit� CBiduleTrucDLLExports qui impl�mente les m�thodes abstraites de CAbstractDLLExports (dont l'Interface Factory)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved) { static CBiduleTrucDLLExports DllExportObject; // mon singleton !!!   switch( reason ) { case DLL_PROCESS_ATTACH : DllExportObject.DLLProcessAttach(); break;   case DLL_THREAD_ATTACH : case DLL_THREAD_DETACH : break;   case DLL_PROCESS_DETACH : DllExportObject.DLLProcessDettach();   break; }   return 1; }

---

Code:

---

1 2 3 4 5 6 7 8 9

void CAbstractDLLExports::DLLProcessAttach() { CAbstractDLLExports::FInstance = this; }   void CAbstractDLLExports::DLLProcessDettach() { CAbstractDLLExports::FInstance = NULL; }

---

Ainsi d�s que l'on entre dans la DLL, j'ai mon point d'entre unique qui existe et peut-�tre utilis� dans la foul�e !

L'astuce consiste que chaque classe h�rit�e de CAbstractDLLExports impl�ment�e dans chaque DLL va cr�er son propre IHardwareProvider qui expose tout une s�rie de fonctions et propri�t�s standards pour identifier un Hardware !

THardwareAbstractProvider est la classe anc�tre qui impl�mente une partie commune de IHardwareProvider, certaines m�thodes devant �tre impl�ment�e par un objet h�rit� par exemple THardwareBiduleTrucProvider ... chaque DLL aura sa propre impl�mentation dont l'une renvoie la liste des Mod�les g�r�es par la DLL via une IHardwareModelList, effectivement pour des appareils d'une m�me marque, certains fournissent des protocoles g�n�riques d'autres sp�cifiques � une gamme d'appareil, il faut donc pr�voir l'utilisation de DLL tiers ou de protocoles qui peuvent �tre diff�rent, l'un par exemple serait purement une DLL, un autre un OCX ou encore m�me un pilotage en HTTP ou une configuration via la MIB, les fabricants ont une grande imagination !
Chaque IHardwareModel re�oit une impl�mentation par un objet h�rit� d'un THardwareAbstractModel qui se nommerait dans notre cas THardwareBiduleTrucModelBlueSerie et THardwareBiduleTrucModelRedSerie si l'on avait deux mod�les
C'est objet Model fournisse une Factory de THardwareEntity\THardwareAbstractEntity qui serait dans notre cas des THardwareBiduleTrucEntityBlueSerie et THardwareBiduleTrucEntityRedSerie

Ensuite, le Hardware Entity propose un Purpose qui est une Delphi Interface et s'utilise avec un GUID et Supports !
Un m�me Purpose pourrait impl�menter plusieurs Interface GUID
On peut d�couper les taches d'un p�riph�rique en plusieurs groupes, les taches basiques et communes � tous, les taches avanc�es que les mod�les les moins chez ne fournissent pas et les taches sp�cifiques pour les mod�les les plus performants !

C'est cette Delphi Interface qui va amener les fonctionnalit�s sp�cifiques du Device et l� c'est illimit�, tout d�pend le mat�riel, cela peut �tre une Cam�ra, un Bras m�canique, une Porte...

D'ailleurs j'�voquais cela dans le sujet TADOConnection + Unresolved external


EDIT : Pour ma fameuse DLL qui m�lange C et C++, j'ai au moins 10 versions diff�rentes, en fait, selon le package, je n'ai pas les m�me exports, j'ai plusieurs packages (des ZIP) contenant des D�mos montrant l'utilisation de DLL !
Moi, un peu b�te, j'ai pris la DLL accompagnant la D�mo ! :roll:
Mais la m�me DLL est contenu dans d'autres Packages qui concernent une autre partie du p�riph�rique que j'ai cod� il y a presque 6 mois et sur les 100 fonctions seules 3 sont d�cor�es dans cette version mais les 4 fonctions que j'utilise ne le sont plus !
Du coup, j'ai pris ce package (en plus c'est la derni�re release) sans avoir besoin de mettre dans alias !
J'ignore pourquoi ce fabricant fourni des versions diff�rentes de m�me DLL !
Leur SDK est bien fichu mais leur gestion des versions est �trange !

Faudra que je pense qu'� chaque fois que je r�cup�re une nouvelle version � v�rifier leurs exports, ils ont l'air de g�rer �a en dilettante !