First off, I didn't want this to turn into a debate on the validity of DLLs. We're talking about a very specific DLL here, exec.dll. You're the one turning this into a philosophical debate about mIRC script "purity", but I *will* bite.
I didn't say I had anything against dlls,
According to the rest of your post it certainly sounds like you do have some serious ideological issues with using dlls.
if I need a dll to do it than I probably don't need to do what i'm doing with mIRC.
This is ironic, since you are using Perl to do something because it can't be done in mIRC. exec.dll is an example of a situation where you definitely need the power of a dll to do things that mIRC just isn't designed to do within the scripting language. There are *MANY* such examples, but the "dll-isn't-scripting" debate is old and boring-- and irrelevant. It comes down to this: your script isn't capable of doing what exec.dll is. mIRC [scripting] isn't capable of doing what exec.dll is. I guess according to the above quote, you are saying that you don't need to run 2 or more programs efficiently and simultaneously with mIRC.
DLL's are frowned upon on a lot of mIRC fan based sites for general addons you'd like to release to the public.
This sounds anecdotal to me. In fact, of the popular scripts I know, nearly all of them include (or *are*) dlls. Looking at mircscripts.org shows a healthy number of downloads for every dll, often surpassing downloads for a similar sampling of addons/snippets. In short, the data seems to disprove your statement.
Users are also cautious about DLLs and tend to not want to use them without the source, and chose not to even with the source because they themselves don't have the compiler to generate the dll and don't want to chance the "pre-compiled" one included in the package.
Again, anecdotal. The download counts posted on sites like mircscripts.org prove otherwise-- there is no significant difference in user behaviour. If your statement was accurate, DLLs would see much lower download counts than all other scripts. This is simply not true. Secondly, most script sites require source to be posted and reviewed. If you don't trust the site in question, that's a personal issue that you need to deal with-- it's not a question about DLL safety.
We're talking about exec.dll, though, not "dlls in general". exec.dll publishes the source code; it's in the package that you downloaded. Are you saying that you don't trust *my* source? Are you saying that the dll I've provided is malicious? These are some pretty serious claims, if that's what you're alluding to. If you're talking about dlls in general, well, that's just tangential to this topic.
FYI it's just as easy to write a malicious mIRC script as it is to write a malicious dll. Having the source code is not security. Trusting the people who write the code you're running is the important part. There have been undetected vulnerabilities and even malicious exploits in production level open source code (linux kernel, openbsd, exim, etc.) that have stuck around for years without people seeing them.
I'd call you stupid if you blindingly trusted a pre-compiled dll included with the supposed "source" as you're just asking for trouble.
I guess you're calling every mIRC user, including Khaled, stupid. Somehow I don't think this is true. You're running mIRC without any source code provided. You must be asking for trouble, too. This is such a slippery slope argument. There's a difference between running untrusted code and running code that's been peer reviewed by community members that you know. If we can't agree to that, we have a problem (more likely you have a problem with computing).
Finally:
I myself use windows in a virtual environment
I hope you realize that wine is not a virtual environment. Perhaps you're running wine inside of a VM on your OS-- but if you're just running wine on your host OS, I'm afraid you're deluding yourself into a false sense of security. I noticed you were previously (on IRC) calling wine an "emulator", and it is neither an emulator nor a virtualized environment. Perhaps you are confused about what you're really using?
