If it's really a c++ feature issue, it would make sense if they checked msvcp140.dll instead. Setting arbitrary version without understanding what's the problem was is not great, do we have this issue in our msvcp140? Does it correspond to newer or older behavior?
I mean everything I found is for C++, this doesn't necessarily mean C is unaffected. Regarding our lib, it seems to me that is using the previous abi, but I'm not sure, as I don't know what kind of breakage that change does. Note that this is a tangential matter, as this change was introduced way after 14.29
And if this is in fact a problem that's not fixable at application side, e.g. by never using constructs that supposedly cause the issue
An application that doesn't use the problematic code (in this case mutexes) won't be affected by the change.
"correct" way seems to me is to bundle crt modules of a matching version. Or asking user to install updated redist package.
We could do that, but wouldn't this loose the point of shipping it inside wine? And for what I can see PHP works with this change, barren a problem with traversing the mount points (and symlinks with the junction patchset), without the need to actually using a native version of the runtime. It seems also it's one of the few applications making this kind of check. And imho, if the windows runtime get updated, it should be responsability of the wine project to make the wine implementation conformant again (excpecially if we have now a guarantee of forward compatibility).