Avoid undefined behaviour of LoadLibrary() on Windows. #553
Conversation
According to [1] the flag LOAD_WITH_ALTERED_SEARCH_PATH should be used with absolute paths only. It has the effect, that the path of the DLL to be loaded is temporary added to the search path, so that dependent DLLs in the same directory can be found and loaded implicit. However for relative paths the standard LoadLibrary() search order should be used, because the behaviour of LOAD_WITH_ALTERED_SEARCH_PATH isn't defined for relative paths. In practice (on Windows 10) relative paths to Windows system DLLs do work, so that the library is loaded, but DLLs in other search paths are not found, when this flag is set. Ruby's fiddle library uses LoadLibrary without flags in both cases. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx
|
I've opened the same issue on jnr/jffi#45 for JRuby. |
|
@headius Can you merge this PR into the release? |
|
... It's a blocker for many FFI based gems in the new MSYS2 based RubyInstaller environment. See oneclick/rubyinstaller2#4 |
|
Thanks @tduehr ! |
|
I couldn't get ffi to compile with this change. It looks like an I wonder why the tests didn't catch this. Perhaps it is a problem on my machine... |
|
@daniel-rikowski yes this include is missing. This is addressed in #556 but not yet merged. |
|
Ah, thank you, I didn't see that. |
|
Hello again! I just merged and released jnr/jffi#45 and will look into this one now. |
|
Ok I see this has been merged as well but presumably not released. |
|
@tduehr @enebo @larskanis I don't know who did the win32 binary release last time...ping me and we'll coordinate on getting a new ffi gem out. |
|
@enebo @larskanis @headius It was probably me. It uses a docker image to build it so it's quite easy. I just have to remember to do it. I'll cut a release later today. |
According to [1] the flag LOAD_WITH_ALTERED_SEARCH_PATH should be used with absolute paths only. It has the effect, that the path of the DLL to be loaded is temporary added to the search path, so that dependent DLLs in the same directory can be found and loaded implicit.
However for relative paths the standard LoadLibrary() search order should be used, because the behaviour of LOAD_WITH_ALTERED_SEARCH_PATH isn't defined for relative paths. In practice (on Windows 10) relative paths to Windows system DLLs do work, so that the library is loaded,
but DLLs in other search paths are not found, when this flag is set.
Ruby's fiddle library uses LoadLibrary without flags in both cases.
[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx