His problem (seen from earlier in the thread) is that anything that
starts the process via CreateProcess doesn't work properly with elevated
permissions. He has to start the process via ShellExecute to get the
elevated permissions to work properly, but he still needs to capture the
output. Thus my proposal to write a custom app using PerlApp that is
marked as requiring elevated permissions and is started via ShellExecute
and that in turn starts the C installer app using CreateProcess (or
system() or open(), which both use CreateProcess), but hopefully the C
installer app will thus inherit the elevated permissions attached to the
small wrapper PerlApp. The wrapper PerlApp can grab the output and use
a file, named pipes, TCP/IP connection on localhost, or whatever to send
data back to the parent process (it can't use STDOUT since it was
started via ShellExecute).
--Toby Ovod-Everett
-----Original Message-----
From: Mark Dootson [mailto:mark.dootson@xxxxxxxx]
Sent: Tuesday, July 03, 2007 2:24 PM
To: wxperl-users@xxxxxxxx
Cc: Ovod-Everett, Toby; Ed W
Subject: Re: [wxperl-users] grr, vista issues
If buffering isn't your issue, you could take a look at
Wx::Perl::ProcessStream on CPAN. It may do what you want.
Regards
Mark
Ovod-Everett, Toby wrote:
> Totally missed this reply for some reason . ..
>
> -----Original Message-----
> From: Ed W [mailto:lists@xxxxxxxxxxxxxx]
> Sent: Saturday, June 16, 2007 11:54 AM
> To: Ovod-Everett, Toby
> Cc: wxperl-users
> Subject: Re: [wxperl-users] grr, vista issues
>
>> No, I wrote the app, so I don't think it buffers its output (or if it
>> does then it can be changed)
>
> If it's using STDIO, it buffers by default as soon as STDIO discovers
> that the output device isn't a console but is a file or STDIN of
another
> program. Thus $| in Perl (which should be set to 1 for handles where
> you want to ensure that they do not buffer). Thus the common idiom:
>
> select((select(MYHDL), $|=1)[0]);
>
>
>> I had considered running the program via shellexecute, spooling the
>> output to a file and reading in the file. Seemed quite ugly
though...
>
>> I hadn't really given it much more thought, but why would I need a
>> wrapper around the shellexecute? Does it turn out to be difficult to
>> start that up with output redirected to a file?
>
> Capturing output is a weird business, having to do with all sorts of
> weird plumbing stuff in NT that I don't completely understand. I
don't
> think ShellExecute lets you specify STDIO handles - that's a Microsoft
> decision. See http://msdn2.microsoft.com/en-us/library/ms647732.aspx
> and http://msdn2.microsoft.com/en-us/library/ms682425.aspx and see if
> you can find the equivalent of the STARTUPINFO structure (one of the
> options to CreateProcess) for ShellExecute - I don't see it. The
> STARTUPINFO structure includes hStdInput, hStdOutput, and hStdError,
> which is, I presume, how Perl goes about capturing output (by creating
a
> handle and passing it in STARTUPINFO).
>
> Given all of that, I think you're going to have to use some program to
> capture the output. Whether that program is $ENV{COMSPEC} using ">"
to
> redirect it to a file or whether it's a custom Perl program that uses
> named pipes or something like that to communicate back to its "host",
I
> think that's the route you're going to have to follow.
>
> --Toby Ovod-Everett
>
> -----Original Message-----
> From: Ed W [mailto:lists@xxxxxxxxxxxxxx]
> Sent: Saturday, June 16, 2007 11:54 AM
> To: Ovod-Everett, Toby
> Cc: wxperl-users
> Subject: Re: [wxperl-users] grr, vista issues
>
> Hi
>
>> Does the "small C based installer app" use buffering on its pipes or
>> not? If not, is there a way to write another small C (or
> PerlApp-based)
>> wrapper that is also marked as needing elevated permissions that will
>> then start the installer app and redirect its output to a temp file
> that
>> can then be read by the Wx app?
>>
>
> No, I wrote the app, so I don't think it buffers its output (or if it
> does then it can be changed)
>
> I had considered running the program via shellexecute, spooling the
> output to a file and reading in the file. Seemed quite ugly though...
> I hadn't really given it much more thought, but why would I need a
> wrapper around the shellexecute? Does it turn out to be difficult to
> start that up with output redirected to a file?
>
> Cheers
>
> Ed W
>
|
