Re: work3 - searchpath

[David Burgess <dburgess@...>]

I thought some more about this and with win32  IMHO the way to check for a
existence of a DLL is to simply use LoadLibrary() or LoadLibraryEx().
The logic being that once we find a DLL we are going to load it anyway.

I also think that the package.cpath logiic is not quite right for Windows.

a) The cpath that I tried used in testing is simply "?". I wrongly assumed 
that this would enable the default windows search strategy.However, the 
searchpath() will not find what  LoadLibrary() will.

b) The LoadLibrary() does not require an extension. LoadLibrary("socket") will
look for a file named "socket.dll". Hence, the cpath substution for the 
suffix would be redundant.

c) If we assume that the package implementor (me) wishes to use the 
default windows search strategy, and we assume that when deploying an
application I would like to place all DLLs in s single directory then 
a non-pathed LoadLibrary() works well. The first point of search for
LoadLibrary is the directory of the module that loaded it. 
This is probably the simplest (and most common) directory layout
for Windows apps, this does not require searchpath(). 

d) dotted names.
e.g. require"socket.udp"
Rather than forxe the deployer to create yet another DLL what do you
think of the idea that this should simply reference a different entry
point in the same DLL.

Thus when package.cpath == "" or NULL

require"socket"
translates to
LoadLibrary("socket")
GetProcAddress(h,"luaopen_socket")

require"socket.udp"
translates to
LoadLibrary("socket")
GetProcAddress(h,"luaopen_socket_udp")

If a separate DLL is required for udp then the entry point luaopen_socket_udp
could load it.


In summary I am asserting that package.cpath should be a set of *optional*
paths that loadlib() will search thru. No cpath then no (lua) searching.

LoadLibrary() without a path does (roughly) the 
"%moduledir%/?.dll; ./?.dll; %systemroot%/system32/?.dll; 
%systemroot%/?.dll; %all directories in path%/?.dll

It is not possible to craft the same effect with CPATH.

My last issue is with LUA_POF (luaconf.h). While this is a fair default
there exists a compatibility issue with many existing libraries (like Luiz's)
which presume that the dll name is prefixed with an "l". This raises
question of whether LUA_POF should be in the environment or in the 
package table? 

DB