Re: [PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.
Martin Storsjo <martin(a)martin.st> writes:
Since MSVC 2015/Windows 10, the C runtime has now been split into two parts, ucrtbase, which is the generic C runtime which is now considered a system component, and vcruntimeX which is specific to the compiler version.
Even if this DLL only has a fraction of the functions of the full msvcrt/ucrtbase, it still requires almost all the object files from msvcrt.
It would be better to isolate the corresponding code so that we don't need all the files. -- Alexandre Julliard julliard(a)winehq.org
On Fri, 28 Aug 2015, Alexandre Julliard wrote:
Martin Storsjo <martin(a)martin.st> writes:
Since MSVC 2015/Windows 10, the C runtime has now been split into two parts, ucrtbase, which is the generic C runtime which is now considered a system component, and vcruntimeX which is specific to the compiler version.
Even if this DLL only has a fraction of the functions of the full msvcrt/ucrtbase, it still requires almost all the object files from msvcrt.
It would be better to isolate the corresponding code so that we don't need all the files.
That would indeed be the best. For some functions (like memcmp/memcpy/memmove/memset and such) it's pretty straightforward, but for others it does pull in most of the internals of the msvcrt implementation. One example: _purecall and _set_purecall_handler (currently implemented in exit.c). The _purecall implementation uses _amsg_exit which in turn uses _cprintf (console.c), _MSVCRT_app_type (data.c) and DoMessageBox, which uses _MSVCRT_mbstowcs (mbcs.c). Second example: MSVCRT__get_unexpected (cpp.c), using msvcrt_get_thread_data (thread.c), which uses MSVCRT_locale (locale.c). So unless it's a really simple function, it ends up pulling in most of the msvcrt internals. For the real implementation, I'd guess it uses most things from ucrtbase, instead of having a separate full crt state within both DLLs. But I'm not sure I'm ready to take on such a challenge. // Martin
Martin Storsjö <martin(a)martin.st> writes:
So unless it's a really simple function, it ends up pulling in most of the msvcrt internals.
For the real implementation, I'd guess it uses most things from ucrtbase, instead of having a separate full crt state within both DLLs. But I'm not sure I'm ready to take on such a challenge.
That's another reason for avoiding it. Since applications will most likely use both, you can't duplicate the implementation. You'll need vcruntime to import ucrtbase somehow. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Martin Storsjö