On Saturday, 22 May 2021 at 16:25:08 UTC, Andrei Alexandrescu wrote:
> While working with the dmd codebase (https://github.com/dlang/dmd/pull/12560) I noticed that it systematically shuns C runtime calls to functions such as unlink, rename etc. Instead the code uses native Windows API calls (DeleteFile, MoveFile).
>
> Spoke to Walter about it, he said the reason is mostly historical and for the most part forgotten and probably obsolete - at least in the past, Windows implementations of CRT was poorly done, had subtle differences, and bugs.
>
> Is that still the case? If not, we could reduce the complexity of source code considerably by unifying version(Posix) and version(Windows) code.

Wikipedia has a small section on the C Runtime DLL which talks about the changing history and the present use of two DLLs, one of which has name changes in sync with VC++ versions:
https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL


_______________________________________________________________________
MSVCRT.DLL, MSVCP*.DLL and CRTDLL.DLL

MSVCRT.DLL is the C standard library for the Visual C++ (MSVC) compiler from version 4.2 to 6.0. It provides programs compiled by these versions of MSVC with most of the standard C library functions. These include string manipulation, memory allocation, C-style input/output calls, and others. MSVCP*.DLL is the corresponding C++ library.

It has shipped with Windows versions since Windows 95 OSR2.5 for use by other Windows components; earlier versions shipped with the CRTDLL.DLL library instead. In older versions of Windows, programs which linked against MSVCRT.DLL were expected to install a compatible copy in the System32 folder, but this contributed to DLL Hell because many installers failed to check the library version against the installed version before replacing it.

Versions of MSVC before 4.0 and from 7.0 to 13.0 used differently named DLLs for each version (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL, etc.). Applications are required to install the appropriate version,[16] and Microsoft offers Visual C++ Redistributable packages for this purpose, though Windows typically comes with one version already installed.

With Version 14.0, most of the C/C++ runtime was moved into a new DLL, UCRTBASE.DLL. However, C/C++ programs using UCRTBASE.DLL are forced to link against another new DLL, the VCRuntime, whose name continues to change with each version of MSVC (e.g. VCRUNTIME140.DLL).

Source code for runtime libraries is included in Visual C++[17] for reference and debugging (e.g. in C:\Program Files\Microsoft Visual Studio 11.0\VC\crt\src).

This runtime library is used by programs written in Visual C++ and a few other compilers (e.g. MinGW). Some compilers have their own runtime libraries.

On Saturday, 22 May 2021 at 19:08:14 UTC, IGotD- wrote:
> Instead of trying to unify the code, OS dependent implementations should be moved to separate files. Also, should D rely on the C library? I would say the D should go the other way and rely on the C library a little as possible.

This, even on posix the only useful stuff in libc is malloc and getaddrinfo. Try anything mildly useful like pipes, processes, threads, atomics, mutexes, sockets, async io, and you find yourself writing a PAL anyway.