RE: LoadLibrary and 5.2

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

  I guess this solution would be fine for me. We already change some
definitions in luaconf.h, one more is much better than editing the source
code.

  Other thoughts about this change?

Best,
scuri

> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
> bounces@bazar2.conectiva.com.br] On Behalf Of David Burgess
> Sent: quarta-feira, 13 de janeiro de 2010 03:23
> To: Lua list
> Subject: Re: LoadLibrary and 5.2
> 
> I have been thinking about this and in summary we have some competing
> requirements.
> We have users who have application structures on WIndows that are
> suited
> to the way loadlib.c currently works and we have users that it does not
> suit.
> There are argumnets for both forms of loading. I think the solution is
> to make LOAD_WITH_ALTERED_SEARCH_PATH a variable or at least  a
> luaconf.h provided option or both of the above.
> 
> POssibly with require() one could implement both forms of loading and
> it
> would be a simple matter to swap from one to the other at run time.
> 
> package.loadlib() would also need a solution.
> 
> However I think that a luaconf.h solution would serve most peoples
> needs, e.g.
> 
> /* define the following if you wish to use the alternate search path
> strategy for DLLs */
> #define LUA_WIN_ALT_PATH 1
> 
> This approach then reduces the argument to which DLL search method
> should be the luaconf.h default.
> 
> David Burgess
> 
> 
> 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.
> >>>
> >