Discussion :

[Feneck91]

Bonjour � tous et � toutes...

Le contexte : un ensemble de dlls sans code source mais avec les headers. D'apr�s ce que j'ai lu il semble que les dlls soient compil�es en Visual C++ 6.0
Cet ensemble de dlls (3) ont d�j� �t� wrapp�es en Java via JNA et �a fonctionne tr�s bien, le but est de faire le m�me en C++ CLI et/ou en CSharp pour attaquer ces librairies en CSharp.

Etude 1 : wrapper via un CLI

Je l'ai d�j� fait.. aller go, on commence en C++ CLI, on cr�e un projet tout �a...
Je code, je link et l� 1er probl�me : il n'aime pas les .lib livr�s avec les dlls : xxxxxxx.lib : fatal error LNK1136: invalid or corrupt file

Je vous livre les deux batchs et le vbs qui permettent de g�n�rer un .lib au format compr�hensible par Visual Studio 2015 � partir des dlls pr�sentes dans le r�pertoire.

1. CallVCVarsAll.bat : permet de lancer 'vcvarsall.bat' du bon visual en allant chercher le chemin d'installation en base de registre.
2. GenerateDef.vbs : permet de cr�er le .def � partir du fichier export cr�� � partir de la dll.
3. GenerateLibs.bat : permet de cr�er un .lib par dll trouv� dans le r�pertoire dans lequel il est ex�cut�.C'est ce batch qui utilise les deux autres fichiers.

Donc, je cr�e les .lib � partir des dlls je compile, �a link. J'acc�de aux variables globales pr�sentent dans la dll (des messages d'erreurs en const char *). Et �a fonctionne !
Sit�t que je tente d'acc�der � une fonction un probl�me se pose : le mangling.
Voir ligne 243 du fichier GenerateDef.vbs, j'ai tent� des trucs diff�rents !
En gros, les variables globales n'ont pas de mangling et c'est pour �a que �a fonctionne... Mais pour les fonctions c'est autre chose !

1er cas : la fonction const char* HwdContextGetHwdRootPath( void );
l'export de g�n�re :
29 1C 000094C0 _HwdContextGetConfigPath@0
Si je g�n�re le fichier def en HwdContextGetConfigPath@0 �a link bien (dans le C++ CLI) mais lorsque je tente son chargement une erreur est g�n�r�e indiquant : Le point d'entr�e de la proc�dure HwdContextGetConfigPath@0 est introuvable dans la biblioth�que de liens dynamiques xxxxx.dll !

2�me cas : la fonction const char* HwdContextGetHwdRootPath( void );
l'export de g�n�re :
29 1C 000094C0 _HwdContextGetConfigPath@0
Si je g�n�re le fichier def en _HwdContextGetConfigPath@0 �a ne link plus car il y a un _ (underscore) en d�but du nom de la fonction, ce qui est d'ailleurs bien pr�sent dans l'export r�alis� � partir de la dll !
Les autres tests donnent les m�mes probl�mes de link si je g�n�re _HwdContextGetHwdRootPath.
J'ai tent� de faire l'import de plein de fa�on diff�rente mais rien n'y fait, ce mangling fait chier !

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
extern "C" __declspec(dllimport) char const * __fastcall HwdContextGetHwdRootPath(void);
__declspec(dllimport) char const * __fastcall HwdContextGetHwdRootPath(void);
 
__declspec(dllimport) char const * __stdcall HwdContextGetHwdRootPath(void);
extern "C" __declspec(dllimport) char const * __stdcall HwdContextGetHwdRootPath(void);
 
__declspec(dllimport) char const * __cdecl HwdContextGetHwdRootPath(void);
extern "C" __declspec(dllimport) char const * __cdecl HwdContextGetHwdRootPath(void);

Les pistes ?

• Je ne peux pas r�g�n�rer une lib d'une dll si je n'utilise pas le m�me compilateur que celui qui a g�n�r� la dll ?
• Il y a une fa�on de faire l'import pour que le mangling ne pose pas de probl�me et je n'ai pas trouv� comment ?

[U]Etude 2 : wrapper directement via CSharp[U]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
    static class kernelhdr
    {
        [DllImport("kernelhdr.dll")]
        public static extern IntPtr HwdContextGetHwdRootPath();
    }
 
    void main()
    {
        IntPtr toto = kernelhdr.HwdContextGetHwdRootPath();
        var value = Marshal.PtrToStringAuto(toto);
    }

Et l�, plus besoin de lib, �a g�n�re tout seul, �a fonctionne (en tout cas l'appel me retourne une cha�ne vide).
Plus simple, rapide que demande le peuple ? En plus le mangling n'a pas l'air de le d�ranger du tout (mais alors pourquoi �a ne fonctionne pas en C++ CLI ?).
Sauf que .... les variables globales, elles, ne sont pas accessibles dans ce mode, la cha�ne HWDERR_DIGEST_FILE_READ qui est un extern "C" extern __declspec( dllexport ) char HWDDIGEST_FORMATVERSION_UNKNOWED[]; n'est pas accessible par :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
    static class kernelhdr
    {
        [DllImport("kernelhdr.dll")]
        public static extern IntPtr  HWDDIGEST_FORMATVERSION_UNKNOWED; 
    }

Ceci n'est pas autoris� par le compilateur et impossible de savoir comment acc�der � une variable membre globale de la librairie, � priori on ne peut r�f�rencer que des fonctions !

Etude 3 (non r�alis�) : wrapper directement via CSharp pour les fonctions et faire des LoadLibrary / GetProcAddress pour les variables globales.
Cel� pourrait peut-�tre fonctionner mais qu'est-ce que c'est lourd !!!!

Vous avez d�j� �t� confront� au probl�me ? Vous avez des pistes, au mieux une solution ? Je suis preneur !
Je ne me fais pas trop d'illusion mais j'esp�re trouver une solution...

[M�dinoc]

Si la DLL a d�j� une interface C, je serais pour la m�thode 2 aussi (mais les variables globales compliquent le truc).
Personnellement j'utiliserais la solution de facilit�: Faire un wrapper pour les variables globales (avec des fonctions getter et setter pour chaque variable) dans une autre DLL non-manag�e, et r�f�rencer les deux DLLs depuis le C#.

[Feneck91]

C'est un mix entre la solution 1 et 2, et �a oblige � se trimbaler deux projets (ou un projet + un fichier csharp), pourquoi pas, mais bon c'est quand m�me cracra !
Surtout que je devrais pourtant r�ussir � tout linker correctement dans mon projet CLI !