Re: [PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.

[Alexandre Julliard]

Martin Storsjo  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.

[PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.

[Martin Storsjö]

On Fri, 28 Aug 2015, Alexandre Julliard wrote:
> Martin Storsjo  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

[PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.

[Alexandre Julliard]

Martin Storsjö  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.