> Any comments, questions or more feedback on the PR?

I commented on the PR that I'm concerned that ctypes.CDLL will no longer open a path with slashes in it (e.g. CDLL("./spam.dll") or CDLL("eggs/spam.dll")) relative to the working directory, and may accidentally match another directory in the search path. In POSIX, a path with a slash in it is always relative to the working directory and never searched for. In Windows, particularly for the loader, all relative paths are always searched for. This works with the current LoadLibraryW call, with minimal risk of name collisions, because only the application directory and system directories are checked before the working directory, which is checked before searching PATH. I suggest that with the change to use LOAD_LIBRARY_SEARCH_DEFAULT_DIRS, ctypes should first resolve such a path by calling GetFullPathNameW, as is suggested in the Windows docs.

I also had suggested documenting and exposing a subset of the loader flags for use with the CDLL `mode` parameter, which is currently unused in Windows. This would make it convenient for a user to include the flag LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR when the DLL path is fully qualified. However, that was deemed too peripheral to be worth the extra effort of supporting and documenting the parameter and adding the required tests, which is understandable. This can maybe be addressed in another issue, if the need arises. That said, it would be nice to provide parity with C extension modules here, which are always loaded with the latter flag. If given a fully-qualified path, or a relative path with slashes in it that's resolved via GetFullPathNameW, _ctypes.LoadLibrary could automatically include the LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR flag.