Somehow, that clarification doesn't do much to improve my clarity. On Fri, Mar 25, 2016 at 7:49 PM, Ray Donnelly <[email protected]> wrote: > On Fri, Mar 25, 2016 at 11:34 PM, Óscar Fuentes <[email protected]> wrote: >> Matt Breedlove <[email protected]> >> writes: >> >>> DLLs load from the system32/wow64 directory first *regardless* of any >>> PATH variables. This was a prior problem I experienced with python >>> being built and there having been openssl dlls within my system >>> directories. It has nothing to do with the path variable. This is >>> documented behavior on MSDN and requires a system call to change the >>> search paths. Ray is correct, although I typically use procmon from >>> the SysInternals Microsoft suite and just filter for dll paths. If >>> you have a dll with the same name as the one a process is trying to >>> load within system32/SysWOW64, it will override any dlls that might be >>> present within PATH. >>> >>> Here's the URL that describes the behavior: >>> >>> https://msdn.microsoft.com/en-us/library/7d83bc18.aspx >>> >>> Because his zlib.dll file for msys2 doesn't reside in the same >>> directory that conftest.exe is being compiled in, Windows will search >>> the system directories first and then progress along the PATH >>> directories. This is unless a specific call is made to change that >>> behavior (which it is not). >> >> My point was that Ray's comment could be interpreted as saying that >> having *any* foo.dll on your system and a process that uses it implies >> that you will have problems if your application comes with its own >> foo.dll. >> >> If you place your foo.dll along the rest of the binaries of your >> application, you are safe, no matter how many other foo.dlls you have >> around on your system. >> >> I'm sure that Ray knows this, but as the discussion progressed some >> context was lost and on the final messages it is not obvious that the >> problem is related to relying on PATH for locating zlib.dll and having >> other zlib.dll on the Windows system directory. >> >> There is much confussion with dlls on Windows and I've met many >> programmers who hold the weirdest ideas about it (as demonstrated by the >> other response to your message.) >> > > Hi Óscar, > > From MSDN: > > https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx > > "If a DLL with the same module name is already loaded in memory, the > system checks only for redirection and a manifest before resolving to > the loaded DLL, no matter which directory it is in. The system does > not search for the DLL." > >> >> ------------------------------------------------------------------------------ >> Transform Data into Opportunity. >> Accelerate data analysis in your applications with >> Intel Data Analytics Acceleration Library. >> Click to learn more. >> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 >> _______________________________________________ >> Msys2-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/msys2-users > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 > _______________________________________________ > Msys2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/msys2-users
------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
