Hi All
I have a program I want to write, but I want to be able to add functionality via dll's, in order to try and future proof it somewhat. My main question is what is the best way to do this. I will give you what I think is the way to do it and please feel free to tell me thats stupid, or there is an easier way. I'm thinking that the core system will scan the plugin directory, and when it finds a dll file it will try to load it, the dll file will have a header that will tell the core if it is written for it and if so then it will pass strings and whatever else to the core system so it can then be integrated into the main menu.
Am I on the right track?
Many thanks for your help.
Sounds fine to me. I've done similar things before, though nothing that ever got released. There are definitely guys here who have done it successfully though, so their advice will probably be invaluable to you.
Cheers,
Zooba :U
Yep, that's the way to do it :wink
The thing you need to consider is how you're going to get that 'header' in the first place. I would suggest requiring these dlls to export a function "GetHeader" (or whatever).. Then for each dll you find, load it (LoadLibrary) and call GetProcAddress for that function - if it fails then it's not a valid plugin, so unload it (FreeLibrary) and ignore it. If it succeeds then you can call this function to get a pointer to the header, and go from there. I'd still have an extra check on the header too - some version identifier? Then, in the header you can have stored any necessary strings, data, and function pointers.
Hi
Thanks for your advice all, I had hoped I was thinking the right way, its nice to have it confimed. :U
Many Thanks
You may not want to be too automatic.
I would suggest an internal add-in list, that gets updated from the directory. When you 'find' it the first time, ask the user for permission to load/enable the plug-in. Then have a small maintenance routine for the user to choose whether to load an add-in or not at startup. Having an optional commandline feature to not load plug-ins, would be helpfull at times.
This would make it better to trouble-shoot your app, when an add-in pulls your hairs out by the roots.
Regards, P1 :8)
You see thats why its always better to ask the experts first, thanks!!! :toothy
Also, note that in DLLs you can export a variable. Usually of some structure-type, instead of "dd".
PLUG_INFO struct
name db 32 (?)
version dd ?
plug_type dd ?
pFuncCreateObject dd ? ; pointer to some function
PLUG_INFO ends
public PlugInfo
PlugInfo PLUG_INFO <"myFirstPlugin",1,0,FuncCreateObject>
(you should add the "PlugInfo" in the .DEF file, associated with this .dll )
This is the way I make plugins.
Hi thanks for that, very interesting. It will definitely give me some nice reading for the weekend. :U
In HLLs a plugin architecture is achieved with interfaces. An interface dictates a set of function signatures that a module must implement. A loader (the module that consumes the plugin) will load the plugin, inspect it to see if it implements a pre-decided interface, if it does then the loader can immediately call into the plugin through the known functions.
In simple language, you can check a dll to see if it implements certain functions, GetProcAddress will tell you if the function exists and what its address is in memory. You could then inspect the code at the start of the function, and do things like determine how big its stack frame is to see if the parameter count/size matches what you are expecting - although this method can be quite prone to error.
Or you could just do the hardcore thing and use interfaces, donkey (amongst others) has published some very good examples on how to use various interfaces. If you learn how interfaces work (which is not really that hard) then you will be most of the way to unlocking the mysteries of COM.
Hi thanks for the input, very much appreciated, I need all the help I can get right now :toothy