Re: Mixing CRTs on windows

[Ross Berteig <Ross@...>]

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 
design.


> But I have read your MSDN link
> (https://msdn.microsoft.com/en-us/library/ms235460.aspx) and if
> anything, it seems to support my arguments:
>
> > Each copy of the CRT library has a separate and distinct state.
> ....

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 
the winter.

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
> (https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/)
> 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. ;-)

--
Ross Berteig                               Ross@CheshireEng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/
+1 626 303 1602