Forums Feature Suggestions Registry Manipulation

mIRC should have commands and identifiers to manipulate the Windows registry. This would be extremely useful in my opinion.

I'm very aware that implementing this feature would be a field day for some malicious users, but if this is added, an option should be also implemented to disable registry access via mIRC.

if i remember correctly there is a dll out there that does allow registry manipulation for use in mirc ..... altho i am not positive of its name or where abouts. i once went on a search for dlls for mirc to see what i could find and toy around with..... id have to assume that would be the safest way to manipulate your registry by only having that dll ....... i could only imagine how bad things would be if mirc had it built in to every download that someone could use something similar to that matrix deal to mess up your pc on ya ...... again im thinking its just a dangerous thing to put into mirc from the box but it would be a nice idea to be able to have it at your disposal

As _D3m0n_ said, there are already DLLs for this, and if I'm not mistaken, it can also be accomplished using COM.

It does, by providing COM support. You can use the WshShell object (registered as Wscript.Shell) and its RegRead, RegWrite and RegDelete methods. They do not do stuff like enumerating (ie allowing you to loop through) registry keys/values, but they should be enough for what you want to do from within mirc. If you want these extra features, you'd better get registry.dll by Dragonzap. Here's what I use for reading/writing:

Yeah you can do it by using COM, IF the user has the Windows Scripting Host installed, And not all users do. Also, There are numerous features that could be done in DLL's. Given that DLL's can do just about anything, I think dismissing a suggestion because "You can do it in a DLL" is unfair.

This isn't a feature that's easily scripted.

$regread would be a good idea I think, /regwrite is debateable.

There is already MDX, I bet the next mIRC version will introduce new 32 bit controls. There was already an MD5 DLL, and an MD5 script, mIRC introduced $md5. Those are just some examples off the top of my head. Registry manipulation is a basic and useful function of most languages.

Further more, Including DLL's with mIRC scripts is an undesirable requirement because mIRC lacks in some areas. It's not a reason for mIRC to continue lacking.

read my post as to why it shouldnt be a built in thing into mirc ..... remember alot of ppl using irc dont even use any scripts and they fall for alot of things like the matrix $decode crap ...... this would open up a major security issue in mirc if this were to be added as a built in feature ...... id rather see it as it is right now ..... only a select few ppl have in because they have added it themselves ...... and normally the ppl who add it themselves wont be stupid enough to alter thier registry on hte suggestion of nother chatter they dont even know

The particular methods (RegRead, RegWrite, RegDelete) are implemented in version 1.0 of WSH. v 1.0 exists on every windows os starting from win98. So the only users that will not be able to use the aliases are win95 users. It is generally believed that they have become extinct, but for the few remaining ones... well, sucks to be them.

I agree that /regwrite is a bit risky. I think $regread isn't so risky though. The only risk is //say $regread(My_Serial_number_or_password_stuff). There are a lot of risky commands within mIRC however. And the only ones you can disable are /run and /dll, which are incidently, enabled by default.

You can execute COM, and all the file/folder manipulation from a chat window, with simple commands.
There are also ways to get sensitive information from people just by telling them to /dcc send particular files. So to focus on regread for safety is unfair.
People have to learn for themselves not to type stuff or accept files. And the REG commands do not generally compromise the persons Box, and lead to platform for harming others. They only harm the ignorant user. Khaled could simply prevent these commands from being executed in the command line. That way, the person must atleast accept a File. And if a person is willing to accept and run unknown files, No safety measure will ever protect them. It's a basic fundamental thing that they have to learn, and mIRC's progress shouldn't be impeded because of them. Because they will inevitably come to harm anyway.

And regarding COM and WSH. In my version of windows98, WSH is not installed, even on the Full install. It is an optional component on the CD. However, Perhaps this changed for 98SE.
Regardless; Many Anti-Virus programs encourage users to disable WSH. Asking a user to install, or enable WSH, just so that a mIRC script can do a $regread through COM isn't so good. It's like imposing a real security risk on those mindless users you worry about, For the sake of averting a possible, minor risk in mIRC.

It may be possible with COM as you say, but I don't know anything about COM and I don't care about COM.

Wrong. They are DISabled by default.

Umm well it's not our problem that you "don't care about COM". qwerty already gave you the aliases to add, if you don't like that, thats not our problem.

I just installed fresh copy of mIRC, both /run and /dll were enabled..

Did you delete the registry entry first?

No you are wrong. /dll and /run are enabled by default. Download a *Fresh* copy of mIRC from one of the mirrors, Uncheck the boxes that say "Keep my current settings", and install mIRC to your desktop. I formatted my disk just last week and did a clean install of mIRC , so there is no lingering registry settings. All such info is stored in the mIRC.ini, anyway. And FYI, I just downloaded mIRC again to verify that I'm correct. Even if I wasn't correct, it doesn't invalidate the point of my post at all.

Disable commands
This allows you to disable the /run and /dll. Although these commands can be quite useful in scripts, they are disabled by default to protect new users since some scripts might be harmful. See the Accepting Files section for more information. Once you are confident enough and know how to accept files safely, you can enable these if you wish.

"Keep my current settings" Obviously if you have previously enabled them the setting will be kept. :tongue:

I would imagine there's many features that mIRC currently supports that could be accomplished via COM Objects, but Khaled still implemented commands/identifiers into mIRC to perform those tasks. Why not Registry manipulation? Just because it can be done via other methods is not a good excuse why there shouldn't be commands and identifiers to manipulate the registry. You must keep in mind that not everyone knows how to work with COM Objects, and probably doesn't care too either!


Obviously you haven't read the third locked post in this forum:

Here's a quote from the post:

"Improve on suggestions or show the poster why his suggestion just wouldn't work or make sense ("you can script it" is not a valuable response).

Remember that people come in here looking to pitch an idea to Khaled, not for other forum members to shoot ideas down."


That's what you're doing, shooting down my idea.

I dont care what the help file says, It wouldn't be the first time the help file is wrong. Do this.

Open mIRC, Disable the Commands.
Go to control panel, Uninstall mIRC.

So that you now have no mIRC installed on your system at all.
Download mIRC. Open it. Behold, the commands are enabled.

The commands are only disabled IF:
* You have mIRC already installed with them disabled. (The installer disregards what you check, and keeps current settings for that item).

On a new system, the commands are enabled. They are not disabled until you have done it manually.

In my test i removed every mIRC folder from my system. I opened Regedit and searched for 'mIRC', I deleted all the relevant keys.

Instead of people giving reasons why there shouldn't be registry manipulation commands in mIRC, why dont you give some reasons why there should be? I can't think of any reason why it is reasonably necessary to have that sort of access built into mIRC.



- Well if they really want to use the registry then they've got a reason to care haven't they?

As far as shooting down your idea, I think you'll find most people are simply giving reasons why there's little need for this feature in mIRC. As the 'forum guidelines' thread also says: "You should try to stick to ideas that would help lots of people". I don't see this feature helping many people, do you?

Actually I do have a good reason why it should added. Two good reasons in fact. The Registry is a good place to store values for a script, and it beats storing values in a hash table, ini file, or variable. You may also want to change current registry settings via an mIRC script for some reason. I imagine there's other possibilites, but those are the main two that I would use it for.

I have read it; perhaps the problem is you only read part of it:

Would it be easy to write a script for my idea?
If it's something that is very easy to do with scripts, chances are it won't be built into mIRC. (This isn't always the case, but should be considered when posting your idea.)

Seeing as how qwerty already gave you the code, "I don't know COM" is not an excuse, simply use his, and looking at his code you can see it is ~10 lines, I'd say that is "easy" and "simple" and therefore shouldn't be implemented.

You are right saying "you can script it" is not always a good answer, but if someone says "I want $n instead of $nick" should we all say "Well it can be scripting, but since thats not a good answer, I guess Khaled should add it." Or should we tell the user that he can simply make $n an alias to $nick, me, I think the latter is the more sane answer.

Why is it better? Because it is less secure? Because it is slower? Give a reason why it is better rather than just saying it is better.


For "some reason"? Well give us a reason, if you want to say that is a use for it, give us an example, don't simply say that someone may want to use it, give us an example of where it would be used in this fashion.

"I don't see this feature helping many people, do you? "

I would ask Dragonzap how many people have downloaded his regestry DLL's. And a quick check on MS.org shows 700 downloads for regsitry related COM snippets. I would say thats a more significant number than the few people who have posted here that "DLL's can do it". And I wouldn't say that those responses are in the spirit of the thread at the top of this forum either. There are lots of uses for accessing the registry. The reason why it's not part of mIRC is not because it's a useless feature, as you imply. The reason is most probably the abuse concerns..

Maybe it's easy for you or qwerty to script it, but like I said numerous times, not everyone knows how to work with COM Objects. I would not classify scripting registry manipulation as an easy task for the average mIRC scripter.

And like I said, and you neglected, you do NOT HAVE TO SCRIPT IT. Qwerty already gave you the code, Windows has this nice feature called "copy and paste," seeing as how he posted his code on the forum, it makes it clear that he is saying anyone can use it, so why would you bother scripting it when he already did it for you?

Slower? It's not noticeably slow. Are you trying to say an INI file is much faster to access than the Windows' Registry? If that's the case, then why didn't the developers of Windows store the operating system values to an INI file instead of the Registry?

I would have to say the reason I think it's better to store values in the Registry is because it's a place where many average users don't mess around with, therefore, a user will not accidently mess with the values of a script. With an INI file, a user can just make a simple edit, and that can seriously break a script. And it's a more professional practice to store values in the Registry.


If you still think Registry support is useless, then why did DragonZap write a dll to do this? Just because you have no use for it, that doesn't mean the rest of the mIRC users feel the same way. I don't have use for mIRC's Agent support, but do you see me complaining about it? No.

Time For My 25 Cents Worth (inflation)

maybe i am wrong, probably am but, isnt the Registry jsut like ONE BIG FREAKING INI file? i mean, sure, it uses a different format, but the fucntion is basically the same, it stores values for programs to retrieve when needed, like an ini file.


one little slip in the registry can break your whole computer. whats worse, losing a script or losing windows? More Professionial? NOT!! What Makes it professional in putting stuff in the registry vs a INI file?



ummm maybe because he was bored?

I doubt that's why. I'm guessing he wrote it because it was requested by other mIRC users who have use for it!

Like I said before, if the Registry is like an INI file, then why did the developers of Windows invent a Registry anyway? No one seems to want to answer that. You and the others claim that the Registry is indistinguishable to INI files, then wouldn't an INI file be just as good to store Windows' settings? I'm tired of arguing about this.

personally i think using the dll or com as someone else posted is alot safer for everyone .. i dont think this should be added just based on the security risk it entails to the not so educated mirc user ...... if ur able to be messing around in ur registry then u should be able to use a dll inside of mirc to so it from ...... if u arnt advanced enough to understand how to use a dll then u shouldnt bemessing around in your registry ... its simple as that no arguements left to say

I know how to use dlls, it's COM Objects I don't understand. I edit my Registry all the time manually, I know what I'm doing. If security risks are the reason this should not be implemented, then why not have Registry access disabled by default? End of problem!

well if u know how to use them then use them ...... i dont think the average user of mirc needs a huge security issue in thier mircs ....... imagine the havoc this would cause ....... id hate to see mirc get a terrible rep because ppl are stupid enough to enter commands random users tell them any worse than the matrix deal ..... manipulation of your registry is a terrible thing to do if u dont know what your doing ... so as ive stated already if u can use dll ... do that its going to leave an all together more safe mirc for all users if only the ppl who know how are doing it ........ u see what im saying? im not knocking your suggestion i can see why u would want this ability ...... but 95% of all mirc users would have this huge security issue if this was to aded ...... and u know how many ppl dont proterct themselves it would turn mirc into the biggest joke going if this was added for morons to send u commands to mess up your pc

Yes you are right, less users look there, which is why it is always the perfect place to hide a virus, why give mIRC the easy ability to do that?



Well I never said registry support is useless, I asked you to provide a reason why it isn't, which you have still failed to do. And as for Agent support, it serves a very important purpose. Perhaps you don't know but there are several blind people that use IRC, MS Agent support allows them to use mIRC to chat because although they can not see what is said in the channel, they can now hear it. Allowing the blind to use IRC certainly supercedes any possible reason you can give for needing registry access.

And exactly how would you hide a virus in the windows registry, from the mIRC command line? The answer is: You can't.

If a person has to accept a file off you for registry commands to be harmful, then your safety argument is null and void. Things such as sockets are potentialy more harmful than registry commands, once a file is received.

We've already mentioned that /regwrite can be disabled from command line. A few of you made an attempt to say that reigstry manipulation is useless in return, now what? The commands can be made safe.

Ignoring Anti-Virus advice and enabling WSH so mIRC can do $windir and $regread is moronic.

The thing that I don't understand is this, many are worried that if registry support is implemented, it would cause a lot of security issues. What about Com Objects? Can't that cause just as much risks as registry support? I would think so. You said yourself that qwerty made an alias that can access the Windows' registry. Well, if it can be done through COM Objects, then what would the difference be if there were commands and identifiers just for registry manipulation? I can't honestly see any difference. COM Object support is just as dangerous as registry support.

From what I understand, someone who was good with COM Objects could easily write an mIRC script that could do far more damage to a user's operating system than just messing with the registry.


A person who is not sure about script should not load anything they don't understand! Then there would be no problems. Am I right?

I'm not talking about receiving a file, when you received a .mrc you have to/loar -rs it, I'm referring to the "type .......... to stop spam!!!" messages. It seems that people have been smart enough to find things like matrix.ini in their mIRC directory, but for the most part users are told NOT to edit their registry unless they know what they are doing. My guess would be that users who would type such a message do not know enough to start playing around with the registry. Therefore if one of those "no spam" messages contains code that tells it to execute something in /regwrite, it would be a lot harder (and less safer) for the user to go digging around to try and find the problem than it is to look in the mIRC directory to find a new script file. Just a quick example, I have a "no spam" line that adds something to the autorun section of the registry telling it to launch mIRC with a few commandline flags that make it run minimized (and of course since I have registry access it also sets mIRC to minimize to the tray making it less noticable), and it loads a script that performs malicious acts. Unlike the typical "no spam" script where once you delete the bad script file you are fine, that won't help you in this case because the file will be regenerated when Windows restarts and the registry line is executed again.

It could be disabled from command line. mIRC has a lot of powerful commands, that control the users PC from the chat window. I find that not adding features because of this is more repressive than disabling some of them from the command line. The ability to recursivly delete files from the command line isn't so hot either.

You are right, COM can do some very dangerous things, but COM scripts are not a single line of mIRC code. As you can see in something as simple as writing/reading to/from the registry required ~10 lines. It would be harder to persuade a user to type all 10 of those lines into mIRC than it would be to persuade someone to type a single /regwrite line.

The kind of users who would execute such code just because someone tells them to most likely don't even know what a command line is.

One other thing, if you have /dll and /run disabled, but /regwrite enabled, then you in essence have nothing disabled. Because I can set up a script that simply:
/regwrite HKCU\Software\mIRC\LockOptions 0,0
And then I can use /dll and /run whenever I please.

Please read the posting guidelines on this forum.

If it can be done via DLL, the chances of it being added to mIRC are zero to nil, at best. It is not Khaled's intent to make mIRC into the next operating system or programming language. Registry access is currently possible, and with utmost ease... the DLLs come already installed with windows, all you need is a <10 line script to access them. Only users with the intention of propagating the next trojan/worm would be so insistent on having the command built in natively.

- Raccoon

//var %a = $findfile(c:\,*.*,*,.remove $1-)

That would be enough to screw up most systems. Windows has file protection, But a user upon booting would get error messages. This is enough to make a lot of people think they have a virus and format. Perhaps this would even corrupt the OS completely. Either way, the damage to the users OS is tremendous. And all from a simple command in a chat application window.

Now, Im not suggesting that because dangerous commands already exist, that we should add more. Im suggesting that certain commands should be disabled from command line. So that a user has too atleast accept a File.
Im also pointing out that this feature suggestion doesn't have to dismissed on the grounds of safety. One of the possible alternatives to this suggestion was using COM. Which means WSH. And that means the users system is now open to all those .VBS exploits, Just cos a mIRC script said "To use this addon use must enable WSH". WSH may well be enabled by default in NT, but a lot of people disable it with there Anti-Virus applicaitons.

Will you please read the guidelines to this forum?

"If it's something that is very easy to do with scripts, chances are it won't be built into mIRC. "

Your taking that out of context and using it unfairly to dismiss this persons feature suggestion.

As I already stated earlier, DLL's can do just about anything. So we dont need a feature request forum at all. Do we?

"you can script it" is not a valuable response" - Did you just ignore that part of the forum guidlines or what?

Your telling me this feature has no chance of being added. I thought that was up to Khaled too decide?
Many features have been added that are already accomplished by DLL's and SCRIPTS even.

If you had bothered to read the rest of the posts you would of seen the part where I pointed out that WSH is NOT installed on all systems. Further more, Anti-Virus programs encourage it too be disabled. Enabling WSH makes the in-experineced user far more vulnerable too worms and trojans!



You can't address anyone of my points with a sensible answer and so you resort to insulting me, I do not appreciate that.

Ignoring Anti-Virus advice and enabling WSH so mIRC can do $windir and $regread is moronic

Ok, you mentioned this before too, so I gotta ask: which antivirus completely disables WSH for security purposes? I have Norton Antivirus 2003 and the only related feature is Script Blocking. SB does not completely disable WSH though: it prevents (or pops up a warning before it does) script files (such as .vbs, .js etc) from being run. It doesn't even disable ALL scripts, only those with "suspicious" commands in them (such as file operations). It certainly does not interfere with the COM interface of the WSH objects, at least here.

mirc can do $windir and $regread (and even $regwrite) just fine with Norton Antivirus SB enabled. I don't know what other antivirus software do and whether they disable WSH completely, but if something sounds moronic is to disable the entire WSH (including its COM interfaces) just because of some strange belief that "it's safer".

I never stated that it disables WSH automatically. In previous versions there was an option to disable it, you were advised to disable it. I don't know about Norton 2003. But I do know that the Symantec website still recommends the same thing that you call a "strange belief":

"One preventive measure that you can take to protect yourself from viruses that come as .vbs attachments is to disable or uninstall the Windows Scripting Host. Because Windows Scripting Host is an optional part of Windows, it can be safely removed from your computer. This feature can easily be reinstalled if it is needed in the future. Remember that there are many other viruses that do not use the Windows Scripting Host, so it is critical that you continue to use Norton AntiVirus protection with the most up-to-date virus definitions. "

You have to remember not everyone uses Anti-virus software, Let alone Norton 2003. So it is indeed safer for people to follow the above advice. Basically your snippet is reliant on 2 external programs; WSH, and seeing as you now have that security risk enabled you better get Norton2003. That isn't so great.

Eep. This thread is getting out of hand. The suggestion is out there and there has been very little constructive criticism. Just because something can be done via COM or DLL support doesn't mean that it isn't a valid feature request.

Remember, this isn't a forum to debate feature ideas. It's a forum to suggest ideas. The only debating done is inside Khaled's brain (ok maybe arnie helps a bit)

-chris

I never stated that it disables WSH automatically.
I never stated nor implied that you stated such a thing.

One preventive measure that you can take to protect yourself from viruses that come as .vbs attachments is to disable or uninstall the Windows Scripting Host.
Finally, we're getting somewhere. What Norton states is that .vbs attachments can be dangerous. This is not a "strange belief", .vbs attachments are indeed responsible for the spreading of viruses. Clearly, a way to stop .vbs files from being run (or ask the user with big red exclamation marks about it) is needed. The simplest, but most naive, method is to uninstall WSH. What - it seems - you didn't realize is that there are ways to stop .vbs files from being run other than uninstalling (or completely disabling - note the bold) WSH. Norton AV does that very well: it prevents (or asks the user whether it should, something that's configurable) scripts from being run, nothing more, nothing less. This means that no .vbs, .js etc files can be run, but the COM interface of the WSH objects still works. THAT's what mirc uses in $regread/$regwrite/$windir: it communicates with the objects via COM, it doesn't run any script files. So, no running scripts = everybody's happy (mirc, Norton and the user).

Yes, you are reffering to Norton 2003. As far as I remember, the older versions of Norton just gave you an option too disable WSH. And the above advice from Norton says that it's safer to disable WSH. Your COM snippet demands that WSH is installed, and for safety you must use Norton 2003. That's 2 dependancies that I wouldn't want to impose on the users of my scripts. What if a user doesn't have Norton, and they install WSH to support my COM script, It will then be my fault when they get infected through email attachments, etc. That is a very real scenario. mIRC could implement $regread (Note, I never upheld /regwrite in the first place), and there would be no security issues attached to it.

This doesn't matter anyway, I don't wish to debate the validity of using WSH in mIRC. This feature request is good enough to stand on it's own, regardless if WSH snippets work or not.

I believe all the arguments on this topic are exhausted now. As d00d said, the feature request is here, lets leave it too Khaled to decide..

i think also $regwrite and $regread is useful,
the creation with com objects or dlls is more dangerous than an $regwrite or $regread to disable or enable.

The most of "normally" mirc User dont know

The Download an normal Addon, and than are an com objects or dlls is on it and the trojan has been installed (And there could also read/write in registry)

With reg commands to enable/disbale it, is the responsibility from the users only.
And if you could choose which scriptfile is it allowed to use $regread or $regwrite it is saftlier than uncontrolled com objects or dlls in mIRC

The other Way:
dlls now it can be disable
com objects must be the same (I couldn't disable my WSH on my complete system, only why mirc could use it...)

Everyone know this, and khaled could be add an hint if there reg commands or com objects (with wsh or any other objects) on it.

So the user knows.
if he agree, is it his problem

Prizm, you specifically mentioned keeping script values safe from users. You don't need a windows registry manipulation to do this. All you need is hash tables. In fact, that is one of the best reasons for using hash tables.

Having said that:

1) Ethics: script users should be able to tinker with the script values, or else you should not be able to set those values yourself.

2) Windows Registry Manipulation will open mIRC to another category of hacker. We all know this. I'm surprised no one has mentioned it on this thread.

3) Prizm, if you don't know how to work COM objects, how do you REALLY expect to know how to mess with the windows registry safely?

As you do talk about the regitry ediiting scripts--



*also assuming the enviornmental variable alias was added.

Are you saying that would cause a virus to open every time the computer is started?

Dude, it might even get worse than this. The DALNet hacker club has found even more exploits than the mind can fathom WITHOUT such easy access to the registry. They could possibly do a field trip with this.

* sings in his head o/` The wheels on the bus go round and round... o/`*

You do mean Field Day, right?

Personally, I dont see any valid reason why a CHAT program needs to have any kind of registry commands/identifyers. I know people will say "because it's better/easier than using "X"" to which I say, it might be better sure, but that doesnt mean it has to be there.

if uve read this thread from the very begining ud see the very reason many have been slightly opposed to this is the sole fact of having a very dangerous manipulation set built in to every mirc that could do so much more than just start a virus on your pc everytime u start ...... say some fool figures something like this is set in on all ur mircs and makes up a $decode of something for ppl to type in the wipes out thier registry
not only is that worse than a virus to some ppl ....... but add the fact that passwords to your system are stored into this ...... now the intelligent scripter can now make your system do ANYTHING he wants ..... total control of manipulating anything in your pc from a remote settup ....... and think of it like this ...... if its a registry change and not a program change how would a virus scanner find this alteration? ...... most times it wouldnt ....... ud end up with a pile of hacker enabled junk and ud be causing a horrid flood of networks simply because some immature child learned a couple commands to have an inexperianced user cut and paste ....... i personally wouldnt like mirc to end up a total joke of all programs for having this type of huge security issue just based on the fact it has alot of limited knowledge users

My God people!

Quit it! You're insane monkies!

Ok, I'm going to start off by saying that if registry read/write were enabled by default, people could create some pretty creative scripts by doing such things as scanning for reg keys of certain installed programs, then going from there.

The bad seems to far outweigh the good though. I think registry manipulation using a simple command is a terrible idea. Just think about all of the morons that listen to the "no spam" and "matrix 2" messages.. mIRC WOULD most likely become a terrifying program to use to morons, and yes, there are a LOT of morons in the world today, why do you think infomercials work so well?

When it all boils down to it, if there is no such thing as $regwrite or some similar command, then there won't be the possibility of morons and newbies running very very malicious code, but registry editing for scripters is still very easy to do by using that nice little dll or that simple little script posted somewhere inside of this thread.

You might argue, "Well what about the scripters who don't know about the DLL or the code snippet?". If they don't know how to go to this place called "google" and search for what they need, then they are probably a severe newb and shouldn't be messing with their registry in the first place.

I'm not saying the suggestion is a bad idea. In fact it would be great if such a feature could be enabled, but because of lamers who like to write dumb little $decode scripts, features like this simply should not be added.

Keep in mind guys: This is not a voting board or a debate club, arguing things till you're blue in the face isn't really worth it. You should state your opinion if it is constructive criticism, but you really shouldn't argue your point over and over.. The same goes for the person who made the suggestion to begin with. (yes, it is irritating when someone severely tries to defraud what you suggested, but I think khaled is smart enough to debate the issue for himself). Unless you have something new to add to your arguement, why argue?

-- My mIRC did not come with /run and /dll disabled. They were enabled. (just because the help file says they're disabled by default doesn't mean they are..)

-- To anyone who knows how to use COM objects: Are COM objects easy to use? If so, could perhaps a small list of useful COM objects be listed somewhere? I'd like to see what I could do with them.

very very well said you got my point acrossed more clearly than even i did