The OP's point was that mIRC is missing the ability to call the SendMessage API using a previously created memory mapped file. There are lots of implementation problems with this (mIRC would have to automatically keep track of the memmapped files for the response sendmessage-- this would actually be impossible without introducing a new event that contained such a context), but let's forget the implementation details completely:

- SendMessage is not a good arbitrary data transfer protocol. The receiving end needs to have a GetMessage runloop, which most languages don't easily support (.NET does away with GetMessage loops, hacking it in is painful; other languages like Python would require extra library code). SendMessage works for sending commands to mIRC because it is built with a message loop; it's easy to send stuff to mIRC, not as easy to get stuff from mIRC.

- Using a memory mapped file or named pipe directly would be better but still not ideal because it requires polling on the file/pipe to detect when something was sent. Ultimately you would need to create 2 pipes, one for stdin/out, and poll/write. mIRC probably doesn't need to expend these resources.

- Sockets require polling but you can easily detect when a new message was received (as opposed to simply seeing new data being written to a named pipe as part of a long message, or having to delete data in a named pipe to send a new message).

In short, adding the ability for mIRC to respond to SendMessages just wouldn't be a useful solution to the problem. As pointed out above, it requires the external program to know and handle message loops, which is uncommon nowadays. There are better ways to do this in general, namely, sockets, or even COM. Also, there is often a case-by-case solution; in this case, if the problem is that Python RPC is complicated, the solution is to use something like Python4mIRC or a Python specific IPC mechanism. If this were a .NET question, the answer would be COM.

FYI this was all pointed in the thread, which means nobody missed the point.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"