WinError 6, the handle is invalid

On some system, the value get from msvcrt.get_osfhandle is wrong and cause OSError. Here is what my machine get:

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:38:48) [MSC v.1900 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import msvcrt
>>> print(msvcrt.get_osfhandle(1))
7
>>>
>>> from ctypes import windll
>>> print(windll.kernel32.GetStdHandle(-11))
7
>>>

And here is another user’s:

Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import msvcrt
>>> print(msvcrt.get_osfhandle(1))
18446744073709551614
>>> from ctypes import windll
>>> print(windll.kernel32.GetStdHandle(-11))
0
>>> 

Version 0.4 works fine on his computer.

[yirkha]

A simple test that gives 100% repro on Python 2.7.11 (AMD64):

import win_unicode_console
from multiprocessing.pool import ThreadPool

def f(x):
    print(x)

if __name__ == '__main__':
    win_unicode_console.enable()
    p = ThreadPool(1)
    p.map(f, range(10))

[yirkha]

The root cause here is usage of wrong data types in some Windows API calls on 64-bit systems (as demonstrated also by the version strings in the reports above).

E.g. in WindowsConsoleRawWriter.write(), self.handle usually ends up being something low like 84. Because ctypes knows nothing about WriteConsoleW(), it guesses the data type of the first argument to be a 32-bit number.

This is wrong, because the type is really HANDLE, which is supposed to be wide as a pointer on the platform. E.g. in ctypes/wintypes, HANDLE = c_void_p. So the upper 32 bits can be left containing anything, and then error 6 (ERROR_INVALID_HANDLE) will surely be the result.

The solution is to fix the type, either by and explicit c_void_p(self.handle), or with wintypes.HANDLE, or nicely at the time of the import through WriteConsoleW.argtypes (and similar, for the other functions).

My PR (that I’ll post in a few seconds) does it the latter way, like it is already done in other parts of win-unicode-console. And without referencing wintypes, to avoid the extra I/O in arguably the most common parts of the library. Of course feel free to modify/improve/fix as you see fit.