Discussion :

[Mat.M]

Bonjour,
Je travaille actuellement sur une application en C++. J'aimerais créer une API pour cette application qui me permettrait d'utiliser ses fonctions depuis l'extérieur. En effet, j'aimerais pouvoir utiliser cette API pour créer des plugins en C++ pour cette application.

le plus simple c'est de commencer par compiler un fichier .lib ou une dll "simple".

Merci pour vos conseils. J'y ai réfléchi et j'ai décidé de faire un plugin sous forme de DLL d'extension MFC, qui affiche lui-même une fenêtre en plus de la fenêtre principale. Comme MFC gère tout ça, et que l'appli et l'extension sont très liées, il n'y a pas de souci à priori.

en général en programmation windows on a recours à des plug-ins développés avec l'architecture Component Object Model plutôt que MFC...

Je sais que ms-office par exemple c'était à 90% peut-être bâti sur une architecture COM maintenant je crois que c'est tout en NET

le projet sur lequel j'avais travaillé d'imagerie médicale c'était majoritairement des plug-ins COM qui sont encore utilisés avec un frontal sous C#/.NET
l'appli avant utilisait VB6 comme ça ça permettait dans le code VB de faire new d'un objet C++.
L'avantage des objets COM c'est qu'ils sont enregistrés dans la base de registre, on peut en charger plusieurs instances
Mais c'est trop complexe pour être expliqué ici

Maintenant je bloque sur l'appel des fonctions de mon Api (qui sert d'interface entre les fonctionnalités de mon application et la DLL) depuis la DLL. Le but étant que la DLL puisse utiliser des fonctionnalités de mon application.

d'où l'intérêt d'une DLL COM ça permet de s'interface plus aisément qu'une dll MFC

J'ai également une question plus avancée:
Est-il possible de faire communiquer un plugin avec l'application qui l'a chargé? Je m'explique: imaginons que mon application ait une classe "Config", singleton, qui contienne des infos en "temps réel" (selon les dernières modifications de l'utilisateur pendant l'exécution de l'application), est-il possible d'accéder à l'instance de cette classe depuis mon plugin?

pour faire communiquer l'application soit on utilise des "pipes" en win 32 soit encore une fois des "fires" avec un objet COM

Le projet d'imagerie médicale sur lequel j'ai travaillé c'était le cas..

L'application est en C++ et utilise MFC. Comment fonctionnerait grosso modo un système de plugins fait avec MFC? Les plugins eux-mêmes devraient utiliser MFC également?

utiliser les MFC c'est du 50/50 perso je ne le ferais pas et puis l'API win32 c'est pas si compliqué que cela
MFC simplifie le travail mais ça fait des exécutables plus lourds ou alors il faut redistribuer le runtime

Je pense que tu cherches un peu trop "générique", il faut focaliser tes recherches sur tes besoins précis.
MFC est un Framework graphique d'assez bas niveau ( en terme d’abstraction ).

mais non pas du tout MFC n'est pas bas-niveau.
1-MFC c'est un équivalent de NET (avant la mise en servide de NET ) mais pour le C++ ( quoiqu'on peut faire du code managed en C++ )
Avec MFC on peut créer des fenêtres en 2 ou 3 lignes là où en win32 il faut 50lignes

2- pour un plug-in oui il faut faire forcément générique sinon ça n'a pas d'intérêt donc proposer un certain niveau d'abstracvtion

J'ai déjà fait des trucs où l'interface était créée à partir de méta données contenus dans une base relationnelle, donc c'est possible, et sans utiliser COM/OLE Control/ActiveX, donc il n'y a pas qu'une solution.

oui d'accord mais pour un projet conséquent vaut mieux utiliser COM/Active X...
parce que l'intérêt c'est que le client en NET, VB6..peut instancier des objets

[bacelar]

Cependant, cela ne me permet toujours pas de déboguer ma DLL d'extension MFC (càd mon plugin). Je me doutait que ça ne fonctionnerait pas, car il n'y a pas vraiment de lien entre le débogueur et le plugin lancé depuis l'appli...

Y a-t-il une méthode?

What ???
Bien sûr qu'il a un lien entre le débogueur et le plugin lancé !!!
Quand vous configurez vos options dans le section "débogage" de votre projet, vous indiquez un exécutable à lancer.
VS lance cet exécutable en mode "debuggee" avec comme garde-chiourme notre débogueur adoré.
Le débogueur est donc averti quand le programme se prend un "int3" (interruption n° 3, c'est comme ça que sont implémentés les points d'arrêt), mais aussi quand le programme tente de charger une Dll.
Le débogueur zyeute si c'est l'une des Dll qu'il doit surveiller (celle du projet l'est de base, mais il y a des options pour en mettre plusieurs sous surveillance), charge le .pdb associé à la Dll s'il le retrouve, et vérifie qu'il n'y a pas de break-point en cours (c'est le .pdb qui fait le pont entre l'exécutable/dll et le code source). S'il y en a, bin, pas de problème, il colle une instruction int3 comme un gros bourrin dans le code binaire supposé contenir la ligne avec le break-point.
Forcément, en release, avec les optimisations, la méthode de bourrin a tendance à ne pas être super précise, voir ne pas être applicable du tout en cas d'inlining. Le débogueur le signale, dans ce cas, en désactivant lui-même ces points d'arrêt.

Donc, déboguer une Dll Plug-Ins, c'est aussi simple que déboguer une application, faut juste faire gaffe à bien générer les .pdb de la Dll.

En effet le concepteur de plugin n'aura à sa disposition qu'une version debug de l'application.

C'est assez étrange. Généralement, en tant qu'éditeur d'un applicatif extensible via plug-ins, on ne fournit (si on fait du code propriétaire avec de propriété intellectuelle) que la version Release du programme.
Le fait de fournir une version Dll DEBUG n'a pas de sens dans ce cadre, car le produit final, chez le client final, c'est en Release qu'il est fourni.
Le concepteur de plug-ins fera ces tests d'intégration/d'homologation/de recette/de performance/etc... avec la version final du produit, et puis c'est tout.
En plus, le fait de fournir une version Debug augmente grandement les possibilités de reverse-engineering si vous n'êtes pas très scrupuleux avec les options de compilation et le shrinking/ofuscation des éléments à fournir aux développeurs externent.
En Open Source, c'est pas du tout le même délire. Vous fournissez les sources donc, le développeur, il fait sa tambouille comme il veut.

Le fait de ne pas mélanger Debug et Release, c'est l'une des limitations des Dll d'extention MFC.
Mais dans les faits, c'est pas très gênant.
Le développeur de Plug-in MFC a l'habitude de n'avoir que la version Release de l'applicatif et on peut toujours déboguer un code en Release (avec quelques inconvénients assez mineurs).
On n'a assez rarement besoin des fonctionnalités de la C-Runtime Debug quand on fait un plug-ins MFC (tracking des fuites mémoires, validation des pointeurs, etc...)
C'est le genre de code qu'on colle dans une librairie standard, utilisé dans un programme standard, en DEBUG, dédié à la vérification de ces aspects.
Le Dll d'extention MFC, en Release, utilisera cette lib, en version Release elle aussi, mais le code de la lib a déjà été vérifié/corrigé sur ces aspects via le programme dédié.
On peut toujours repasser par le programme dédié en cas de détection d'anomalie dans la lib.

Quand on développe des Dll d'Extention MFC, il n'est pas rare de faire une programme hôte "from scratch" pour accélérer le développement et les tests. (une application MOCK)
Ce programme hôte ne sera là que pour charger la Dll et faire des actions le plus automatique possible pour pouvoir rapidement faire tourner les campagnes de tests unitaire sans avoir à cliquer comme des malades sur des boutons d'une IHM.

Si vous en fournissez une, why not, mais sans les sources, les développeurs préféreront faire une application MOCK qu'ils pourront customiser pour s'intégrer dans leur architecture d'Intégration Continu, entre autres actions.

J'ai donc du mal à comprendre pourquoi la livraison d'une simple version Release ainsi que le code source d'un Plug-Ins de démonstration ne suffirait pas amplement aux développeurs de Plug-Ins.
(Après, un fichier .PDB shrinké de l'application pourrait être pratique pour des cas de monitoring d’incident ou de debugging de fonction de callback.)

le plus simple c'est de commencer par compiler un fichier .lib ou une dll "simple".

@Mat.M, je crois qu'il sait déjà faire.

en général en programmation windows on a recours à des plug-ins développés avec l'architecture Component Object Model plutôt que MFC...

Dans l'absolu, oui, mais là, on n'est déjà dans un contexte ou l'applicatif est en MFC.
Dans ce cas-là, il est plus simple de faire une architecture de plug-Ins via Dll d'extention MFC, qui sera très facilement implémentable, et facilement utilisable par des développeurs MFC.

Comme je l'ai déjà signalé, l'approche COM est tout à fait valide mais il implique un bien plus grand travail pour les développeurs de plug-Ins.
Cela demande aussi un peu de travail pour le développeur de l'application par rapport à l'utilisation des Dll d'extention MFC.

Il est tout à fait possible d'offrir les 2 types d'architectures de plug-ins dans le même programme sans trop de problème.

COM est plus ouvert mais plus complexe et je ne vois rien dans les contraintes initiales qui obligerait cette "ouverture" mais surtout qui interdirait le cas qui simplifierait le travail des développeurs de Plug-Ins MFC aware (qui doivent être une majorité).

Je pense donc qu'il est judicieux que le programme commence par offrir un mécanisme d'extension vie Dll MFC, puis, si nécessaire, par composant COM.

Rien n'empêche de profiter de l'expérience acquise dans la construction de cette architecture à base de Dll d'extention MFC pour la construction de l'architecture à base de composant COM, bien au contraire.

Je sais que ms-office par exemple c'était à 90% peut-être bâti sur une architecture COM maintenant je crois que c'est tout en NET

ms-office utilisait très majoritairement du VB (non .NET) qui imposait COM comme architecture la plus "simple" de composant (à mort DDE).
Ils ne disposaient pas de la "facilité" MFC.
VB cachait beaucoup de la tuyauterie COM pour rendre une implémentation COM en VB étonnamment simple.(mais assez piégeusement limitée)
Avec l'intégration d'une architecture COM, vous donnerez la possibilité de faire des plug-Ins en VB6 (mais qui l'utilise encore ?) mais aussi en .NET, mais faudra pas que les développeurs soient des perdreaux de l'année.

d'où l'intérêt d'une DLL COM ça permet de s'interface plus aisément qu'une dll MFC

Pas si l'application est en MFC.

pour faire communiquer l'application soit on utilise des "pipes" en win 32

Pour de l'intégration graphique, on va oublier.

soit encore une fois des "fires" avec un objet COM

Là, c'est bien mieux, mais c'est quand même assez triky à mettre en place.

utiliser les MFC c'est du 50/50 perso je ne le ferais pas et puis l'API win32 c'est pas si compliqué que cela

Euh, pas si compliqué ???
Il te faut combien de TJM pour avoir une interface qui ressemble celle d'un produit office à partir de Win32 ? (MDI, Ribbon, Menu Windows, etc etc etc et tout le tralala ....)
Parce qu'en MFC, c'est fait en quelques minutes.

MFC simplifie le travail mais ça fait des exécutables plus lourds ou alors il faut redistribuer le runtime

Quelle idée de ne pas distribuer l'application sous forme d'un MSI qui intègre directement les bons redistribuables ???

mais non pas du tout MFC n'est pas bas-niveau.

What ???
Tu trouves que la MESSAGE_MAP à base de pointeurs de fonction avec un champ texte pour encoder la signature du bidule c'est haut niveau ???
Et je parle même pas des autres MACRO magique pour "gérer" la sérialisation ou les DDX/DDV etc...

En .NET, t'as quand même des méthodes "overidable" ou le DataBinding pour éviter toutes ces cochonneries.

Les MFC, c'est la fin des années 80, la dernière version des bibliothèques graphiques .NET, c'est METRO, après 2010 (donc largement plus de 20 ans d'écart, et 20 ans en informatique, comment dire ).

Avec MFC on peut créer des fenêtres en 2 ou 3 lignes là où en win32 il faut 50lignes

Et la vache, faut voir la tête des 50 lignes, en code spaghetti imposé par cette antiquité. (oui Win32 de base c'est une antiquité même par rapport à cette autre antiquité que sont les MFC)

2- pour un plug-in oui il faut faire forcément générique sinon ça n'a pas d'intérêt donc proposer un certain niveau d'abstracvtion

NON !!!!
Il faut favoriser l'utilisabilité du machin.
Avoir un truc super générique, utilisable en IronPython avec extension en langage naturel Klingon, n'a aucun intérêt si je dois juste dire bonjour à ma boulangère qui parle avec un accent picard.

oui d'accord mais pour un projet conséquent vaut mieux utiliser COM/Active X...
parce que l'intérêt c'est que le client en NET, VB6..peut instancier des objets

Commencez par une Dll d'Extention MFC n'interdit en aucune façon de le faire.
Mais ne mettez pas la charrue avant les boeufs.

Ce qu'il concevra dans le cadre des Dll d'Extention MFC sera aisément utilisable dans le cadre plus complexe de COM.