Ah, I missed the elevated permissions bit. If you had an executable, 'my.exe' with an application manifest marked for elevated permissions, wouldn't a command line of
"cmd.exe /C my.exe" get you an elevated permissions request? Mark Ovod-Everett, Toby wrote: > 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 >> > >
