RE: Lua app crash with mixed DLLs; advice needed

[Thijs Schreijer <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Paul K
> Sent: maandag 11 maart 2013 6:42
> To: Lua mailing list
> Subject: Re: Lua app crash with mixed DLLs; advice needed
> 
> Thanks Owen for the detatils and thanks Thijs for a link to a nice writeup
> on this issue.
> 
> > Whatever the result, it occurs whenever you try to interact with
> > things at the C library/C++ library layer between different DLLs
> > compiled with different runtime libraries on Windows.
> 
> So, what are my options? Why does it seem to work when I use luasocket
> compiled with VS from an application compiled by Mingw? Am I just lucky in
> this case and my luck may run out with a different application or is this
> going to work?

Iirc your case only is when an application is being debugged and it doesn't come with its own version of LuaSocket. This causes the debugger code to load the LuaSocket version distributed with ZeroBrane. And in case of a mismatch it crashes/disfunctions.
So to fix it; you need a LuaSocket dll compiled/linked against the same runtime, but you require no changes for ZeroBrane studio itself or any of the other components.

I don't think there is an easy solution. You could provide a LuaSocket dll for each of the MSVCRT dlls. There are a lot of them, one for each Visual Studio version (the numbered ones), and one for each Windows version (plain MSVCRT.dll)

The user can track what their application uses through Dependency Walker (http://www.dependencywalker.com/) and then install the proper dll. Alternatively they do trial and error.

Obviously would be nice if you could make a dll error/fail/crash at runtime if it detects the wrong runtime (to prevent the accidental 'it seems to work' scenario). Did a short search on that but found nothing on the topic of determining MSVCRT version in use at runtime.

Guess that's why they call it dll-dependency-hell

Thijs