3

Apparently using ctypes on Cygwin has the bad side effect of not recognizing the host OS as being using Windows, so the Python interpreter cannot use/import the often used Window (API) specific DLL loaders, such as:

from ctypes import WinDLL
import wintypes
import msvcrt

The reason is that the import mechanism is using sys.platform to check for win32, but receives cygwin, and thinks it's on another OS and therefore disables any Windows related imports.

As I have mentioned in this answer, you can import DLL's using the cdll loader from ctypes, but I have no idea if this is correct and what is the difference from using the windll.

Is there a way to side-load the windll (or wintypes, msvcrt) ctypes libraries on Cygwin?

(It's very sad that Cygwin, ctypes and the python maintainers have not figured out what to do in this case, even after 6+ years of being first reported.)

For reference, when trying to import wintypes, you get:

>>> from ctypes import wintypes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/ctypes/wintypes.py", line 20, in <module>
    class VARIANT_BOOL(ctypes._SimpleCData):
ValueError: _type_ 'v' not supported

Where the offending lines are in wintypes.py: 

class VARIANT_BOOL(ctypes._SimpleCData):
    _type_ = "v"
    def __repr__(self):
        return "%s(%r)" % (self.__class__.__name__, self.value)

ADENDUM

Probably we should not try to use the wintypes libraries in this use case. As stated in the python ctypes docs:

Note: Accessing the standard C library through cdll.msvcrt will use an outdated version of the library that may be incompatible with the one being used by Python. Where possible, use native Python functionality, or else import and use the msvcrt module.

not2qubit
  • 14,531
  • 8
  • 95
  • 135
  • 1
    Generally this is not something you should need or want to do, though admittedly I've wanted to be able to do this myself from time to time. Normally my solution has been to just use the native Windows Python for whatever the relevant purpose was. But what is your use case? Maybe there's an alternative. – Iguananaut Dec 14 '18 at 16:50
  • It seem from the sources that `cdll` *should* [work](https://stackoverflow.com/questions/53775994/how-to-get-a-handle-on-windows-stdout-handles-in-python), but I'm still not clear on the difference. – not2qubit Dec 14 '18 at 17:23
  • Any particular reason (constraint) for using *wintypes* (and co) under *Cygwin*? Cause it kind of smells like an *XY problem*. – CristiFati Dec 19 '18 at 00:14
  • IDK what is an "XY" problem. But I'm building a windows app in python and don't see any reason to have to install a second python interpreter and VS to get it work, while Win OS builders are using MinGW/MSYS2 all the time to build multi-platform apps. Pretty much everything works with Cygwin + MinGW, except some of the Miscrosoft infected Win pythonisms (like WinDLL), that doesn't work or are not being properly maintained. Either way, the code base for WinDLL is small enough and similar enough (to CDLL) that it should be possible to circumvent and do this in a standard portable manner. – not2qubit Dec 19 '18 at 07:44
  • 1
    It's not that they are not maintained, but this is how it should be (as you could see the debate on the *Python* issue). The real bug in *wintypes* is the way to signal the error (raising *ValueError*, when instead it should not even be present on non *win32* versions). *WinDLL* is specifically enclosed in os conditionals. Not sure if I should prepare an answer as it would take long time, and it's also debatable. You can have as meny interpretes as you like (on *Win* I currently have ~12, and I have to add more as the newest one is *3.7.0.RC1*). – CristiFati Dec 19 '18 at 11:35

0 Answers0