You can see DLLs and COM and even mIRC scripts as already being "plugin support", because, well, they are. You put them in a directory, load them, and they extend the functionality of mIRC beyond its default. That is the definition of a plugin, by any reasonable standard
The problem here is when such a plugin (again, mIRC scripts included) tries to push the boundaries of this plugin support and do something that mIRC has not really made an API available for. This problem will never be solved by introducing "unified plugins", whatever that would be.
A little history:
mIRC script was introduced in the v4's because people wanted the ability to "extend mIRC", much like a plugin would extend mIRC. This language grew over time to a point where it was nearly fully functional...
Did that solve the problem of extending mIRC? No. There was still plenty that mIRC could not do. So DDE was soon added to allow mIRC to communicate with other applications in the most advanced fashion at the time it was implemented.
Again, did that solve anything? Nope. The boundaries were continually pushed, and soon, DLL and COM support was added because people wanted more access to Windows' API, performance, etc.
And now we're in a similar situation, where the boundaries are still being pushed and people want mIRC to implement heavier dialogs, more API's etc.
Will adding another method to plug code into mIRC solve anything? Maybe temporarily. Are there even any other methods? Not really, we've pretty much covered them all.. DLL's and COM is pretty much the only way for mIRC to communicate with plugins anyway, so if there was any other form of plugin support it would just be another DLL like API. Notice that although mIRC still supports it, DDE is essentially obsoleted by DLL and COM, which proves the above.
The solution here isn't to create more bridges. The solution, especially for a DLL like FiSH, is to open mIRC's API so that such a plugin can interface with mIRC *properly*, rather than having to hack its way into mIRC's internals. Unfortunately, this is easier said than done, and there is probably a lot of work needed to open an API for something that FiSH could actually use.
Virtually anything can be done with DLLs, and having written DLLs that push those limits, I know this. The problem is that sometimes Khaled didn't think of the ways we might make use of such plugins, and we have to do things the hard way. Again, the solution is not making more ways to create plugins-- heck, there really is no "solution".
The best way to deal with a problem like this would be for the FiSH author to make a feature suggestion on the mIRC boards asking for a way to do what he needs to do and have it be officially supported, and then hope Khaled sees purpose in the suggestion. Otherwise, even *if* this hypothetical "unified plugin" support was created, it would potentially also not support what FiSH is trying to do unless Khaled knew that such an API was needed; and that would just bring us back to the very same point we started at.
