[RFC PATCH v2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.

Martin Storsjö martin at martin.st
Wed Oct 28 03:52:30 CDT 2015

On Tue, 20 Oct 2015, Martin Storsjo wrote:

> 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.
> This DLL is built using only a small subset of the msvcrt source
> files. In particular, the DLL should not use most of the global
> CRT state as a normal msvcrt carries - the only TLS state handled
> is for exceptions.
> The functions in main.c are simplified versions of the corresponding
> ones from msvcrt. Additionally, two stub functions (relating to telemetry)
> are added; they are required for a plain empty exe built with MSVC 2015
> with dynamic C runtime to start up with the builtin vcruntime140.dll.
> Some functions that are available in the full msvcrt, that vcruntime140.dll
> should export, are not included since they haven't been split off to be
> buildable without the full internals of msvcrt yet. Those functions are:
> _CxxThrowException
> __AdjustPointer
> __RTCastToVoid
> __RTDynamicCast
> __RTtypeid
> _chkesp
> _get_unexpected
> Signed-off-by: Martin Storsjo <martin at martin.st>
> ---
> Changed since last version: Moved main-vcruntime.c to the vcruntime140
> directory; skipped the separate memory.c and included all of it in the
> vcruntime main.c instead. Removed a leftover commented out statement.
> In this build configuration, some functions use simpler error handling
> - instead of calling _amsg_exit, it calls ExitProcess directly.
> (_amsg_exit checks the error mode, which is state that lives within
> ucrtbase.dll; vcruntime140.dll shouldn't have a separate copy of that
> state, and there's no function in ucrtbase.dll that would allow quering it.)
> ---
> configure.ac                        |   1 +
> dlls/msvcrt/except.c                |   4 +
> dlls/msvcrt/except_i386.c           |   4 +
> dlls/vcruntime140/Makefile.in       |  12 ++
> dlls/vcruntime140/main.c            | 224 ++++++++++++++++++++++++++++++++++++
> dlls/vcruntime140/vcruntime140.spec |  87 ++++++++++++++
> 6 files changed, 332 insertions(+)
> create mode 100644 dlls/vcruntime140/Makefile.in
> create mode 100644 dlls/vcruntime140/main.c
> create mode 100644 dlls/vcruntime140/vcruntime140.spec

Piotr asked whether this would make sense as a DLL that only forwards 
calls down to ucrtbase, instead of a standalone DLL that duplicates the 

For i386, this DLL has got 81 exported functions, and all of those except 
a few do exist in ucrtbase.dll. The ones that are unique to 
vcruntime140.dll are the following:


Out of these, the telemetry ones actually are called implicitly even in a 
plain hello world executable built with MSVC 2015 (but having them as 
empty stubs seems to work fine so far), the other ones I haven't had 
reason to look into yet.

The real vcruntime140.dll actually also do some calls to ucrtbase.dll 
(linked via the api-ms-win-crt-* stub dlls), but not all the real 
functions - it only links to the following ones:

(Additionally it links to a few symbols from kernel32.dll and one from 

Given this, I still think this DLL makes sense as a standalone DLL instead 
of just a stub forwarding to ucrtbase, since that's what the original one 
does as well. At worst some of the functions may need to have subtly 
different behaviour in different versions (which I guess is the main 
reason for the DLL existing in the first place).

// Martin

More information about the wine-devel mailing list