Hi all,

I ran into this problem myself today with 3.3.2 and I thought I'd provide some more detail on what's going on. As has been described, prior to VC11, fileno(stdin) returned -2 in applications with no console, so is_valid_fd() was properly rejecting it and the standard streams were being set to None. With VC11, it now returns 0, and the NT handle that underlies the FILE object associated with file descriptor 0 is -2. The problem is that -2 is a pseudo-handle representing the current thread. dup() is simply a wrapper around the Windows API function DuplicateHandle(), so when dup() is called on file descriptor 0, it returns success because DuplicateHandle() is successfully creating a new handle referring to the current thread. It's not until the call to fstat() in check_fd() much later that the CRT realizes it's not dealing with a file.

I see in Mercurial that 3.3.4 and 3.4 that the is_valid_fd() code hasn't been changed. This is definitely a Microsoft bug, but if (as it sounds) they're not going to be able to fix it anytime soon, I think it would be  ideal to have a change for this in Python. Replacing this with check_fd() would fix it, or if you don't want to rely on fstat(), some Windows-specific code using GetStdHandle():

#ifdef MS_WINDOWS
	if (!is_valid_fd(fd) || GetStdHandle(STD_INPUT_HANDLE) == NULL) {
#else
    if (!is_valid_fd(fd)) {
#endif

That would have to be repeated for stdout and stderr using GetStdHandle(STD_OUTPUT_HANDLE) and GetStdHandle(STD_ERROR_HANDLE), as those descriptors have the same problem.