mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Sep 2007
Posts: 14
D
Diam0nd Offline OP
Pikka bird
OP Offline
Pikka bird
D
Joined: Sep 2007
Posts: 14
Will mIRC ever support plugins properly? Example: as many might know there is an addon for mirc called FiSH, which provides a form of security. As far as I know many people use it. Now, this addon works through a .dll, of course, and with EACH AND EVERY new mIRC version mirc.exe needs to be patched for FiSH to work properly. And since the original founder of the FiSH project is gone now, people have to patch their mirc with home-made patches, many of which crash; a lot.

Wouldn't it be simplier if there was a unified plugins support in mIRC, because in that case we could drop a few files into like /plugins/ folder, and that's it. Nobody would never have to worry again.

I really like mIRC and I do appreciate tons of stuff being added, but I really do think that with plugins support we would have an unlimited horizons before us all. That would make the client WAY more popular, imho.


mIRC v7.32 REGISTERED
Plain, no scripts
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Any script or DLL will have a chance of failing with a new version of mIRC due to changes made. Unfortunately, that's unlikely to change. However, most DLLs don't fail with new versions except when something major is done dealing with whatever the DLL is meant to do. If that DLL fails that often, then perhaps it isn't written very well. Also, if you are patching mIRC (instead of fixing the DLL), then that also leads me to believe the DLL isn't very well written. And I personally wouldn't want to trust a poorly written DLL for security. That said, I haven't used it, nor have I looked into it. It may be a good DLL. Even so, if it's that popular, someone should take over keeping it updated and then there won't be any issues.

As far as plugins like you are asking for, I don't think we'll see that happen... at least not anytime soon. Of course, only Khaled knows what will be added.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2007
Posts: 14
D
Diam0nd Offline OP
Pikka bird
OP Offline
Pikka bird
D
Joined: Sep 2007
Posts: 14
I would not focus so much on the .dll I mentioned. It was merely an example, nothing more. I see tons of things added to mIRC with every release, including many cosmetic-type of fixes (which absolutely does NOT mean those are bad), but nothing major (well, at least in my opinion). And one of those "major" things could be support for plugins. Again, that was just a suggestion really. I don't think there's much more to discuss here, since it's all up to Khaled.

Last edited by Diam0nd; 05/09/07 12:09 PM.

mIRC v7.32 REGISTERED
Plain, no scripts
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I wasn't trying to say it's a bad idea. It could possibly be very useful. I'm just not sure it will be done considering we already have support for DLLs, COM objects, and normal scripting. People have asked for support for other things, such as using SQL, and we haven't seen that added either... partly because there are so many versions that picking one wouldn't satisfy everyone.

Anyhow, it isn't a bad suggestion and I wasn't trying to say it was.


Invision Support
#Invision on irc.irchighway.net
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
First, a reply about the whole 'plugins' thing. Personally i dont see it at all neccersary, there is very little you can do with a 'plugin' (modification to mirc.exe itself), that you can not do with a dll (or a few working together).

In your specific example of the blowfish patch (note that its always been buggy from the day it was started, and as such i refuse to use it, thats the nature of third party modifications to the mirc executable), the same result can be achieve with the use of some dlls and scripting.. there is a nifty little dll called io.dll that can catch incoming/outgoing communication between mirc and an ircd and halt/manipulate it.

This makes it relatively easy to write a script that uses this dll to detect incoming encrypted messages (or catch and encrypt outgoing messages) by replacing the data in the caught message with data that has been altered using ANY encryption dll such as fish.dll

Dispite this (which is how i have done it for the time being) there have been a few suggestions in the past for generic text encryption support built into mirc, one by myself, which i personally think would be great but also realise thats its the kind of feature that the general mirc userbase isnt particularly interested.

Native text encryption (eg blowfish)

I believe there have been others, but i only did a quick search of my own suggestions.

Anyway, i am all for generic text encryption support even if it was just designed to call specific functions in whichever dll its set to use (dll would have to be created with mirc in mind and use appropriate function names), and a good key exchange method (weather it use DH like the blowfish patch does or any other/better form). But as far as 'plugin' support in the way that it seems your suggestions i dont see the point.

As a side note, and i believe i have mentioned this before also, a dll management dialog could be very useful. It could allow you to add feature enchancing dll's to an autoload list (when mirc starts) that could add functions/identifiers/features/etc to mirc without needing to script calls to the dlls. (eg a dll could autoload, and upon autoload send a command to add a button to the toolbar, and interpret the click of the button to launch a dll coded dialog, without any need to use mirc scripting)


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby

Link Copied to Clipboard