Author Topic: Plugin Interface needs versions that can return a list of plugin interfaces  (Read 73 times)


  • Posts: 261
So, I want to make a wrapper for XMPlay plugins for .NET Standard / Core / Framework that basically wraps the XMPlay plugin interfaces with Reflection based api's that is supported in managed code (for interface types), I want to expose managed interfaces that deriving plugin classes in managed code would derive from and those managed dll's would be loaded by reflection and called out on their GetInterface members to return a list of managed interfaces that are then easily marshaled back to what XMPlay expects however there is an issue with how plugins are loaded.

Specifically these do not contain a version yet where you are allowed to return an array of plugin interface instances to XMPlay and for it to read them as multiple plugins like so:

- XMPARC_GetInterface
- XMPDSP_GetInterface2
- XMPIN_GetInterface
- XMPOUT_GetInterface

The xmplay structures that is in the XMPlay SDK itself are easy ones to implement into managed code (C# and managed code allows function pointers in structures now), however the issue is that I would still need a native C++ wrapper that pull in the common language runtime to expose only what is wrapped to managed code. However since multiple plugins would need to ship their own copy it is best to make a single wrapper that wraps all the different types of plugins all at once, and then use reflection to load plugin types since it's more pain to try to force those specific signitures above from C#, Visual Basic, etc as if they were native exports (which is still why C++/clr would be needed for this).

However I would suggest the following be added for this case (note the s added to the name to denote to XMPlay that it returns a list of interfaces in the form of a C style array):
- XMPARC_GetInterfaces
- XMPDSP_GetInterfaces
- XMPIN_GetInterfaces
- XMPOUT_GetInterfaces

(I do not think the 2 at the end of XMPDSP_GetInterfaces is needed not to mention might make it confusing, but it could be added onto the name I suggested in case it's wanted with it on it at the end)

Sorry it took so long to report this idea of mine, I been busy doing stuff and just now decided I wanted for people who use managed programming languages like C# or Visual Basic to be able to make simple, yet functional plugins for XMPlay as well so that way people who do not know native code like C or C++ could still be able to make plugins for the program.

Also if any of the C style array versions returns a null pointer that would mean there is no managed plugins of that specific plugin type installed yet. Also no matter what the wrapper must not be listed and will not attempt to be listed as a plugin itself since it's a wrapper for implementing XMPlay plugins inside of managed code so people do not have to think about
How will I make XMPlay know about my managed plugin, will I need C++ /clr or could I just use C# of Visual Basic.
since the wrapper would do the heavy lifting for them and they would only have to think about making plugins instead.
« Last Edit: 3 Apr '21 - 05:56 by PSXGamerPro1 »