Re: Modify Lua Executable for a -51 option

On Sun, Apr 29, 2018 at 2:07 AM, Viacheslav Usov <via.usov@gmail.com> wrote:

On Sun, Apr 29, 2018 at 6:54 AM, Russell Haley <russ.haley@gmail.com> 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.

I get this..

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.

So do I rename ...\lua5.1\src\lua.c(h) to ...\lua5.1\src\lua51.c(h) as well or is that unecessary? I assume I include ...\lua5.1\src\lua.(h) in ...\lua5.x\src\lua.c?

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.

I only partially understand this. I believe this refers to:

  // resolve function address here
  f_funci funci = (f_funci)GetProcAddress(hGetProcIDDLL, "funci");
  if (!funci) {
    std::cout << "could not locate the function" << std::endl;
    return EXIT_FAILURE;
  }

from https://stackoverflow.com/questions/8696653/dynamically-load-a-function-from-a-dll#8696688

I will need to try to understand why it needs to be static (I'll look that up).

Here is another question the could only be asked by someone ignorant to C nuances: As an alternative to the above, could I just rename each main() to mainL() and make them NOT static, compile the lua.c files into the lua5x.dll and then just call the appropriate mainL from a new lua.c that I write?

Thanks for your help with this!

Russ

Cheers,
V.