$exec would run an executable file and return everything it writes to stdout

Could be very useful. In addition to that, perhaps a $execcall identifier that's multi-threaded and calls a specified command when it's finished running (basically an $exec equivalent to $dllcall).

Being Multithreaded is a requirenment. The main problem is when to return. What if the called application runs for say 2.5 hours? $exec couldnt simply return the data from the pipe becasue it doesnt know when the application is finished writing to it.

That said, A multithreaded version would be a nice idea. Wouldnt it make more sense to just use $run instead of adding a new identifier? Since run already runs an external app $run might make more sense.

What if the called application runs for say 2.5 hours? $exec couldnt simply return the data from the pipe becasue it doesnt know when the application is finished writing to it.

Maybe a buffer allowance on mIRC's end? Not sure if you are farmiliar with php, but you can execute a command, and have its return outputted to the webpage. Changing the buffer can also make it either wait for the application to finish before displaying it. Or, for something like the displayal of a tracert, have the buffer at 2bytes so the user can view it happening, and not think the webpage hung up.

Normally id agree but i dont think buffered output in this case would work too well. Many applications could write a large amount of data etc.. making for a very large buffer.

From what i understood of the idea he wants the identifier to return the inbound data from the pipe. i.e

var %whatever = $exec(some\app.exe)

In order for that to work the app must be run and then mIRC must enter into a wait state (See WaitForSingleObject and WaitForIdleInput), and then set the variable to whatever is on the pipe. (note: this could quite easily reach 10's of kb exceeding the variable size limit).

I think the idea of an async callback would be best in this case. Just my 1 cent

On a side note $exec could use companion idents such as $readpipe and /writepipe etc.. This would work with your buffered output idea as $readpipe would simply read from that buffer returning a special value if the buffer is empty.

It could be handled similarly to the way socket I/O is done (using events, /sockread and /sockwrite, etc.) - after all, TCP/IP and stdin/stdout both operate as streams.