Hehe,
I totaly agree with BW_DUO, c# is the future.. but c++ and managed c++ is the current..
It is easy to just write a little wrapper in managed c++ which will load a .net dll which is its own name .net
So the same assembly renamed to wee.dll will load wee.net.dll, and renamed to rrr.dll it will load rrr.net.dll..
That is the easiest way for n00bs to do it.. or just make the whole plugin in managed c++ (AND before n00bs get complaining!! NEVER USE MANAGED CODE IN THE DLL OFFSET FUNCTION (dllmain) (m$ bug
))
Ow and i think plugins should be revised
There can be a lot of enhancements:
- Dont use the stupid ->nBlah = 5 and then ->aBlah[1] = 3.. as used for example exporting the info about the commands of plugins.. But make a simple add function which takes care of that (and use a vector) so that you only have to use ->add(3, "blag", "gfgg");
- Make it possible to put multiple plugins in one dll: In other words.. Let a module be a class which implements IMPPlugin class (which has all the virtual functions which have to be overwritten). And let there be only one function in the dll that has to be exported (except dllmain), that is getplugins(/*[out]*/ cPluginCollect PluginCollection); , where you just add plugins by using PluginCollection->Add(new SomePlugin);.. It makes things so much more easier (And the patchou doesnt need to keep all the dll`s loaded in the memory )
- And a lot more, but i`m lazy, and people tend to just avoid the main issue by attacking 'a' little flaw in my concepts
