Maybe.. if Khaled took advantage of this new development in computer technology called 32-bit programming with multi-threaded processor support, it would be an improvement. :P

mIRC is a great program, and i'm glad that it's 32-bit now, but why does it still behave like a 16-bit program for windows 3.1?

maybe fix it so remote scripts can function in a multi-threaded way to make them faster. if i sound like a complete idiot its because i dont know anything about actually programming. still tho.. it would be nice.

In what way does it act like a 16 bit win 3.1 app?

* i beleive it does have some 16bit code still, but What are you refering to that you dont like?

/me bets its the single threaded processing of events/scripts

yes mainly the single threaded processing.

to someone who knows more about programming 32bit apps: is it even possible to improve a single-threaded app like mIRC to support multi-threading, or would it require a complete rewrite from the ground up?

will khaled even consider such a thing?

the problem i beleieve would more be in the way its been designed and 1000's of scripts created to function using it.
If instead of u knowing that nothings gonna change tell u finish what ya doing, now you have to watch out for things altering in mid process. I can see a huge level of scripts falling over from this.

It "may" also be incredibly difficult to write into mirc, as i dont know if u have noticed but if a script locks up mirc indefinitly or for a long time, any file sends/recieves well fail, so they also are not getting any processing time, however my mirc does seem to have 4 threads running, so what is being multitaksed in it i dont know.

at the point where mirc has evolved to, as a program, it is quite a difficult task for one man to rewrite an entire application with multithreadedness in mind. trying to make the application multithreaded is likely to make the software very unstable and buggy unless khaled was to double if not triple the beta testing efforts. You're really dealing with a whole new beast when you convert to multithreaded apps. It's also not very worth it-- because the single threadeness of the scripts is in some ways a godsend.

Porting mirc to be multithreaded is a very daunting, painstaking and difficult task for the one man machine that is Khaled Mardam-Bey

And yes, what was said before also applies, about breaking many many many scripts out there that rely on the single threadedness of mirc. It's too late now. Might as well get used to it, or use another client.

Actually, mIRC is a fully multithreaded program when it comes to the GUI, but that's due to the Windows architecture and API.

What is _not_ multithreaded is that one single script process that goes around in circles waiting for an event or command and then executing it. That all happens in that one thread.

I was more refering to a higher level of whats multitasking and whats not, in the sence, that i would have thought that a task(thread?) for dealing with dcc sends/gets in progress would have seemed the right thing to do, but as i said, a simple script like
//var %ctime = $ctime + 60 | while ($ctime < %ctime) { } | echo control returns
well kill all the dcc's, actually i cant for a fact say that they arent attened to untill this finishs, but it would appear that way, it might be that this just eats all of mircs timeslice up (i dont actulaty think its timeslicing anymore but u know what i mean), and thus the dcc task gets nothing. Well i dont beleive thats the cause as i never have had that type of problem with multiple threads myself, so i recon there on hold tell the script finishes. Must be a reason for it, i just cant think of it.

argv0 is right multithread support is a beast at any point in an applications life however an established app like mIRC it is an all but impossible feat...

I agree that it is not worth it mostly because of the instability it would cause there are so many checks you haveta make when using multiple threads to make sure data isnt being changed by multiple things etc... the closest to multi threading we have is $comcall and $dllcall which are awsome in their own right so if i was you i would put the code i wan t in a dll and then do $dllcall (: