Add stdin_handle and stdout_handle in base::LaunchOptions.

base/process_util_win.cc

Index: base/process_util_win.cc
diff --git a/base/process_util_win.cc b/base/process_util_win.cc
index a1a55ea6e4b73abd8a571f263aa66c24c9cf01fd..508583d9ed4ed3457123ff643a1f2506724f9f2d 100644
--- a/base/process_util_win.cc
+++ b/base/process_util_win.cc
@@ -293,6 +293,16 @@ bool LaunchProcess(const string16& cmdline,
   startup_info.dwFlags = STARTF_USESHOWWINDOW;
   startup_info.wShowWindow = options.start_hidden ? SW_HIDE : SW_SHOW;
 
+  if (options.stdin_handle || options.stdout_handle || options.stderr_handle) {
+    startup_info.dwFlags |= STARTF_USESTDHANDLES;
+    startup_info.hStdInput = options.stdin_handle ?
+        options.stdin_handle : GetStdHandle(STD_INPUT_HANDLE);

[rvargas (doing something else), 2012/12/01 01:40:45]

What happens when the current process has a non-default handle and the caller
does not specify all handles? We'll attempt to pass that value to the child
process :(

How is this intended to work with chromium code in general? Do we expect the
current process to allow handle inheritance? We'd have to document that
requirement.

[Sergey Ulanov, 2012/12/05 00:23:15]

Isn't this the default behavior, i.e. aren't stdin and stdout inherited in the
child processes by default? In either case this is consistent with
base::GetAppOutput()
Good point. Added comments and DCHECK().

[rvargas (doing something else), 2012/12/05 21:51:36]

Sorry, I don't really follow this. What do you mean by default behavior?. stdxx
should not be inherited by default... a process is wired to the console it
belongs to. Of more exactly, the handles used for STD_XX_HANDLE should not be
inherited by default.

As for base::GetAppOutput, I don't see who uses that on Windows other than tests
(and some Upgrade code), so most likely the scenario is quite restricted. In any
case, that should not be the case for base code (or at least it should be
documented).

Just to be clear, if I have redirected IO and use this function to redirect
stdout to a specific file, the child process will get my stdin as a bonus, and
that's not good.

[Sergey Ulanov, 2012/12/05 22:38:53]

I didn't know about it. Is it documented anywhere in MSDN? I couldn't find much
information about default behavior and assumed that it's the same as with POSIX
systems (where stdio streams are inherited). What's the right way to get the
default behavior (redirect stdio to console)?
Yes, I see the issue you are concerned about. I've added DCHECK to verify that
stdin_handle is always set here.
Note that if we ever use Chrome's stdin for anything important then there is
still problem on POSIX systems where stdin is inherited by default when another
process is started from chrome and there are no safeguards to unsure it's always
redirected properly.

[rvargas (doing something else), 2012/12/06 00:52:16]

If the default behavior were to inherit handles there wouldn't be a need to set
STARTF_USESTDHANDLES here, right?

As long as there is a console, stdout should be directed to that console (note
that not all Windows apps have consoles). There are specific functions to
manipulate consoles, and a console is always available even if the standard IO
handles are redirected to something else.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682055(v=vs.85).aspx

[Sergey Ulanov, 2012/12/07 23:11:56]

What I was asking about is if there is a way to redirect one of the streams and
keep default behavior for others.

[rvargas (doing something else), 2012/12/07 23:46:52]

I suspect passing INVALID_HANDLE_VALUE has that effect (aka not passing a
handle), but I have never tried that.

+    startup_info.hStdOutput = options.stdout_handle ?
+        options.stdout_handle : GetStdHandle(STD_OUTPUT_HANDLE);
+    startup_info.hStdError = options.stderr_handle ?
+        options.stderr_handle : GetStdHandle(STD_ERROR_HANDLE);
+  }
+
   DWORD flags = 0;
 
   if (options.job_handle) {