I like this, but I see some problems with it:
1) The behaviour to me would seem like it would spawn a new instance of mIRC. The only feasible thing to do here would be to have mIRC talk to an already running instance to pass the command. In this sense, it should function like DDE, however...
2) This would be problematic if you were running multiple instances of mIRC, since it would be impossible to tell which process to talk to. mIRC works by having the process listen to a DDE service name (defaulting to "mIRC"), which is what mIRC could contact, but...
3) If the DDE service name changes from mIRC to something else, mIRC would not be able to know what it is. In this case, it might be necessary to supply the DDE service name in the command line. I wouldn't have a problem with this.
In short, mIRC should have a command-line switch that acts as a tiny helper method to send a DDE requests to a DDE service (defaulting to mIRC). I suppose it could look like:
mirc.exe -d [SERVICENAME] "command to execute"
Although for parsing simplicity, having a separate switch for the service name might be wise:
mirc.exe -s SERVICENAME -d "command to execute"
Calling mIRC in this way wouldn't actually spawn the client, it would simply send a DDE message and exit, without showing any UI elements-- it would basically be the delphi code shown above.
The only problem I see with having such a functionality in mIRC is that it lends itself for more piggyback abuse from viruses, which could use this command to send DDE messages to arbitrary services (like your browser). I'm not sure how big a deal this is, though, if a virus is already running in memory.
