Bonjour,

Je suis actuellement entrain de créer un code qui a pour but d'accéder à une API proposé par Simulink.

Pour cela je dois lier une bibliothèque .dll à mon projet pour avoir accès aux fonctions de l'API. J'ai cherché sur internet les méthodes à suivre pour lier cette bibliothèque dynamique. J'ai appris qu'il fallait utiliser les fonctions "LoadLibrary" et "GetProcAddress". Pourtant je n'arrive toujours pas à accéder à mon API.

Voici la partie de mon code ou j'essaie de loader l'API.

tu dois mettre ta fonction retourner dans un pointeur de fonction:

xPCInitAPI (*pfonc)() = NULL;

après tu fais un mélange de C et C++ assez indigeste quand meme

fait voir ton code

-
Edité par charly33 17 avril 2018 à 17:36:10

Je viens après la bataille.

Les machins à base de LoadLibrary et autres vieilleries, c'était bon pour les années 80 et 90, pas en 2018.

Vérifiez que l'éditeur de cette dll n'utilise pas des frameworks d'inter-opérabilité ou ne fournissent pas des .h et des .lib directement opérationnelles, plutôt que de vous téléporter dans la pré-histoire de l'informatique.

Bon, Google me dit que ça sent le bon vieux machin en C de base qui tâche.

Le "typedef" déclare un type, pas une fonction, mais à la rigueur, ici, c'est un type de fonction (sa signature).

L'espace dans le chemin de la Dll, ça sent pas bon.

Utilisez le débogueur pour voir comment ça se passe au Runtime.

l'api win32 est encore d'actualité ce n'est pas une vieillerie , c'est pour le langage C

et donc loadlibrary est utilisé tout comme le même object sous .NET

non? pk?

A très bas niveau oui, mais les runtimes modernes ont des procédures d'import automatisés avec des bibliothèques d'export, ce qui fait qu'en dehors de cas super rares on ne monte jamais une dll à la main avec LoadLibrary/GetProcAddress (J'en monte deux comme ça dans une appli embarquée, à elle deux il n'y a pas plus d'une dizaine de fonctions, mais je les monte comme ça, parce que je dois les monter en fonction de la configuration du programme, et bien sûr la configuration, je ne pourrais jamais la connaître à la compilation ou au link). En fonction de la configuration, je monte une dll ou une autre, ces dll attaquant du hard, elle ont toutes la même interface, mais comme elles attaquent le même hard, je ne peux en monter qu'une seule, donc là pas trop le choix, c'est la configuration qui me dit laquelle je dois monter et c'est forcément LoadLibrary/GetProcAddress.

Pour toutes les autres, je fais un link avec la bibliothèque d'export des dll dont j'ai besoin. Je n'imagine même pas l'enfer, si je dois monter openSSL en LoadLibrary/GetProcAddress. Sur des bibliothèques purement C++, avec des centaines voir des milliers de fonctions, c'est juste pas imaginable...

L'API Win32 est certes d'actualité, mais c'est une vieillerie, M$ fournit des tonnes de wrappers, pour qu'on ait quasiment plus  jamais besoin de descendre aussi bas (.Net, et même l'antédiluvienne MFC...) , la plupart des gros framework le font aussi(Qt, wxWidget...).

-
Edité par int21h 23 octobre 2018 à 21:59:31

@int21h, tu peux pas gérer ton "problème" de chargement dynamique avec du delayloading ?

int21h a écrit:

En fonction de la configuration, je monte une dll ou une autre, ces dll attaquant du hard, elle ont toutes la même interface, mais comme elles attaquent le même hard, je ne peux en monter qu'une seule, donc là pas trop le choix, c'est la configuration qui me dit laquelle je dois monter et c'est forcément LoadLibrary/GetProcAddress.

Je suis dans le même cas, mais selon la config utilisateur. Comment t'y prends-tu ? Même signatures, même exports et tu change juste la string de ta LoadLibrary ?

Pensez au delay loading de dll.

https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/09t6x5ds(v=vs.120)

@bacelar sous Windows CE 5.0, j'ai des doutes ^^  J'ai un LoadLibrary à faire et au grand max une dizaine de GetProcAddress, ça marche comme ça, je vais ne vais pas prendre le risque de tout mettre par terre, d'autant que CE 5.0 n'est plus supporté par M$ et que la plateforme sur laquelle je fais ça est en fin de vie... Là je suis plus dans la gestion d'un existant préhistorique, le temps de son extinction que dans le développement d'une solution pérenne

@Lilikyanil Le programme lit ses fichiers de configuration au démarrage et détermine quelle dll il doit monter. Suivant ce qu'il va trouver dans ses fichiers de configuration, il va choisir la dll à monter, et éventuellement la configurer, parce que si certaines dll sont très spécifique, la plupart des instances de mon programme préparent un fichier de configuration avec tout ce qui va bien et montent presque toujours la même dll (on va dire 99% du temps...). Si je veux changer, la plupart du temps, ce n'est pas possible sans un reboot complet de la plateforme (Le déchargement des drivers sous CE 5.0, c'est pas une entreprise fiable...), donc je prépare tout et je demande un reboot (en fait comme j'ai un watchdog, quand j'ai fini ma mise à jour, "j'oublie" de faire le refresh du watchdog, et j'ai ainsi le reset hardware de la carte dont j'ai besoin )

-
Edité par int21h 25 octobre 2018 à 0:09:23

bacelar a écrit:

Pensez au delay loading de dll. 

https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/09t6x5ds(v=vs.120)

Chaque module est susceptible de se load et de s'unload au cours du programme. Alors qu'au runtime tout les modules sont actifs, l'utilisateur peut choisir d'en désactiver certains puis de les réactiver par la suite.

Donc je n'ai à priori aucune excuse mais je ne saurais dire pour quelles raisons, je suis réticente...

Je ne comprend pas exactement quand est-ce que cette fonction va se mettre au travail. Est-ce qu'elle hook quelque chose en particulier ?

int21h a écrit:

Si je veux changer, la plupart du temps, ce n'est pas possible sans un reboot complet de la plateforme (Le déchargement des drivers sous CE 5.0, c'est pas une entreprise fiable...), donc je prépare tout et je demande un reboot (en fait comme j'ai un watchdog, quand j'ai fini ma mise à jour, "j'oublie" de faire le refresh du watchdog, et j'ai ainsi le reset hardware de la carte dont j'ai besoin )

Un peu bidouille mais smart

@int21h, ce truc est venu avec VC++6, largement avant WinCE, donc WinCE5.0, mais effectivement pour un code opérationnel, mourant, de quelques primitives, c'est overkill.

@LilyKianii, j'ai pas testé le déchargement et cela semble géré :

https://msdn.microsoft.com/fr-fr/library/96c1b5cf.aspx

Le mécanisme est assez simple. Chaque fonction importée d'une Dll dispose d'une entrée dans l'IAT. Avec l'option /delayload, le code de remplissage de ces entrées, qui est normalement exécuté par le chargeur de programme de l'OS, est remplacé par un code qui met toujours la même valeur dans les entrées pour les fonctions de la Dll, cette valeur est le code de chargement "dynamique" de la Dll. Donc, au premier appel d'une fonction importée d'une Dll, ce code de chargement "dynamique" de la Dll est appelé, fait le chargement de la Dll et remplit les entrées de l'IAT avec les "bonnes" valeurs.

Toi, tu ne fais que customiser le code qui sera appelé lors de ce chargement dynamique.

Pour un mécanisme qui charge et décharge des composant dynamiquement, j'aurai tendance à m'appuyer sur des frameworks dédiés aux plug-ins, aux applications composites, voire COM ou les assemblies .NET.

bacelar a écrit:

le code de remplissage de ces entrées, qui est normalement exécuté par le chargeur de programme de l'OS, est remplacé par un code qui met toujours la même valeur dans les entrées pour les fonctions de la Dll, cette valeur est le code de chargement "dynamique" de la Dll. Donc, au premier appel d'une fonction importée d'une Dll, ce code de chargement "dynamique" de la Dll est appelé, fait le chargement de la Dll et remplit les entrées de l'IAT avec les "bonnes" valeurs.

Toi, tu ne fais que customiser le code qui sera appelé lors de ce chargement dynamique.

ça a l'air de correspondre au besoin à première vu, j'y donnerai un essai.

bacelar a écrit:

Pour un mécanisme qui charge et décharge des composant dynamiquement, j'aurai tendance à m'appuyer sur des frameworks dédiés aux plug-ins, aux applications composites, voir COM ou les assemblies .NET.

COM je m'en sert pour mon interface C# (que certains modules vont d'ailleurs susciter) mais j'ai l'impression que c'est une vraie purge à performances...

J'ai pas pris le temps d'explorer d'autres pistes pour le moment.

Comme tu peux le voir, le mécanisme de delayload est "close to metal", tu peux facilement évaluer "l'overhead" du machin.

COM, c'est pour faire du modulaire langage agnostique, il est donc assez facile de faire des boulettes en terme de conception qui se répercutent sur les performances.

COM peut servir pour la communication C++/C# mais il est plus simple et plus direct de passer par du C++/CLI, avec un plus grand contrôle du bazar et donc mieux voir les éventuelles boulettes de conception.

Après, des framework de plug-ins et d'application composite, c'est pas ça qui manque.