[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.
From:       Martin_Storsjö <martin () martin ! st>
Date:       2015-08-31 20:51:05
Message-ID: alpine.DEB.2.02.1508312322490.6942 () cone ! martin ! st
[Download RAW message or body]

On Fri, 28 Aug 2015, Alexandre Julliard wrote:

> Martin Storsjo <martin@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


[prev in list] [next in list] [prev in thread] [next in thread]