Code change:
let stdin = stdin.to_handle(c::STD_INPUT_HANDLE, &mut pipes.stdin)?; let stdout = stdout.to_handle(c::STD_OUTPUT_HANDLE, &mut pipes.stdout)?; let stderr = stderr.to_handle(c::STD_ERROR_HANDLE, &mut pipes.stderr)?; <del> si.hStdInput = stdin.as_raw_handle(); si.hStdOutput = stdout.as_raw_handle(); si.hStdError = stderr.as_raw_handle(); </del> <ins> let mut si = zeroed_startupinfo(); si.cb = mem::size_of::<c::STARTUPINFO>() as c::DWORD; // If at least one of stdin, stdout or stderr are set (i.e. are non null) // then set the `hStd` fields in `STARTUPINFO`. // Otherwise skip this and allow the OS to apply its default behaviour. // This provides more consistent behaviour between Win7 and Win8+. let is_set = |stdio: &Handle| !stdio.as_raw_handle().is_null(); if is_set(&stderr) || is_set(&stdout) || is_set(&stdin) { si.dwFlags |= c::STARTF_USESTDHANDLES; si.hStdInput = stdin.as_raw_handle(); si.hStdOutput = stdout.as_raw_handle(); si.hStdError = stderr.as_raw_handle(); } </ins> unsafe { cvt(c::CreateProcessW(

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: App P: App C: Build this in Windows. Since has "windows" subsystem, it will create no console window (i.e. no process). Since is a console app, when the process is created, I expect to see one console window that prints "Hello World" infinitely. App creates its console window but no text is printed. In Windows, spawn() eventually calls to with a , whose  is hard coded to . Additionally, it also with , and set them to the . Since app uses "windows" subsystem, it does not have console. stdout is always . Combining with in causes the unexpected behavior. If I make a call to with same parameters except a "zeroed" , it exhibits the correct behavior. spawn() should only conditionally set the flag if it can obtain those device handles, and never set any of those handles . Like this (pseudo code): <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I think this will need a T-libs-api decision as the current documentation for  (and stdin/stderr) is: I would guess that this "inherit by default" is why it's implemented the way it is. But perhaps there's some wiggle room with what it means to inherit handles that don't exist so we can change it. In either case it would be good to have some way to use platform default behaviour here. label -T-libs +T-libs-api
That's exactly my point. If there is nothing to inherit in the first place, just inherit nothing. The current behavior () is simply wrong. I believe fixing it doesn't violate the current specification.
Basically, currently there are only two options when handling the stdout/stderr: inherit or pipe. I think there should be a third option: isolated - make the child handle its console by itself. For example, if user calls and , he basically says "the parent process doesn't care about the child's output". It is the same as the "windows" subsystem case above. In this case, the flag should never be set, regardless if or is called.