Hi, I've tried mIRC 7.0 with mine script, that use much dlls (and mIRC 6.35). Seem that is a bit uncompatible with the MDX (maybe because it's a very old dll?), some functions are broken, and seem that the NickLust make the joining slow (this dll, though a script, make a who on the joined chan).
Yes, sometimes (maybe for the MDX) mIRC crash, but with others dll seems to work very good.

Win7 x64

I'll made more tests in this days

Just like in any other previous version of mIRC, the author of the DLL might have to make a few minor changes to get it to work right again.

The responsibility is up to the DLL’s author, not mIRC.

Unless someone takes over MDX development, it appears that MDX will no longer work in mIRC 7+. I'd recommend switching to DCX as it can do most (probably all) that MDX can do and is still updated.

As for nicklust, if it's still updated, then the next version will probably work with mIRC 7+... just ask them.

As mentioned, DLLs and scripts that stop working when mIRC gets updated need to be fixed themselves. It's not up to mIRC to guarantee compatibility with DLLs or scripts.

Well... But unfortunately many dll's authors have stopped developing, and some like NickLust's author have not released the sources... Well, everytime a mIRC update is out, we have to fight against this problem...

Unfortunately, that is the choice you have to make if you use 3rd party DLLs (i.e. ones you don't make yourself). It's true for scripts as well, though it's easier for people to help you fix a script than a DLL.

There's nothing mIRC can do to solve that problem. If mIRC tried to maintain compatibility with every DLL/script out there every time it put out a new version, mIRC wouldn't be able to change much of anything.

My private opinion.

I'm really happy that mIRC is developing. However, I'm quite
irritated with the added DLL files' service. I think that since it has been added, it shouldn't damage the way the DLL files work. Changing from MDX.dll to DCX.dll is paranoia. One cannot even be sure whether the DCX.dll will be working correctly in a month or so. I'm writing a script myself and I'm beginning to regret spending so much time on writing it, buying a domain and creating a website. Learning DCX.dll and rewriting thousands lines of code from the very beginning discourages me from using the mIRC any longer. Personally, I think that there are some matters that has changed to worse, for instance the very fact that mIRC is supposed to work only on Windows based on the NT system.

scriptwriter

MDX and DCX are not supported in any official capacity and never were. They are third-party modifications of mIRC. If you choose to use them, you should ASSUME that your scripts will break in every release of mIRC. It has nothing to do with mIRC itself. If you used only standard mIRC scripting controls, you wouldn't have that problem.

mIRC is breaking compatibility with versions of Windows prior to XP because doing so was necessary to support new features like full Unicode support. If you must continue to use an older version of Windows, then you can just continue to use 6.35. You wouldn't benefit from most of the new features in 7.0 anyway since they simply wouldn't work in Windows ME or earlier.

mIRC's DLL API ("service") is basically just a mechanism that allows communication/function calling between scripts and DLLs. mIRC 7.x is fully backwards-compatible with mIRC 6.x in this regard, which is where mIRC's responsibilities end.

The DLLs that have broken have done so because they rely on mIRC to behave in specific ways in areas other than the documented APIs, sometimes down to very fine details (such as the format and memory locations of internal data structures) and often because they're trying to alter the behaviour of mIRC itself (as in the case of MDX). For this reason it would be impossible for mIRC to retain backwards compatability with every DLL without bringing development to a standstill.

MDX has not been updated since 2002, it is abandonware and the source (as far as I know) was never released. In all likelihood it will never be updated again. Expecting mIRC to maintain backwards compatability with unmaintained and obsolete addons is unreasonable and unrealistic. What's more, new versions breaking old addons is not a phenomenon unique to mIRC; if you search the Firefox extensions site you will find hundreds of addons that were never updated for Firefox 3.


Correct, but unavoidable. The source for DCX is available though, so there's a far better chance it will be updated as new mIRC versions are released.

What's the point in creating the DLL files and introducing DLL files' service in mIRC? One day you will wake up in the morning and you will find out that your script doesn't work any more. That is why the DLL files' service should not be available (maybe this can be a feature suggestion?).

Adding functionality that mIRC itself does not offer.


You know the great thing? You don't have to use DLLs. As a script writer, it's your choice! You can choose not to use DLLs, and then your script will never stop working for that reason either! Isn't that amazing? mIRC can already do what you want!

Well, that is the same as asking "what is the point in Firefox allowing support for addons? Every time I update to a new version of Firefox, half of my addons stop working!". Are you suggesting that Firefox also stop supporting addons? :-)

This issue is true of all applications that support addons. The more sophisticated and complex the addon is, and the more it ties itself into the way an application works, the less likely it will work in the next release of that application.

I think the way new versions of Firefox disable addons that have not been updated is a good idea. It forces old addons to be updated and if they are not, they stop being used and other addons take their place. This ensures continued addon development and prevents users from becoming dependent on old addons that never get updated.

It is no longer possible to run the new version of mIRC under older versions of Windows, such as Windows 95/98, since they cannot run Unicode applications natively, and any Unicode support that they do have is very limited. It was only with Windows 2000 and onwards that Unicode became a viable and practical option for applications.

At some point, I have to decide when to drop support for an older version of Windows. I usually maintain support for as long as I can - for example, Windows 3.1 was supported for many years, long after most developers dropped support for it, and even though very few people used it.

In the same way, I held back improvements in mIRC to support Windows 95/98, even though very few people are using those versions of Windows. At this point, Windows 95/98 register barely, if at all, in any global usage statistics. So it does seem a reasonable point to drop support for them and to allow mIRC development to move forward.

The other thing to realize is that just because a script stops being supported, it doesn't mean you're no longer allowed to use it. If DCX is abandoned like MDX was, it's not going to magically disappear from your script. Whatever version you are currently using will continue to work, and you will continue to be able to script with it for years to come. AFAIK, DCX is a pretty stable DLL, so any bugs should not be getting in your way often. And again, source is available, so you could fix whatever issues you had.

The same goes for mIRC. Just because mIRC 7.x will no longer be compatible with Win95/98, it does not mean that you can't happily continue to use 6.35 on those older machines. 6.35 is a very stable product with few bugs and plenty of functionality. You may miss out on some interesting new features, but 6.35 will always remain usable as a robust IRC client. Users who have not yet upgraded past 95/98 are probably not too interested in "new functionality" anyway, so it's not such a serious matter.

Listen, a lot of mIRC DLL authors lacked the necessary discipline to publish binaries to begin w/. The same goes for script authors. You should expect that one day, something out of your responsibility will go wrong. You need to to make sure you do everything you can to limit the amount of possible harm done.

If you find a script that uses DLLs, what I recommend trying is to lock scripts from using DLLs from the options window. Then see if the script properly detects something is wrong and does what it needs to while DLLs aren't functioning. If it doesn't, and things go haywire, avoid the script.