[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: LoadLibrary and 5.2
- From: "Antonio Scuri" <scuri@...>
- Date: Tue, 12 Jan 2010 12:00:40 -0200
In Lua for Windows there is only one subdir called clibs where all DLLs
> -----Original Message-----
> From: email@example.com [mailto:lua-
> firstname.lastname@example.org] 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
> Antonio Scuri wrote:
> > Hi David,
> > I understand what you are saying but the main motivation for the
> > 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
> > must also be found. And this is NOT handled by the package.cpath. Lua
> > Windows has lots of these DLLs that are NOT modules. That's the only
> > 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
> > Thanks,
> > scuri
> >> -----Original Message-----
> >> From: email@example.com [mailto:lua-
> >> firstname.lastname@example.org] 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
> >> be
> >> controlled by the environment variable LUA_CPATH. The default value
> >> "!\\" 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
> >> allowing windows to search for a DLL (by just using a file name).
> >> is also compatible with Microsofts recommendation of where to put
> >> application DLLs (WRT the executable) , <QUOTE>It is good practice
> >> 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,
> >> that the standard search strategy and the alternate search strategy
> >> specified by LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH differ
> >> just one way: The standard search begins in the calling
> >> 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
> >> LUA_CDIR and/or LUA_CPATH to *not* use absolute path loads.
> >> MS have change the search strategy with different OSs and indeed
> >> 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
> >> 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 <email@example.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
> >>> to see this change being made as well - I've been using it for some
> >>> time for myself.