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

[Paul K <paulclinger@...>]

Hi All,

> Proxy dll is used when you statically linked liblua into your application's
> exe file, but you want to load pre-built third party C modules, which are
> linked against a dll file.

I'm trying to get a proxy DLL to work with a statically compiled Lua
5.1 interpreter (mingw on Windows 32) with a library that is compiled
against lua51.dll

I tried to use ProxyDll2 (http://lua-users.org/wiki/LuaProxyDllTwo),
both Shmuel's and David's solution, but I guess I did something wrong
as the process hangs after "require 'winapi'" (winapi is the library
I'm "practicing" on). Everything works with a "normal" interpreter
that is linked against lua51.dll.

I also tried ProxyDll4 (http://lua-users.org/wiki/LuaProxyDllFour),
but in that case I get a crash with "access violation" error in
lua.exe, which doesn't tell me much.

Does anyone have a working DLL (or instructions for it) that works
with this setup?
- lua.exe (statically compiled; 191065 bytes in my case)
- lua51.dll (proxy dll)
- winapi.dll (or any other DLL compiled against lua51.dll)

I also tried with statically compiled LuaJIT (instead of lua.exe), but
the result is exactly the same. All executables/binaries are compiled
on the same machine with the same setup using mingw with one
exception: some proxy DLLs requires VS and I used VS 2008 for it.

Paul.

On Sat, Nov 9, 2013 at 7:58 PM, Peng Zhicheng
<pengzhicheng1986@gmail.com> wrote:
> 于 2013-11-8 15:01, Paul K 写道:
>
> Thank you Peng and Liam.
>
> One more question about proxy DLLs. I'm looking at proxy DLL 4 by Paul
> Moore [1] that allows proxying calls for lua51.dll to statically
> linked interpreter (it will probably work with lua52.dll, but I
> haven't tested that yet). Unfortunately, it's using VS compiler and I
> have everything else compiled using mingw.
>
> It includes this comment "The MSVC compiler (as __declspec(naked) is
> only supported by MSVC). I am working on finding an equivalent in
> Mingw, so that an all-Mingw approach is possible." I did find an
> alternative to __declspec(naked) in mingw ([2]), but don't understand
> some of the elements involved to update the current script to work
> using this method.
>
> Do I need to try to come up with mingw alternative or maybe mixing VS
> and gcc-compiled libraries is not an issue in this case as the proxy
> DLL doesn't do any memory allocation or anything else that may be
> potentially harmful [3]?
>
>
> According to my experiences, mingw recognize library file produced by MSVC
> just fine,
> as long you do it right. The key is to get the proper IMPORT library for
> mingw to use.
>
> To do this, you need 'dlltool', included in the mingw distribution. For
> detailed guidelines,
> see [1].
>
>
> Also, since all the DLLs does is call forwarding, are there any issues
> I may run into if I combine exports from Lua51.dll and Lua52.dll and
> create one proxy DLL that works for both versions (as a s uperset of
> all the calls that need to be forwarded)?
>
>
> Well, I've no idea about what your configuration is. But I guess you'd
> better not do it.
>
> Proxy dll is used when you statically linked liblua into your application's
> exe file, but
> you want to load pre-built third party C modules, which are linked against a
> dll file.
>
> Since a C module is built just for one specific version of Lua, you don't
> need a dll
> that forwards both 5.1 and 5.2 of Lua. Just build two dlls, one for each
> version.
>
> Besides, Lua 5.1 and 5.2 contains incompatible APIs, I don't take it as a
> good idea
> to make a "superset" of both version.
>
> -------------------------------------------------------------------------------------------------------------------
> [1] http://www.mingw.org/wiki/CreateImportLibraries
>