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:[EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 2:24 PM To: [email protected] 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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 >
