Cannot Import pywinauto (comtypes passes a union by value)

Expected Behavior

When running from pywinauto import Application, the Python terminal should just reset to >>>.

Actual Behavior

When running from pywinauto import Application, Python throws an error.

Steps to Reproduce the Problem

1. Open Python terminal.
2. Run from pywinauto import Application

Specifications

• Pywinauto version: 0.6.1
• Python version and bitness: Python 3.8.1 64 bit
• Platform and OS: Windows 10 64 bit

[mrginglymus]

Happily the changes appear to have been reverted for now https://github.com/python/cpython/pull/17960

[kdschlosser]

On another note…

We are talking about 1’s and 0’s here… It’s always 1’s and 0’s. Windows is all it’s glory really doesn’t give a crap what is passed to it as long as there are enough bytes allocated to fit the information needed.

I have used this kind of an approach on more then one occasion because of the Windows API being goofy. or simply because of an unknown amount of data being placed.

I recently ran into this issue when writing a pure python eHome CIR binding.

There is not a huge amount of documentation for this portion of the Windows API. and what is available conflicts with other documentation.

ULONG_PTR data type has a double meaning when using it with ctypes. some of the fields containing it. when reading what the ULONG_PTR is… it either a ULONG or a ULONGLONG depending on architecture… This is where the documentation failed… some of the fields needed to be set based on the bitness of python while others had to be set based on the bitness of windows. and others were just flat out wrong and are not ULONG’s at all.

class _IR_RECEIVE_PARAMS(ctypes.Structure):
    _fields_ = [
        ('DataEnd', ULONG_PTR),  # out
        ('ByteCount', ULONG_PTR),  # in
        ('Data', ULONG_PTR * 1),  # out
    ]

So I used code like this to deal with the problem at hand.,

class _IR_RECEIVE_PARAMS(ctypes.Structure):
    _fields_ = [
        ('DataEnd', ULONG_PTR),  # out
        ('ByteCount', ULONG_PTR),  # in
    ]
obj = _IR_RECEIVE_PARAMS()
# LONG or ULONG does not matter they are of the same size
offset = ctypes.sizeof(_IR_RECEIVE_PARAMS) + ctypes.sizeof(LONG)
size = offset + (ctypes.sizeof(LONG) * 100)
func(ctypes.byref(obj), size)

data = ctypes.cast(ctypes.byref(obj), POINTER(ctypes.c_ubyte))

It was something to this nature… I can’t exactly remember. I do know that I had found a bug in ctypes with the garbage collection of ctypes objects being passed between function calls because of having to deal with this. Now I know in this case I am passing a pointer. but windows does not really care what the data type is so long as there is enough space or any data it needs can be found at specific locations in memory. I would imagine that anything can be pass so long as it, A: is the correct size and B: data is positioned properly. if that is the case then it should be possible to do the 2 step around that exception that they have added. Now I am not saying it would be easy to do. This is a tad above my head so I really do not know how else to explain it… could lead to an idea of a fix… who knows… I thought it worth mentioning.