Discussion :

[KindPlayer]

Code :

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

IASAPI_API std::string _HB(CBlob const & blob);

jsais pas si ca va beaucoup t'éclairer. CBlob est une classe qui sert de wrapper pour un buffer binaire. Dailleurs _HB a deux signatures différentes puisqu'elle permet de passer de CBlob à string et inversement:

Code :

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

IASAPI_API CBlob _HB(std::string hex);

[koala01]

Salut,

La question va peut-être te paraître stupide (mais je m'en fout: si le ridicule tuais, je serais mort depuis longtemps ), mais, si j'ai bien compris, le but de cette fonction est... d'obtenir sous forme de chaines utilisant la notation hexadécimale, les valeurs d'un buffer et inversément

Dés lors, ne pourrais tu, tout simplement, pas obtenir un résultat similaire sans passer par la fonction de la DLL

Je me rend bien compte que cela relativise l'intérêt de la DLL, étant donné que cela signifie réinventer la roue pour quelque chose d'existant (et de théoriquement testé), mais cela te permettrait de contourner le problème d'ABI différentes

[KindPlayer]

en fait j'utilise massivement une fonction de l'API qui prend en parametre, entre autres, une référence à un CBlob et je veux récupérer la chaine hexa correspondant à ce CBlob. Me passer de la classe définie dans l'API m'obligerait à me passer de la seule fonction de l'API que j'utilise réellement.

[koala01]

A vrai dire, je te proposais de te passer de la fonction, et non de la classe... Quoi que, le problème est bel et bien similaire: idéalement, CBlob étant - sauf avis contraire - une classe avec tout ce qui en découle, la DLL ne devrait pas renvoyer d'élément de ce type vers l'application qui l'utilise (cf tous les messages précédents)...

Mais ceci dit, j'ai personnellement la conviction (même si cela n'engage que moi) qu'il vaut parfois mieux "réinventer la roue" (dans ton cas, il s'agirait de recréer une classe CBlob et les différentes fonctions que tu utilise) que de persister à vouloir utiliser quelque chose d'existant dont il apparaît à l'usage que ce n'est pas adapté du fait des restrictions que cela impose...

En effet, ce que tu écrivais plus haut est tout à fait juste: un code de départ "crade" impliquera une manière "crade" de coder ce qui en dépend.

Dans cette optique, et parce qu'un bon ouvrier utilise normalement de bons outils, la meilleur décision à prendre - pour difficile qu'elle puisse paraître - me semble être de virer les "mauvais" outils

[KindPlayer]

Simplement si je réécris une classe CBlob à ma façon (c'est pas dit que ce soit moins crade ), il faudrait également que je réécrive par exemple cette fonction

Code :

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

1
2
3
4
void sendAPDU (	unsigned char cla, unsigned char ins,
			unsigned char p1, unsigned char p2,
			CBlob const & data,  unsigned long le,
			CBlob &response, unsigned short &sw12);

qui envoie des commandes à une smartcard. Je n'ai pas les compétences pour écrire ca. Et d'une manière générale la quasi totalité des objets de l'API utilise CBlob qui en est presque une brique de base. Donc de ce coté la je suis coincé. Merci quand même pour tes recommandations, j'aurais quand même appris des choses aujourd'hui c déjà ça.

[KindPlayer]

Tu parlais de la fonction et pas de la classe :$. Ben peut-être que c'est possible jvais regarder mais je ne sais pas comment est représenté le buffer au sein de cette classe, c'est assez opaque et je risque de générer plus de bugs que d'en résoudre

[Emmanuel Deloget]

Simplement si je réécris une classe CBlob à ma façon (c'est pas dit que ce soit moins crade ), il faudrait également que je réécrive par exemple cette fonction

Code :

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

1
2
3
4
void sendAPDU (	unsigned char cla, unsigned char ins,
			unsigned char p1, unsigned char p2,
			CBlob const & data,  unsigned long le,
			CBlob &response, unsigned short &sw12);

qui envoie des commandes à une smartcard. Je n'ai pas les compétences pour écrire ca. Et d'une manière générale la quasi totalité des objets de l'API utilise CBlob qui en est presque une brique de base. Donc de ce coté la je suis coincé. Merci quand même pour tes recommandations, j'aurais quand même appris des choses aujourd'hui c déjà ça.

Pas très compliqué - l'API smart card de Windows est relativement simple.

Bon, d'ou elle vient cette DLL ? a la voir comme ça, il s'agit de quelque chose qui a été développé en interne. N'y a t-il pas moyen d'éviter l'utilisation de _HB, ou de redéfinir cette fonction ?

Ceci dit, L'interface de CBlob ne doit pas être très compliquée. Un petit:

Code :

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

1
2
3
4
5
6
7
8
9
std::string to_hex(const CBlob& blob)
{
  std::stringstream ss;
  for (std::size_t i=0; i<blob.length(); ++i)
  {
    ss << std::hex << std::setw(2) << std::setfill('0') << blob.get_byte(i);
  }
  return ss.str();
}

Je pré-suppose l'existence d'une fonction qui donne la taille du blob (CBlob::length() dans mon exemple) ainsi qu'un moyen pour récupérer le ième byte du blob (CBlob::get_byte(std::size_t) dans mon exemple). Mais de toute façon, il faut bien que CBlob ait une interface permettant de récupérer les informations coté client, non ?

(Note: les identifiants dont le nom commence par un _ et une majuscule sont reservés par le standard C++ pour l'implémentation. Il n'est pas garanti qu'il n'existe pas un identifiant _HB défini par ton compilateur pour une raison quelconque. Raison de plus pour demander des modifications de la librairie).

[KindPlayer]

En effet la classe CBlob dispose d'une méthode size() ainsi que d'une surcharge de [] permettant d'accéder au ième byte. En revanche pas de méthode du type data() permettant de récupérer la chaine hexa. Mais en m'inspirant de ton exemple jpeux essayer de bricoler un truc qui remplace _HB
Merci