An mIRC script does not mean that no C code is involved. mIRC scripts commonly make use of DLLs to accomplish a task. A FiSH script can (and would) do this too.
The FiSH author is mistaken about the inability to script this. The reasons cited are inaccurate.
- Firstly, saying DLL handling is too slow is basically saying C is too slow. Given that mIRC can't get much faster than DLL processing, "native" support would not make a difference. Sending commands via SendMessage is slow, but if you need to do that more than once per message you're doing it wrong. IIRC the latency on SendMessage is ~10-15ms, which is roughly the Windows RunLoop cycle time. You can also use a project like the CLB (
http://kthx.net/clb) to bypass this and get equivalent speeds to mIRC if you
really needed to, though you probably don't. Realize that 10ms is a throughput of 100 messages per second, which seems quite sufficient to me. I don't know many instances of mIRC that send/receive 100 messages per second.
- Displaying messages in mIRC is the same as a DLL or plugin system. You would script the ON TEXT/ACTION events and halt default text. This is an extremely common scripting task, and there is ample support in mIRC for this. Native support in mIRC would not make this easier to implement; certainly whatever problems exist will still exist in the native implementation (though I don't really see any problems).
- The multi-space problem can already be solved by using a DLL like spaces.dll, so unlike the author suggests, a workaround
is known for this problem. This is a side-effect of using
any script that modifies output, not just FiSH, so this is irrelevant to the general question of whether or not it can be scripted.
- Because FiSH encryption lives
above the IRC protocol layer, you should not need (as the author suggests) to "replace" mIRC's buffers, you simply need to pass $1- from an ON TEXT/ACTION event into the dll and decrypt it. $1- should be at most 500 bytes, which is a very small amount of data. There are no performance bottlenecks here, so mIRC is certainly powerful enough to handle this end of things. Again, the cryptographic functionality would all be implemented in C.
- Incompatibilities with scripts is a fair point, but not a show-stopper. You *would* have to modify *theme-based* scripts to support FiSH (anything that modifies ON TEXT output), but it wouldn't take much lobbying to get the bigger scripts to play nicely with a FiSH install. It would also be relatively trivial to modify scripts on your own to add this support, since you would just need to modify 2 events (ON TEXT, ON ACTION). Is this really a big deal? Maybe the author should concentrate more on implementing the script than complaining that it cannot be done.
It is certainly
possible to script as a DLL (or with DLL helper functions). Yes, scripting this adds complexities to mIRC, but most scripts that interact with mIRC in this way do too.
But this all goes back to the question of how many people need this functionality built-in. Currently, not many IRC clients even support this kind of encryption, and I've personally seen no outcry of users asking for it. It would be extremely unfortunate if Khaled had to delay a release of mIRC to add functionality or fix bugs in a feature that was only used by a very small minority when this could be handled simultaneously by a third party script with delays avoided.
