Now this post has been useful. Thanks a lot.

Unfortunately I could not test the Win32::GUI solution (since I can't build Win32::GUI due to make errors), but luckily there is an example code which does the same in slightly more complicated way by using Win32::API (which installs on my system seamlessly).

This latter code works for me after some massaging. Though the consolde window is created but is shut down immediately.

Thanks again, this is a perfect solution.

You know, its trivial to create a tiny gui win32 .exe, which sets up all the console hiding stuff, and then launches a hidden perl.exe as opposed to wperl.exe

or you could simply use wperl.exe , call the hiding children function, then launch a hidden perl.exe

wperl.exe won't open the console window for the piped process but the app itself crashes anyway

So you say again :) Maybe you'd like to prove it by posting some code?

This code will create a text file called 'test.txt' with the content 'I'm alive' both with perl.exe and wperl.exe:



use IPC::Open2;

#$pid = open2( \*Reader, \*Writer, "notepad.exe" );

open OUTF, ">test.txt";
print OUTF "I'm alive";
close OUTF;
[download]



Now, the following code will do the same (+open a window for notepad.exe) with perl.exe but will FAIL with wperl.exe (the notepad window is opened but NO text file is created). The only difference is that now the Open2 call is not commented out:



use IPC::Open2;

$pid = open2( \*Reader, \*Writer, "notepad.exe" );

open OUTF, ">test.txt";
print OUTF "I'm alive";
close OUTF;
[download]



To me this is proof that with wperl.exe the execution is aborted at the Open2 call.

I doubt that a wperl process has STDIN and STDOUT connected. I think that IPC::Open2 tries to do fancy things with (an existing) STDIN and STDOUT.

Personally, I would try to avoid IPC::Open2 and/or pipe functionality, at least until after having set up STDIN and STDOUT for the child process.