in reply to Win32::Process vs Win32::Job vs ????

If you're shy of using Win32::API or Inline::C to gain direct access to the native API,

--and IMO you should be, especially if there is any likelihood of your code needing to run on a 64-bit Perl--

then I offer you a low-tech but very effective solution:


## remember to double your \\s if you need to interpolate
system q[cmd /c start /min c:\windows\system32\notepad.exe";

[download]

Pretty much full access to the CreateProcess() api without the hassle, and guaranteed to continue to work regardless of 32/64-bitness or compiler data model (lp64 .v. llp64).

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Win32::Process vs Win32::Job vs ????
by roho (Bishop) on Feb 28, 2011 at 20:01 UTC
    Thanks for the suggestion, but I moved from running "start /min ..." in a system call to Win32::Process so I could kill the process via its process id later in the same script, and that all works fine. My current "minimize" workaround (which I don't particularly like) is to sleep x number of seconds after launching the first program via Win32::Process to give the program time to initialize and start running (takes a little while), before starting the second program. This allows the second program to be in the foreground hiding the first program, which is why I wanted to run the first program minimized. It's not a perfect solution, but it does what I need for now. I agree it's a shame Win32::Process does not accept window attributes.

    "Its not how hard you work, its how much you get done."

[reply]

In Section Seekers of Perl Wisdom