Re: LuaRocks with Windows/Visual Studio

["Paul Moore" <p.f.moore@...>]

2008/9/5 Thomas Harning <harningt@gmail.com>:
> Has anyone thought of writing a proxy DLL of sorts for the MSVCRT?  One
> could one that meets some least-common-denominator and everyone links
> against it.

I'm not sure how that would work. The main program determines the CRT
in use - only that CRT gets its "process startup" initialisation code
(if any) run. So embedded lua and any modules it uses has to either
use that CRT, or use a CRT which doesn't need startup code (and be
careful not to mix CRTs in any way). The problem is that not all
applications use the CRT (a real-life example: JPSoft's 4NT/Take
Command does not use the CRT at all, and so my Lua plugin cannot use a
CRT which needs initialisation code to run).

Based on my experimentation, MSVCRT80 crashes if it isn't "initialised
properly" - which I guess means it has crucial startup code. I guess
the same is likely true of MSVCRT90.

The original MSVCRT doesn't crash. This either means it doesn't have
any required startup code, or that I haven't found the problem yet :-)

Ultimately, this basically means that Lua can't actually rely on
having any fully-initialised CRT available. But for all practical
purposes, if you either (1) link with the CRT used by the main
application, or (2) use MSVCRT, you don't seem to hit issues.
Unfortunately, later MS compilers have no option to link with the
older CRT, so that there is no universal solution.

> This could be the way to kill this MSVCRT dumbness once and for all (well,
> testing new versions of MSVCRT w/ your app would be preferable)....

There has been talk of writing a library of precisely the CRT
functions Lua needs, and distributing that. For functions like the
various string and maths functions, there is clearly no dependency on
static data, so no initialisation issues can arise. Whether memory
allocation or IO can be done this way is a little less obvious.

Paul.