PureBasic Forums - English

Hi Group,

searching this forum, I noticed that 'Blade' and others posed questions about writing plug-ins. The discussions that ensued mostly concentrated on a single problem the respective programmer was struggling with.

For an application that I'm currenly designing, I'm looking for a generic (if possible platform independent) plug-in architecture/framework. The application will be rather math intensive. The plug-in architecture should support swapping algorithms at will, or adding to a list of algorithms that the main program can select from. Also, the plug-in should be able to provide other resources: perhaps bitmaps, lay-outs for reports, etc.

I've searched this forum, I've surfed SourceForge, but so far couldn't find anything generic.

Any pointers from you? I wouldn't mind being pointed to something written in C, as I could translate this into PB.

Thanks for any hint!

(P.S. Fred: this app would really benefit from double floats; with this app I'm banking on 4.0 not being too far away...)

one of the common ways for making plugins is to build a DLL ( in case of Windows Platforms ) and to specify what functions you'll need.
one plugin is equal to one DLL, each DLL have the same number of functions, the same common abilities.

plugin_number1.dll
plugin_number2.dll
plugin_number3.dll
...

and each have inside the same set of functions :
my_GetName()
my_GetVersion()
my_GetAuthor()
my_GetDescription()
my_ImageNumber()
my_GetImage(i)
my_GetImage(i)
my_Algorithm()
and so on...

so, this way you could build one, and only one, algorithm in order to process all the available plugins.

hope it could help you :roll:

Bonsoir Flype,

thanks a lot for your reply. I sketched something along the lines of your proposal, but got stuck right where I needed the main program to enumerate the list of algorithms that it draws from each of the registered plugins. I guess I also need ideas on what structure to use in the main application.

Take for instance this imaginary scenario: My app needs to draw lines that are interpolated between data points. There are numerous algorithms around to do that: Bezier, cubic or quintic splines, the list goes on and on. Now, if I'm the only one implementing these algorithms for my app, I could simply compile them into the main progam. The beauty of a plug-in system is that programmers other than myself will be able to extend the base product, without them needing sources at all. All that's needed is a documented way how to bundle your own algorithms into a dll and how to let the main program know what your dll has to offer. Also, a plug-in system makes it easy for me to extend/maintain software at customer sites.

Such an interface is an API in itself. I need to define how these functions need to be called (much like in your proposal), how parameters/arguments are passed to this external dll, how results are returned to the main program, etc. That's only the API definition, the part that the outside world needs to know. To implement this API, I need a structure to hold multiple functions with identical function names, each drawn from another dll. There's probably much more that I need to think of, implement and document, but I'm just starting out with this part of the design.

I was hoping that there was some generic way of doing all this documented somewhere.
I'm not necceseraly looking for source code (would be convenient, of course ), no, much more than that I was looking for some high level information that details the structure of a plug-in system.

salut,

I had the same problem...

This is how my plugin-system works:
-I have a plugin-folder under my main app, where different plugins will take place
-the foldername under this plugin-folder is the Plugin-Name
-the plugin itself is always a plugin.dll
-At the beginning my app scans for new plugins, and checks if the old ones are still alive (the old ones are saved in an ini)
-New Plugin Found -> first scan the available Functions (so i can do it case-intensitive) and save the names and Function-Adresses in a structure
-A MUST-BE-FUNCTION called Plugin_Info should be there. Otherwise it isn't a conform plugin
-Through this function you can get :
minimum required App-Version
Own plugin Version
Special infos on the included functions
(just call it more then once and overgive special values)
alternatively you can send a Pointer back to a special app-function so the plugin can get further information if in need...
-Let the User decide which functions he/she wants to be active.
-Now there are a few optional functions which can't be disactivated like :
-Plugin_Install() - called when Plugin is installed the first time
-Plugin_Init() - called whenever my App starts
-Plugin_Uninstall() - called when the plugin is deinstalled
-Plugin_Update() - called when the Plugin is updated
-Plugin_Exit() - called when my app will be closed

------
This is just my own plugin-system, but maybe it will help you

Danke schön HeXOR,

your description gave me some new ideas on how to tackle the subject, thanks!

One question: you wrote that the plugin name is derived from a directory name and that the plugin proper is always called plugin.dll. How do you protect your application against faulty third-party plugin installers, that are not conforming to this grand scheme of things? What happens to your application, when one of those third-party plugin.dll files end up in an already existing plugin directory? This will have trashed the original plugin.dll in that directory. Will your application be able to detect this?

Well my plugins don't have any installer, they are nothing but zipped folders, which the user has to unzip into the plugins-folder.
So it would be on the user to check if the folder is existing and handle as wished.
If it was a plugin with an installer this would be on the installers site to check folders before installing. It's difficult to let this the application do... it will surely recognize that the version changed but never can know if it is now a totaly different plugin.

Maybe not the best solution, but i think a little user-brain can be presupposed

you can just make something like that :

first create 1 or 2 plugin functions
Name.s = Plugin_Name()
Version.l = Plugin_Version()

and then, when parsing available plugins, you may store plugins list in a PB List. Here is some pseudo code : maybe

Just make sure you don't forget to use IsFunction
after opening the library/plugin.

Also, you don't have to use folders.
You could just use a \plugins\ folder.
where all the .dll are installed to.

obviously subfolder is nice if it's a complex app.

\plugins\gfx\
\plugins\sound\

just remember to use IsFunction to make sure the version and plugin name functions exist first

Thanks a lot, all of you, for all of your input!