lua-users home
lua-l archive

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

On Sun, Apr 29, 2018 at 2:07 AM, Viacheslav Usov <> wrote:
On Sun, Apr 29, 2018 at 6:54 AM, Russell Haley <> wrote:

> At first I thought to write a wrapper. And then I thought, "Well, fuck, it's just a tiny C program. How complicated can it be"? (tee hee) The most portable and performant way to handle configuration is in C. In the end, modifying Lua itself seems like the best approach?

If all you want is really a Lua interpreter that loads either lua51.dll or lua5x.dll based on a command line switch, then you could exploit the fact that lua.c defines everything except main() as static. You can therefore take both versions of lua.c, rename their main() functions to main51() and main5x() respectively. So now you can have two versions of lua.c compiled into one executable. Note you will also need two full sets of Lua's headers to make that work.

That only solves part of the problem, because you still need to load the appropriate DLL dynamically (easy) and make sure that all the API calls by main51() and main5x(), and the functions called by them,are routed to the correct DLL. A first step toward that goal would be not linking your executable against any luazx.dll, then all the API calls will result in linker errors, giving you a list of API functions used by both versions.

The next step is ugly, and perhaps there is a more elegant way (of which I will be happy to hear). For each API call in a given lua.c, modify its declaration in the corresponding lua.h. For example, the .1 version calls lua_newstate(), which is defined as

LUA_API lua_State *(lua_newstate) (lua_Alloc f, void *ud);

Modify that to read

static lua_State *(*lua_newstate) (lua_Alloc f, void *ud);

That creates a static pointer to function. Once you have done all that properly, your executable should link successfully, but it will crash when run, because all those pointers need to be set up with the addresses of the corresponding API functions resolved from the dynamically loaded DLL. I think you should be able to fill in the gaps at this point.


Thanks V. I'll study this idea.