lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

I will sleep on it.

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.