RE: LoadLibrary and 5.2

["Antonio Scuri" <scuri@...>]

  In Lua for Windows there is only one subdir called clibs where all DLLs
are placed.

Best,
scuri

> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
> bounces@bazar2.conectiva.com.br] On Behalf Of David Burgess
> Sent: terça-feira, 12 de janeiro de 2010 11:29
> To: Lua list
> Subject: Re: LoadLibrary and 5.2
> 
> Just so I got this problem right we have -
> 
> luadir -
>    - C module dir A which contains a C module DLL
>      - subordinate DLLs  which contain DLLs that A is dependent upon
>    - C module dir B which contains a C module DLL
>      - subordinate DLLs  which contain DLLs that B is dependent upon
>    - C module dir C which contains a C module DLL
>      - subordinate DLLs  which contain DLLs that C is dependent upon
> 
> Yes?
> DB
> Antonio Scuri wrote:
> >   Hi David,
> >
> >   I understand what you are saying but the main motivation for the
> change
> > was NOT to find modules, it was to find DLLs that the modules depend
> on and
> > that are not Lua modules.
> >
> >   For example, iuplua depends on iup. When iuplua is required the iup
> DLL
> > must also be found. And this is NOT handled by the package.cpath. Lua
> for
> > Windows has lots of these DLLs that are NOT modules. That's the only
> reason
> > the Lua for Windows installation must change the PATH so these DLLs
> can be
> > found in the "clibs" subfolder.
> >
> >   Is there any other solution to this problem despite changing
> LoadLibrary?
> >
> > Thanks,
> > scuri
> >
> >
> >> -----Original Message-----
> >> From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
> >> bounces@bazar2.conectiva.com.br] On Behalf Of David Burgess
> >> Sent: terça-feira, 12 de janeiro de 2010 09:11
> >> To: Lua list
> >> Subject: Re: LoadLibrary and 5.2
> >>
> >> Answering you query ther are a lot more posts from Lua 5.0, onwards
> >> methinks.
> >>
> >> At the risk of the discussion starting all over again...
> >>
> >> The current strategy (I believe) is that Lua loads DLLs from a known
> >> set
> >> of locations which is in effect controlled by package.cpath which
> can
> >> be
> >> controlled by the environment variable LUA_CPATH. The default value
> is
> >> "!\\" which expands to the executable directory path.
> >>
> >> The strength of this approach is that Lua DLL loads are by default
> >> loads
> >> from an explicit path, this is multiple orders of magnitude faster
> than
> >> allowing windows to search for a DLL (by just using a file name).
> This
> >> is also compatible with Microsofts recommendation of where to put
> your
> >> application DLLs (WRT the executable) , <QUOTE>It is good practice
> to
> >> install application DLLs in the same directory that contains the
> >> application</QUOTE>ref:
> >> http://msdn.microsoft.com/en-us/library/ms682600%28VS.85%29.aspx.
> >>
> >> Again to quote MS from
> >> http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx,
> "Note
> >> that the standard search strategy and the alternate search strategy
> >> specified by LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH differ
> in
> >> just one way: The standard search begins in the calling
> application's
> >> directory, and the alternate search begins in the directory of the
> >> executable module that LoadLibraryEx is loading."
> >>
> >> This means that with the way loadlib.c currently works the only time
> >> when LOAD_WITH_ALTERED_SEARCH_PATH would have an effect is when your
> >> executable and DLLs are in different directories and one has
> modified
> >> LUA_CDIR and/or LUA_CPATH to *not* use absolute path loads.
> >>
> >> MS have change the search strategy with different OSs and indeed
> with
> >> service packs, as it stands Lua has been immune to this hackery.
> >>
> >> Of the requests for change that I have read it would seem that the
> >> solution is not to use LOAD_WITH_ALTERED_SEARCH_PATH but to change
> or
> >> add a path to the default package.cpath.
> >>
> >> In choosing the best solution I note that DLL redirection and
> >> manifests/assemblies complicate the Windows scene.
> >>
> >> So maybe the solution to keep more people happy is to set the
> >> package.cpath default to something like:
> >>
> >> ".\\?.dll;"  LUA_CDIR"?.dll;" LUA_CDIR"\dll\?.dll;"
> >> LUA_CDIR"loadall.dll"
> >>
> >> or my preference is to use absolute paths
> >>
> >> LUA_CDIR"?.dll;" LUA_CDIR"\dll\?.dll;" LUA_CDIR"loadall.dll"
> >>
> >>
> >> Finally a question, does anyone have a Windows SxS assembly for a
> Lua 5
> >> DLL using VS2008?
> >>
> >> DB
> >>
> >> Theodor-Iulian Ciobanu wrote:
> >>> On Tue, 12 Jan 2010 08:36:30 +1100
> >>> David Burgess <dabsoft@gmail.com> wrote:
> >>>
> >>>> Sometime ago some powerful arguments for no change were placed on
> >> the
> >>>> list. I believe the arguments are still valid.
> >>> These were the arguments I found so far:
> >>> http://lua-users.org/lists/lua-l/2008-05/msg00397.html
> >>> http://lua-users.org/lists/lua-l/2008-08/msg00618.html
> >>>
> >>> But maybe I haven't searched the archive deep enough because I'd
> like
> >>> to see this change being made as well - I've been using it for some
> >>> time for myself.
> >>>
> >