Re: Running Lua from within a Window Program

[Thijs Schreijer <thijs@...>]

> On 20 Sep 2016, at 15:12, Christian N. <cn00@gmx.at> wrote:
> 
> Am 20.09.2016 um 15:01 schrieb Viacheslav Usov:
>> On Tue, Sep 20, 2016 at 2:42 PM, Christian N. <cn00@gmx.at
>> <mailto:cn00@gmx.at>> wrote:
>> 
>>> I thought of setjmp/longjmp too but the setjmp (pcall) and longjmp
>> (error) both happen in the same Lua DLL.
>> 
>> That does not matter. The problem in question is Lua built for runtime A
>> but is executed with runtime B. In runtime A, the size of jmp_buf is a;
>> in runtime B the size is b, and it may be possible that a != b. Then, if
>> a < b, runtime B's setjmp called by Lua will cause a buffer overrun, or,
>> if a > b, runtime B's longjmp will not restore some of the state
>> required by Lua compiled for runtime A.
>> 
>> Secondly, setjmp, being a macro in either A or B or both, may do
>> something not compatible with the other runtime's longjmp even if a == b.
>> 
>> Cheers,
>> V.
> 
> Of course if a binary was compiled against CRT A but is dynamically linked against CRT B then all bets are off.
> 
> But normally incompatible runtimes will have different DLL names (msvcr110.dll, msvcr120.dll, etc.). Thus when you compile a DLL against CRT A and your executable against CRT B then both CRTs will be loaded at runtime and the DLL and the main executable will both use their own ones independently.
> 
> ‒ Christian
> 

This is simply not true, read up on the MSDN link I send earlier in the thread, where Microsoft discusses the potential problems of using multiple runtime (don’t take my word for it, better take theirs, they wrote the stuff).

Repeating; mixing runtime ‘seems’ to work, until it doesn’t. You’ll get sporadic and hard to trace crashes. Search the archives, plenty of others went before you…

Thijs