Re: msvc*.dll versioning conflicts

[David Manura <dm.lua@...>]

Paul Moore writes:
> ...My guess is that this [crashing] is because
> msvcr80 expects to have had some initialisation done at application
> startup time, which isn't done when it's loaded as part of a DLL load
> (the embedded Lua).

The CRT normally defines a function that initializes the CRT and then
calls the usual main/WinMain (in an application) or DllMain (in a DLL)
entry point defined by the user.  The linker typically sets this CRT
initialization function to be the *real* entry point of the module
(which the operating system calls upon loading it).  Normally the
toolchain hides this from the user, though it's often seen in the
debugger.  However, if you set your own entry point, then it's
possible the CRT won't be initialized.  There's articles on the web
concerning the CRT initialization process.

> On 05/08/2008, David Manura wrote:
> > Though it's quite preferable to use the same C runtime, in theory
> > I see nothing
> > incorrect with mixing libraries linked against different C runtimes
> > provided some strong assurances are given from those libraries.
> 
> But isn't the whole issue that MS don't *give* such assurances???

Microsoft's behavior is fairly clear in [1].  I was rather referring
to Lua C extension modules (e.g. LuaZIP), any C libraries they depends
on (e.g. zziplib), and even lua51.dll.  It's currently rare in
practice for such modules to make any claims in their documentation as
to what extent they are safe to mixing CRTs.

> >  Perhaps it's ideal, *when possible*, for a C extension DLL to
> > dynamically link to
> > no C run-time at  all (i.e. /nodefaultlib /entry:... linker options
> > in MSVC).  It may
> > be worthwhile for someone to clarify this all in practice.
> 
> Possibly, but Lua needs a C runtime from somewhere. Statically linking
> it doesn't help, and dynamic linking needs something.

An example with comments about building a Lua C extension module with
no CRT (as well as mixing CRTs) has been added to [2].  Obviously Lua
itself needs to link against a CRT...unless you rewrite Lua to use
only operating system API calls (any takers? ;) ).  However, there are
likely many cases where C extension module need not link directly to
any CRT.

[1] http://msdn.microsoft.com/en-us/library/ms235460.aspx
[2] http://lua-users.org/wiki/BuildingModules