lua-users home
lua-l archive

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

I agree with you Mike. I have tested this on XP SP2. It behaves as per
the documentation. I cannot reproduce the error.
However, it is possible to create a LUA_CPATH that would be non-intuitive
in its behaviour. The default works fine for me.
When Roberto first implemented the current scheme I tested it under NT4,
W2K and XP and it behaved consistently. By constrast
LOAD_WITH_ALTERED_SEARCH_PATH methinks only confuses the already
nightmarish search path. It is also worth noting that the OS providers
take great
joy in changing the search path across releases and service packs.
For those who do use non-path filenames in their LUA_CPATH e.g. "abc.dll"
there is a significant performance overhead (>2 orders of magnitude) in
allowing windows to scan the serach path. The current qualified path scheme
is very quick.

In summary the current Lua implementation methinks is relatively safe from
both OS and registry changes.

David Burgess

Mike Pall wrote:

Hi,

cloudwu wrote:
> LoadLibrary will load dll in system directory before current
> directory by default settings.

Quoting MSDN (emphasis mine):
  "If the string DOES NOT SPECIFY A PATH, the function uses a
  standard search strategy to find the file."

But Lua always specifies a path (i.e. a string containing a
backslash) when using require.

> For example, I create a C module named console.dll and put it in
> my current directory.

You need to put it into the directory where lua.exe is stored.
This may or may not be the current directory. See the search path
order at the beginning of luaconf.h or 'print(package.cpath)'.

> require "console" In lua, it failed.
> lua load the console.dll in windows\system32 instead of my
> .\console.dll .

This is strange and shouldn't happen according to the MSDN docs.
Well, unless you've stored lua.exe in windows\system32 ... (don't!)

Can anybody else reproduce this? Which of the package.cpath
components causes this? IMHO ".\\?.dll" should not trigger the
standard search strategy according to the docs.

Bye,
     Mike