On Mon Mar 9 21:20:25 2026 +0000, Jacek Caban wrote:
To elaborate on that, some msvcrt versions export those operators, but modern MSVC provides them in a statically linked form, like this patch does. Cross-module ABI compatibility depends on using compatible versions of these operators in the participating modules. It helps that the actual work is delegated to the C runtime, using the malloc/free allocators and _callnewh for the new handler (although that part would also require something like https://github.com/llvm/llvm-project/pull/150182 on the libc++ side to be fully correct). With this solution, it would not be possible to use Wine built in mingw mode to build C++ code in MSVC mode, or the other way around. We support that for the C runtime, but unfortunately C++ makes it impossible. Then, as Alexandre said, there is little reason to use Winelib in mingw mode. We will still need to support mingw mode for building Wine itself, but there are good open source mingw toolchains available for non-Wine code. An open source solution for MSVC mode is not available, so allowing that with Winelib seems worth it. Yeah, this sounds very reasonable to me. FWIW, I don't really have winelib use cases in mind at all (I barely remember that exists), just about what it means to potential build configurations of wine itself. And that winelib C++ usecases only works for the same build mode as wine itself sounds totally reasonable.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10273#note_131630