Re: Proxy DLL for Lua 5.1; can't get it to work with statically linked liblua

[Paul K <paulclinger@...>]

Hi Jerome,

> Simply specify your exe name (you probably need the .exe extension,
> but try without) as the "reallib" argument. The DLL loader just use
> that string as a module name, and it will correctly find the exe that
> is already loaded in the process memory with that name.

I tried that, but I got exactly the same error when I tried then to
load a module linked to that proxy: "The procedure entry point
lua.luaL_argerror could not be located in the dynamic link library
lua51.dll." (this is when I specify "lua" name). When I specify
'lua.exe', I get "The procedure entry point lua.exe.luaL_argerror
could not be located in the dynamic link library lua51.dll." I also
tried specifying "lua.exe" with and without quotes in the .def file
(luaL_addlstring=lua.exe.luaL_addlstring), but with the same effect.

Paul.

On Wed, Nov 27, 2013 at 2:21 AM, Jerome Vuarand
<jerome.vuarand@gmail.com> wrote:
> 2013/11/27 Paul K <paulclinger@yahoo.com>:
>>> Did you try http://lua-users.org/wiki/LuaProxyDllThree ? The main
>>> advantage is that it produces a DLL with no code, only metadata for
>>> the Windows DLL loader, so there is less chance of a crash. Also it
>>> produces a very tiny file, if size matters to you.
>>
>> Yes, I'm familiar with ProxyDllThree as I'm using it to support LfW
>> modules that depend on Lua5.1.dll (which proxies requests to my
>> Lua51.dll). In this case I need to proxy the requests to a statically
>> compiled lua.exe and it seems like this method only proxies calls to a
>> dll.
>
> No, you can use this method. Executables and DLLs on Windows use the
> exact same file format. Actually executables with exported symbols are
> a kind of hybrid of the two made possible by that common format.
> Simply specify your exe name (you probably need the .exe extension,
> but try without) as the "reallib" argument. The DLL loader just use
> that string as a module name, and it will correctly find the exe that
> is already loaded in the process memory with that name.
>