Utilisation d'une fonction de bibliothèque qui change de nom

**oodini** · 18/09/2009, 14h52

Hello,

J'ai une application qui utilise une bibliothèque dont le codeur est quelque peu cavalier, et qui change les noms de fonction sans trop de soucier des implications.

Une version donnée de mon application doit pouvoir utiliser une version quelconque de cette bibliothèque. Je sais à partir de quelle version de la bibliothèque ont lieu les changements de noms de fonction.

Sachant que je la bibliothèque a une fonction fournissant son nom de version, est-il possible, à l'exécution, de faire un branchement dans le code pour gérer ça ?

Le problème est que mon code n'est "linkable" que pour pour une version donnée de l'API. Comment faire ??

Merci !

**Grulim** · 18/09/2009, 15h22

1ère Solution change de bibliothèque/de codeur

2ème solution, sous Windows, tu peux charger explicitement la bibliothèque et obtenir un pointeur sur chaque fonction manuellement (pratique si tu en as 100

).
3ème solution, faire 2 versions de ton programme, une avant changement et l'autre après.

Invité(e) · 18/09/2009, 15h28

Bonjour,

Pour charger une bibliothèque, on utilise LoadLibrary / GetProcAddress sous Windows, dlopen / dlsym sous unixoïdes.

Après, il faut savoir que demander l'adresse d'une fonction qui n'existe pas renvoie juste NULL, ça pourrait permettre de déterminer la version de la bibliothèque (mais le mieux, c'est d'avoir une fonction get_version).

**oodini** · 18/09/2009, 15h29

Envoyé par Grulim

1ère Solution...
2ème solution...
3ème solution...

La 1ère solution n'est pas envisageable. :-)

La 2ème solution ne me semble pas applicable, car mon programme est en mode console.

La 3ème solution est celle que j'applique actuellement, mais elle ne me satisfait pas.

Sachant que mon application est en fait appelée par un programme Java, peut-être devrais-je me débarrasser de cette appli en C, la transposer en Java, et utiliser JNA pour appeler l'API C...

Et suite à la réponse de mabu, tout semble en effet laisser penser qu'il faut effectivement passer en Java, qui via JNA offre à peu près la même chose.

**Grulim** · 18/09/2009, 15h32

Envoyé par oodini

La 2ème solution ne me semble pas applicable, car mon programme est en mode console.

??? Je parle de l'OS quand j'écris Windows...

**Mac LAK** · 18/09/2009, 15h33

Tu peux même faire un code auto-adaptable : tenter de charger la fonction initiale, si ça foire (retour de GetProcAddress valant NULL) tu tentes la "nouvelle", si ça re-foire tu déclares réellement l'erreur à l'utilisateur (à priori, DLL corrompue et/ou trop "nouvelle").

Le fait que l'application tourne en mode console ou pas n'a absolument aucune importance, LoadLibrary et GetProcAddress sont certes des fonctions de l'API Win32, mais elles n'exigent aucunement la moindre interface graphique (ni même la présence d'une console, d'ailleurs).

**oodini** · 18/09/2009, 16h04

À priori, c'est effectivement le comportement que je souhaite.

Je m'y connais fort peu en chargement dynamique de bibliothèque.
L'API me fournit des .h, un .lib, et un .dll. Jusqu'à présent, j'utilisais bêtement les .h et le .lib. Je suppose que le .dll offre exactement les mêmes services, mais est chargeable dynamiquement avec l:es fonctions que vous évoquez ?

**Mac LAK** · 18/09/2009, 16h29

Envoyé par oodini

L'API me fournit des .h, un .lib, et un .dll. Jusqu'à présent, j'utilisais bêtement les .h et le .lib. Je suppose que le .dll offre exactement les mêmes services, mais est chargeable dynamiquement avec l:es fonctions que vous évoquez ?

Le .LIB permet de lier la DLL à l'exécutable de façon "statique" (oui, je sais, ça parait bizarre à lire), dans le sens où l'exécutable devient publiquement dépendant de la DLL et ne peut plus démarrer sans elle (sauf cas particulier de delayed loading, mais qui ne permettrait pas de résoudre ton problème quoi qu'il en soit). De plus, ce .LIB permet aussi d'exporter de la DLL des entités qui ne sont normalement pas exportables, tel que des classes C++ ou des variables globales. Comme tu es en C, seul les variables globales pourraient poser un problème.

En gros, le principe se résume ainsi :

Ne plus inclure le .LIB dans ton projet.
"Traduire" le .H actuellement fourni vers un .H d'importation : tes fonctions vont devenir, pour chacune, un "couple" pointeur fonctionnel / type fonctionnel.
Un fichier .C devra contenir les variables fonctionnelles ainsi déclarées. Il faudra initialiser chacun de ces pointeurs de fonctions à NULL, par propreté.
L'édition de lien se passera sans problème, car ton .H fourni avec ta DLL trouvera ses petits dans ton fichier .C, sous forme de pointeurs de fonctions (qui ne valent rien de bon pour le moment, bien sûr).
Dans tes .C/.H nouvellement créés, tu vas ajouter une fonction du genre "int LoadMyDLL(char* DllName)", que tu appelleras au début du main(), destinée à connecter la DLL.
Pour chaque fonction, tu vas charger la fonction correspondante de la DLL, ou la "nouvelle" si cela échoue. A la fin de la chaîne de tentatives de chargement, tu testes si ton pointeur de fonction est NULL ou pas : si oui, c'est une erreur critique (=> boum), sinon, la fonction est correctement connectée.
Éventuellement, au lieu de provoquer une erreur, tu peux connecter la fonction manquante à une fonction stub, qui affichera un message du genre "Function XXXX is missing, please check version of YYYYY.dll"
Le principe est le même pour les variables globales, la différence étant dans le fait qu'il faut caster comme un goret et utiliser quelques trucs sales pour changer l'adresse de ta globale (ou alors, n'utiliser que le pointeur et devoir donc modifier le code utilisant ladite globale).
Le reste du programme ne devrait pas avoir besoin d'être modifié, et continuera à ne référencer que le .H d'origine. Seul le fichier contenant le main() devra explicitement faire référence à TON module de chargement.

Si tu es à l'aise avec les outils de génération automatique de code et/ou les analyses de texte, tu peux même automatiser complètement la création de ces fichiers de chargement : après tout, c'est déjà ce que fait Visual C++ lorsqu'il compile la DLL, la seule différence étant qu'il n'est pas tolérant à la faute contrairement à ce que permettra ton importation manuelle. Cerise sur le gâteau, ton code d'importation est compatible avec GCC si besoin, voire d'autres langages, si la DLL n'utilise pas de conventions d'appel exotiques ou de name-mangling.

**oodini** · 18/09/2009, 16h39

Merci pour cette réponse complète !!

J'ai toutefois encore quelques questions, notamment une sur les deux premiers points et le dernier.

L'API contient une quarantaine de .h, et seules deux fonctions posent problème. Ne puis-je continuer à utiliser le .lib, et à en faire appel au chargement dynamique que pour les fonctions qui posent problème ?

Je n'ai pas besoin de variables globales, et les performances ne sont pas un problème.

J'ai par ailleurs vérifié dans Depends.exe, et les fonctions ne semblent pas "manglées".

**Grulim** · 18/09/2009, 16h41

Ce n'est malheureusement pas possible de mixer les 2 modes.

**oodini** · 18/09/2009, 16h54

Bon, alors je vais partir sur la solution sans .lib.

En revanche, le second point me laisse perplexe. Si un .h déclare :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int maFonction(int a, int b);

que dois-je faire exactement, pour le .h ??

**Grulim** · 18/09/2009, 19h00

C'est plus dans le .c que la magie opère...

Ton code devrait ressembler à ça (pas tester) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
typedef int (* maFonctionLib_type) (int a, int b);
 
int maFonction(int a, int b)
{
  static maFonctionLib_type pfn;
  if( pfn == NULL )
  {
    pfn = (maFonctionLib_type)GetProcAdress(hDll, "maFonctionLibVersion1");
    if( pfn == NULL )
    {
      pfn = (maFonctionLib_type)GetProcAdress(hDll, "maFonctionLibVersion2");
    }
  }
  return (*pfn)( a, b );
}

une macro ferait bien l'affaire...

**oodini** · 21/09/2009, 14h44

Bon, ça me rassure : c'est ce que j'avais fait, d'après vos explications. :-)

En revanche, l'utilisation du .lib en sus ne semble pas gêner... Il faut dire que mon programme ne tourne pas vraiment, pour cause d'autre problème. Peut-être qu'à l'usage, le .lib se révélera effectivement gênant.

**Mac LAK** · 21/09/2009, 14h51

Envoyé par oodini

En revanche, l'utilisation du .lib en sus ne semble pas gêner...

En fait, tout dépend s'il reste des symboles non-résolus (=> piochés dans le .LIB) ou pas (=> le mettre ou pas n'a aucune importance).

Toutefois, par "sécurité", je te conseille de l'enlever.

**oodini** · 21/09/2009, 15h06

Envoyé par Mac LAK

En fait, tout dépend s'il reste des symboles non-résolus (=> piochés dans le .LIB) ou pas (=> le mettre ou pas n'a aucune importance).

Ben je l'ai justement laissé pour piocher dedans sans charger dynamiquement toutes les fonctions qui ne me posent pas problème.

**souviron34** · 21/09/2009, 15h23

ya une question que je me pose...

Pourquoi ne pas faire simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
  switch ( NumVersion )
    {
         case 1 :
            return FonctionVer1( a, b );
         case 2 :
            return FonctionVer2(a,b);
   }

?

puisqu'au link il faut les 2 ??

**Grulim** · 21/09/2009, 15h25

Envoyé par oodini

Ben je l'ai justement laissé pour piocher dedans sans charger dynamiquement toutes les fonctions qui ne me posent pas problème.

Mais l'utilisateur qui a version de la dll avec des noms de fonction différents va se prendre un message d'erreur à l'exécution...

**Médinoc** · 21/09/2009, 15h56

Envoyé par Grulim

Ce n'est malheureusement pas possible de mixer les 2 modes.

Si, avec le chargement retardé (delay-loading DLLs) c'est possible, sous Visual Studio.

Mais là, on se retrouve à gérer des exceptions Win32 ou fournir des fonctions callback...