api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
Here's a little more info on these mysterious files.
These (and more) are what Microsoft calls
API Sets. Vortex called them forwarders,
and he's not wrong about that, but its better to think of them as proxies to the actual
functions contained in the UCRT.
Api Sets help abstract the actual implementation, ensuring that different versions
of Windows provide the same function interface. Kind of like a COM Interface, if you
look at it sideways. So, besides routing function calls, the Api Sets are sensitive to the
version of Windows that the calling apps are running on.
That right there tells me it's wise to
not avoid them.
When Microsoft add new features or bug fixes to the UCRT, they could change the actual
coding of one or more runtime functions. But it is the API Sets that mostly eliminate the
need to recompile apps that are tied to UCRT functions. The version of the API Sets that are
tied to an app stays the same (apparently embeded in the app's executable). Windows will
direct function calls to the correct version of UCRT. (I suppose that's true, as long as the
required UCRT version is installed on the machine that needs it.)
So, that's the way it's supposed to work. Even if you have an app linked to an older UCRT,
it will likely still run on a newer version of Windows and even with a newer version of the UCRT.
There ... clear as mud!