> If one calls Popen with stdin = stdout = stderr = None,
> the caller's std descriptors are inherited on *x, but
> not on Windows

In the default case, CreateProcessW() is called with bInheritHandles as false and without explicitly setting the standard-handle values. Also, creationflags is 0 in the default case, not CREATE_NEW_CONSOLE, CREATE_NO_WINDOW, or DETACHED_PROCESS. In this case, the child's standard handles are implicitly duplicated from the parent if the child shares the parent's console session. Contra "1227748.patch", the standard handles are not "attached to the console window". For example, if the parent's stdout is redirected to a handle for an open disk file, the child's stdout will be redirected to the same open file. It has nothing to do with a window, and the console session doesn't even need to have a window (i.e. created with CREATE_NO_WINDOW; or a pseudoconsole session).

In particular, if the executable image of the child is a console application, the system duplicates the parent's standard handles to the child, as well as a handle for the parent's console session, if any. If the child can connect to the parent's console at startup, then the duplicated standard handles are used, whatever they are. (In general, they need to be handles for pipe, character, or disk files opened in synchronous mode, as required by C standard I/O.) If the child can't connect to a console session, it allocates a new console and opens the console "Input" and "Output" as its standard handles. 

On the other hand, if the executable image of the child is not a console application, the system does not implicitly duplicate standard handles from the parent to the child. The window manager and graphical shell even explicitly reuse the standard-handle values (via STARTUPINFO) to implement features that aren't I/O file related when running GUI apps, including configuring an activation hotkey (stdin) or passing a handle for the preferred output monitor (stdout).