You admit casually yourself it has a slow script engine, does this not set more of an example for necessity?
No. The point is that only cpu intensive programming truly benefits from multithreading. Because mIRC is slow, people don't use mIRC for cpu intensive programming, so no one will gain from a change like this.
Also, multithreading a slow engine will give you the same slow engine. The best solution is to make the engine itself faster-- using multithreading in hopes of getting better execution speed is just a workaround.
homegrown solutions on the scripting environment is only a temporary compromise to accepting a better solution
Wrong. It's not a temporary solution. It's a fully workable and usable solution in this context. Certain programming paradigms do things in a certain way; usually there is no ONE best solution, there are many. mIRC has one of many best solutions. Take, for example, the way that an imperative language like C implements an event-driven model like the windows api-- someone can say "you should use an event based language to solve this problem!", but frankly, the solution given in C is perfectly capable on its own. Should we rewrite windows into an event based language just because the windows api is event based? Frankly, asking for multithreading in mIRC shows a lack of understanding of mIRC's programming paradigms.
Then I ask you this-- Who doesn't need multi-threading?
Everyone in some fashion could use this, from simple things like
loading files and redundant searching in loops, video and sound addons.
Multithreading would not make any of those any more feasible in mIRC because mIRC's script engine is way too slow to support any heavy search loops or video/sound processing to begin with. Again, the solution would have to be to improve mIRC's script engine itself, not duplicate it twice and have it run in a thread. But if you really want you can already use dlls to do heavy processing, and then you have full threading capabilities to your hearts content. By the way, most people would go down to C for video processing anyway, so this is not such an outlandish idea.
You also didn't answer my "Are there any problems that I cannot solve given mIRC's single threaded environment?" question, you just said you think there are some-- I'd love to hear what they are. Yes, you can leave out dlls.
But frankly, all of what you're saying is hypothetical. mIRC *could* be faster. Obviously it would. How much faster, however, remains to be seen. From experience, multithreading really is not meant to give speed increases, so you shouldn't expect to see much in speed, only bandwidth. If mIRC is a 56k modem, then a multithreaded mIRC would just be 2 56k modems. You may be able to download 2 files at once now, but you're still only getting them at 5kb/s, so what's the point? You also have to realize that this is a cost benefit scenario, the cost of having K waste his time on multithreading is not worth the few benefits you get from a *potentially* faster mIRC.
As an aside, I don't know of any applications that converted from single to multithreaded with a considerable enough speed boost to conclude that mIRC should go down the same path. To really sell this idea to anyone, you'd really need to show success stories from other applications or at least show HARD evidence that mIRC could gain from an X% speed boost, or be able to solve a specific problem that is currently unsolveable (period, not unsolveable in an easy way. you can omit dlls from the picture though, to be fair). Currently though, you seem to just be saying "multithreaded would be cool cause it's a buzzword and why not?!" -- no real uses, no real proof of speed gain, nothing.. so where's the incentive?
