As I said, the above was an example, not a point. V8 is supposedly even easier to embed than spidermonkey (it was built for embedding), so it's feasible to update JS4mIRC with V8. The source code is published for JS4mIRC, so you could just change the embedding calls, or recompile with the new TraceMonkey engine, which uses the same API (you can drop the library into JS4mIRC and recompile), *is* JITed, and competes nicely with V8.

FWIW, even SpiderMonkey is hundreds of times faster than mIRC's engine, so I think you're exaggerating the importance of what JIT gets you. You'd still gain a tremendous speed increase by using the above dll, JIT or not. Also keep in mind that any window command you perform, be it /echo, /draw*, /dialog, /window or other (even /timer), has up to a 10-15 ms delay, and that's because of Windows, not mIRC, so if your script is heavily dependent on UI commands, you're not going to get speed anyway. You only really need "speed" when performing numerically intensive computations, and that rarely happens on IRC. Basically, I just think you're hearing the word "fast" and you think mIRC needs this quality because it sounds better than slow. The truth is, in many cases you won't actually notice a difference, and the other cases can be done through existing *4mIRC dlls (there are ones for Python, Perl, PHP and Ruby, and they're all faster if you need the speed and don't program C). You don't need JIT speed for an IRC script, trust me.

As far as multibyte stuff goes, mIRC 6 handles unicode just fine, so you can just return unicode characters. As far as getting the data in, everything is passed in as raw data, so you decide how to encode it. There is also this:

Originally Posted By: versions.txt
52.Added support for DLLs that use Unicode functions. By default mIRC assumes that DLL functions are ANSI for backwards compatibility. However a DLL can enable Unicode support by setting mUnicode to TRUE in the LOADINFO structure


In short, Khaled already thought about this problem. DLL developers don't really have to worry about an incompatibility between 6.x/7.x. Even in the edge cases you could easily check mVersion to see whether you should perform conversion on input, and you could also use an isutf8() function.