You didn’t post it (that “I tried to explain that Pascal that and FORTRAN did not have a ‘monolithic’ runtime”). If you did, please quote where you did so. And, as I explain below with a specific example, that statement is wrong anyway. That’s OK.
That wasn’t the question. The question was where is the DLL corresponding to the C standard library. As explained in this Microsoft document, ucrtbase.dll contains the ISO C standard library (libc) as well as some components for C++. It is the dynamically linkable equivalent of the static library libucrt.lib, which is only provided with Visual Studio or the Windows SDK. It’s not really a runtime system, though Microsoft calls it that, but rather the standard library of C functions that is usually dynamically linked at runtime, but the programmer could optionally choose to statically link it with the .lib file.
From an architectural perspective one could say that C has a very minimal runtime, as indeed I’ve cited several times, called CRT0. On Windows CRT0 is always statically linked. One could therefore argue that C has no runtime at all, or certainly no runtime dependency, since it could easily be built that way.
While the distinction as to just what a runtime is may sometimes be unclear in modern language implementations, especially with dynamic linking, the distinction was very clear in legacy implementations of languages like FORTRAN, making the statement that it “did not have a monolithic runtime” completely and demonstrably false. One need only look at a legacy system like FORTRAN on the PDP-10 (DECsystem10) timesharing system to see a clear example of this architecture.
The FORTRAN system on the PDP-10 had four components: the compiler itself, the runtime system called FOROTS (OTS=Object Time System), the FORTRAN library called FORLIB used by the linker, and a debugging component called FORDDT which isn’t relevant here.
One notes that the runtime system had the .SHR file extension (FOROTS.SHR). The file extension .SHR referred to what was called a shareable high segment, logically part of the user process, but mapped to a common shared virtual high memory segment that was pure code, with all the user-specific data in the low segment. This architecture was commonly used to allow system programs to serve multiple users with only one copy of the pure code, with the variable data in the user’s low segment. The FORTRAN object time system being a SHR meant that it was mapped as a monolithic entity to the high segment of the user’s virtual address space. Thus a running FORTRAN program consisted of the user’s compiled code plus any needed library functions and subroutines in the low segment, and the essential runtime system in the high segment.
Other FORTRAN implementations weren’t as elegant but made a similarly clear distinction between the FORTRAN library and the runtime system. It’s much less obvious in C because basically there isn’t really a runtime system at all in any such sense (let alone a big one), by design.