Discussion :

[stof]

Bonjour,

Je précise que j'ai peu d'expérience en développement et que je dois attaquer un projet avec les indications suivantes :


Un logiciel existe déjà et on ne veut pas toucher à sa structure mais rajouter des besoins spécifiques, des fonctions supplémentaires.
Donc en gros, c'est la notion de plugin que je connais bien en tant qu'utilisateur de logiciels divers.

maintenant au niveau code, comment ça marche; que rajouter dans le code du logiciel et comment l'interfacer avec ces fonctionnalités nouvelles (elles-mêmes, quelles formes doivent-elles avoir).

Merci pour vos pistes.

[Médinoc]

Typiquement des bibliothèques à liaison dynamique (.so sous Linux, .dll sous Windows).

[stof]

D'accord pour les DLL; peux-tu me dire comment ces DLL interviennent dans le logiciel (je vais chercher comment faire une DLL mais ce que je ne visualise pas, c'est comment dans certains cas on va utiliser la DLL avec les options correspondantes aux nouvelles fonctions du logiciel, et dans d'autres cas on n'utilise pas de nouvelles fonctionnalités)

[Médinoc]

Généralement, les plug-ins ont une interface commune (ou bien, plusieurs types de plug-ins avec une interface commune).

Regarde dans WMP ou dans WinAmp par exemple, chaque plug-in a un type (input, output, etc).
À partir de là, le plug-in est une DLL chargée dynamiquement, avec une interface précise (Des fonctions exportées qui ont toujours le même nom).
Sous WinAmp je ne sais pas, mais ça peut être un simple chargement avec LoadLibrary() + GetProcAddress(), sous WMP il me semble que ce sont des composants COM, encore qu'un LoadLibrary() normal soit sûrement nécessaire tant qu'on ne connait pas l'ID des composants...

[PRomu@ld]

Une bibliothèque partagée, est définie pour étendre ton logiciel.

On va prendre comme exemple l'exportation d'une image via des pluggins (certains appellent cela des greffons).

Le principe pour que ça fonctionne est que les pluggins aient une interface standard, c'est à dire qu'ils possèdent tous les mêmes fonctions.

Ainsi pour l'exportation d'une image, tu auras toujours dans chaque pluggin une fonction exporter. Tu pourras avoir une fonction qui te permette d'effectuer un paramètrage, etc ...

Ensuite, pour ce qui est de la réalisation, tout est dépendant de ton système d'exploitation. Sous linux, tu as les fonctions dlsym/dlopen ... sous windows, je ne sais pas

[stof]

sous windows, je ne sais pas

Pas de chance, c'est sous Windows
Sinon le logiciel a été créé sous LabWindows pour être plus précis.

Alors dans mes lectures sur des plugins, j'ai l'impression que les développeurs utilisent toujours le SDK fourni avec le logiciel qui accepte les plugins.
Par exemple j'ai vu un tutoriel pour un plugin WinAmp et pour mettre en liaison WinAmp et le plugin, il faut appeler

Code :

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

1
2
3
4
5
__declspec( dllexport ) winampVisHeader *winampVisGetHeader()
{
 
     return &hdr;
}

A partir de là, OK, mais c'est pas le cas ici puisque le logiciel artisanal auquel je dois rajouter des plugins n'a pas encore été prévu pour ça (d'où le boulot que j'ai à faire).

[Médinoc]

Ben tu dois faire un truc du même genre : Il y a toujours une interface fixe.
Pour les composants COM, les fonctions DllGetClassObject() et DllCanUnloadNow() doivent être définies et exportées
(Ainsi que DllRegisterServer() et DllUnregisterServer() pour l'installation).

Pour les types renvoyés et pour éviter de faire des GetProcAddress() à gogo, tu peux utiliser une classe abstraite ne possédant que des fonctions membres virtuelles pures, et retourner un objet descendant de cette classe (c'est ce que font les composants COM avec leurs "interfaces").