Am 21.09.2016 um 12:15 schrieb Jerome Vuarand:
> 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.
Please see my mail titled "Mixing CRTs on windows" in this thread
While it may be true for other systems, at least on Windows, multiple
CRTs have to be prepared for side-by-side loading (although I have
verified that only for MSVC. It might indeed be different for MinGW).
> 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.
That is right. If you use luaL_Stream, then you need to use the same CRT.
I agree that mixing CRTs is a bad idea, but technically it should work
for Lua on Windows (except for luaL_Stream, environment variables and
On 9/21/2016 2:44 AM, Christian N. wrote:
> Am 21.09.2016 um 01:33 schrieb Thijs Schreijer:
>> 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…
In my (too) long experience with Windows starting with Windows 3.0 as a
developer and Windows 2.0 as a casual user, this is what happens.
Periodically there are efforts to improve the situation. Sometimes
things even get peaceful for a while. But then something breaks and it
is very difficult to debug.
> First, even though I argue that in the case of Lua, there is no problem
> with mixed CRTs, I do so mostly on theoretical grounds (though I did
> have success mixing a small MSVC 2015 executable and the MSVC 2013 Lua
> DLL). I do not recommend mixing CRTs if at all possible.
For released products not mixing CRTs is the only sane answer. If you
are building a product top to bottom, just don't do it.
Use DEPENDS.EXE (delivered with VS, newer versions from its developer at
their web site) to see what DLLs are actually loaded to make sure you
did it right. Don't fret too much when one official CRT loads another,
that has often been the case, and should generally be assumed to be by
True, but there is a case that is being overlooked: namely accidentally
loading more than one build of the Lua interpreter. That is almost
certainly a pathway to madness.
If you use the Lua 5.1 distributed as Lua for Windows which is entirely
linked to one version of the CRT, and then add a module you compile
yourself linked to another, you might be ok if you successfully keep all
CRT property isolated.
But when you load a module that has a different build of Lua linked,
possibly as a result of frustration when trying to get your module to
build at all, you will have trouble. The most obvious source of trouble
(that has a really really really obscure symptom) results from the fact
that the value `nil` is at the core a singleton static data structure in
the Lua core. When there are two Lua cores, `nil` from core A is not the
same as `nil` from core B and all kinds of strange things will happen.
The problem is not that it will fail.
The problem is that it will seem to work. Until it fails.
We've had long threads on debugging this kind of problem on this list in
the past. In the long run, having multiple DLLs loaded that "do the same
thing" often leads to very mysterious symptoms that only happen when the
perfectly working application is demonstrated before upper management,
your most important customer, or left in Antarctica to gather data over
Although this tread has been implicitly discussing the issue from the
Windows point of view, this can happen in *nix land too. There, the
usual cause is static linkage when dynamic should be used, and usually
not the result of multiple CRTs because having more than one is not a
common configuration in *nix.
> Tangetially related: With the ucrtbase.dll since Windows 10 / VS 2015,
> the operating system becomes a CRT delivery channel again (cf. the
> oldnewthing blog article mentioned previously in this thread). This CRT
> is announced to be stable across major VS versions
> and will thus hopefully tame the Windows CRT jungle.
I've been hearing promises to tame DLL Hell since shortly after Windows
was born. I sure hope it happens someday. At least from what I've read
about the recent promise to "fix" the CRT, it does sound like a group at
MS has taken ownership of that specific niche of the problem and has a
plan that might succeed. Until it fails. ;-)
On Wed, Sep 21, 2016 at 2:46 PM, Ross Berteig <[hidden email]> wrote:
> Although this tread has been implicitly discussing the issue from the
> Windows point of view, this can happen in *nix land too. There, the usual
> cause is static linkage when dynamic should be used, and usually not the
> result of multiple CRTs because having more than one is not a common
> configuration in *nix.
Until you have to update glibc. >.> I remember going from libc5 to
libc6. THAT was an adventure. The typical advice was "make a backup,
blow away your system, and install fresh."
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…
In my (too) long experience with Windows starting with Windows 3.0 as a developer and Windows 2.0 as a casual user, this is what happens. Periodically there are efforts to improve the situation. Sometimes things even get peaceful for a while. But then something
breaks and it is very difficult to debug.
An alternative (and shameless plug) would be to use the Lua module `pe-parser`  (this is a Lua list after all).