Re: Module loading on Windows

[Ignacio Burgueño <ignaciob@...>]

Hisham wrote:

> >  If an lrexlib rock installs pcre.dll into the same directory as
> > rex_pcre.dll, then the rock is wrong! pcre.dll should be either somewhere on
> > Windows PATH, or in the directory where lua.exe resides.
>
> Correct. External libraries are, well, external to LuaRocks. On Unix
> we use { "/usr/local", "/usr" } as default value for the
> external_deps_dirs in the config file, but on Windows (since there is
> no default place to look for development libs and headers) one should
> either set this value by hand in the config file or pass the location
> of external deps in the LuaRocks command line. On runtime, we rely on
> the standard Windows rules for loading libraries. LuaRocks will inform
> if it can't find the external dependency on installation, but it is
> not its task to provide it.


Well, I'm not saying that LuaRocks should deal with external 
dependencies in that way. My point is that deploying any library to a 
directory accessible by the PATH variable can break other applications.
Also, I'm talking about Windows here. I don't know how Unix deals with 
this issues.
Using the PATH as a way of locating shared libraries is way too fragile. 
http://en.wikipedia.org/wiki/DLL_hell


See, an application A uses libFoo 1.0.0 and registered itself in the PATH.
PATH=c:\applicationA

Now I install a rock that has a C library, which uses libFoo 2.0.0. Both 
versions are known to be incompatible, hence the change in its major 
version number. Both are named the same.

Ok, let's copy libFoo 2.0.0 somewhere in the path.
PATH=c:\applicationA;c:\myPathForDlls

Now, application A will continue to work, but surely my rock won't.
Ok, instead of appending ourselves to the path, let's prepend.
PATH=c:\myPathForDlls;c:\applicationA

Now, I broke application A.

A way to avoid breaking other applications is to not mess with the 
environment. So, keep the C library together with its dependants (libFoo 
2.0.0). Here I agree fully with what Shmuel just said, that if an 
application is concerned with a particular DLL version, it should 
install it in the same directory.

The other way on Windows is Side-by-side installations, but let's not go 
in there...

To recapitulate, what would be the drawback of using LoadLibraryEx with 
altered search path instead of LoadLibrary since require is using full 
path names?

Regards,
Ignacio Burgueño