Hm. You seem to be specifying a moving target.

Originally, it was a windows equivalent of ulimit you were after.

Then you seemed to be mostly concerned with asynchronous execution.

Now you've dropped that in favour of:

1. Obtaining the exitcode.

   Is this going to be useful if you are going to kill the process per the original requirements?

2. No shell interpretation.

   Which belies the examples you posted in your OP which both use shell interpretation.

3. A new requirement for separating STDOUT & STDERR.
4. (And the portability requirement.)

It's almost as if this latest "requirements list" were taken straight from the IPC::Run features list. Which would be fine if it worked.

There have been many attempts by a lot of clever people to try and hide the differences between *nix and Win32 Process control, and to my knowledge, none of them have yet succeeded. Mostly because they tend to start with what works on *nix and then try to force Win32 to work the same way. These attempts are pretty much doomed to fail because the *nix solutions rely upon using select to prevent blocking IO, but Win32 pipes do not work with select. Win32 pipes have their own asynchronous mode of operation--several different modes--but they do not fit the *nix select model.

The single best possibility I have seen for the creation of a *nix/Win32 portable solution to the requirements you describe is salva's Win32::Socketpair, which exports a winopen2() command that is equivalent to IPC::Open2::open2(), but uses sockets instead of pipes between the parent and child processes. As win32 sockets do allow the use of select, this allows *nix asynchronous techniques to be layered on top of it successfully.

However, he stopped short of providing an winopen3() entrypoint which is what would be required to meet your latest set of requirements. I do not know whether he didn't try, or failed to succeed.

If you have a particular requirement for a win32 solution--that you can describe in sufficient detail that I can re-create the circumstances locally, and test locally--I can generally solve it. But I am not equiped to addressing theoretical, generic, cross-platform requirements.