Re: Running Lua from within a Window Program

[Jerome Vuarand <jerome.vuarand@...>]

2016-09-20 15:01 GMT+01:00 Christian N. <cn00@gmx.at>:
> Am 20.09.2016 um 15:28 schrieb Viacheslav Usov:
>>>
>>> But normally incompatible runtimes will have different DLL names
>>> (msvcr110.dll, msvcr120.dll, etc.).
>>
>>
>> In the case of MinGW, they will not. It always links to the DLL named
>> msvcrt.dll, which is not even supposed to be linked to except by the
>> OS's own components [1].
>>
>> Cheers,
>> V.
>>
>> [1] https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273
>
>
> I fail to see how this is a problem. If I link my MSVC-compiled program with
> a MinGW-compiled lua53.dll, I might get the following dependency tree (swap
> msvcrt.dll with msvcr120.dll for the reverse case):
>
>   myprogram.exe
>   ├───lua53.dll
>   │   └───msvcrt.dll
>   └───msvcr120.dll
>
> Two runtimes are loaded independently, as described before.

C runtimes are not just a bunch of clean C functions using only stack
memory. Some might expect their main wrapper to have been called to
initialize some globals and will break if the exe was linked to
something else. Some might use thread-local storage in different ways,
and overwrite each other's memory.

But even with two nice and clean runtimes, the Lua 5.3 API has a FILE*
in luaL_Stream (I was under the impression that older Lua version had
some FILE* too, but I can't find them now). If your program creates
some of these, or if binary modules access some of Lua's own streams,
you need to make sure every party involved agree on what FILE*
pointers point at.