Comment créer une API C++ ?

Citation:

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.

Citation:

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. :weird:
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.)

Citation:

Envoyé par Mat.M

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. ;)

Citation:

Envoyé par Mat.M

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.

Citation:

Envoyé par Mat.M

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. :weird:

Citation:

Envoyé par Mat.M

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. :mouarf:

Citation:

Envoyé par Mat.M

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

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

Citation:

Envoyé par Mat.M

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.

Citation:

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. :weird::aie::mouarf:

Citation:

Envoyé par Mat.M

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 ???

Citation:

Envoyé par Mat.M

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 :aie: ).

Citation:

Envoyé par Mat.M

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)

Citation:

Envoyé par Mat.M

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.

Citation:

Envoyé par Mat.M

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.