Re: LoadLibrary and 5.2

[David Burgess <dabsoft@...>]

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.