There's a command line compiler option to avoid reliance on VC++ redist: /MT (in release mode) or /MTd (in debug mode). Default is /MD (in release mode) or /MDd (in debug mode). With /MT or /MTd Microsoft libc will be linked statically to your application and VC++ redist DLLs won't be required to run the application in the end user environment.

Though there's a shortcoming: if your application consists of EXE file(s) calling into your own DLL(s), then in /MT or /MTd mode you have multiple instances of libc in the process address space, and so tricks like "malloc() in dll, free() in exe" or "open() in dll, close() in exe" will produce weird runtime errors. That won't be a problem if DLL interfaces are strictly C functions and structs, i.e. without classes, STL, smart pointers, exceptions, RTTI-related stuff etc.

Static linking can also make the executable a lot bigger, and if the statically linked library uses new APIs, won't run on older Windows versions (I know about the special XP support option, but I don't know if it'll let you create binaries that will run on Win95.)

The other option (which I believe MinGW uses) is to link with msvcrt.dll, something which MS doesn't officially support and rather strongly discourages but actually works very well in practice and enables the "one binary for Win95 to Win10" effect.

Minimum Windows runtime version depends on libc shipped with MSVC compiler, for Visual Studio 2008 it's Windows 2000 SP4; for VS2010 it's Windows XP SP3; for VS2013/VS2015 it's Windows 7 IIRC. There's also /Zl compiler option to omit libc entirely (e.g. for small programs using only Win32 API).

MSVCRT.DLL used to be default runtime library for code produced by Microsoft Visual Studio 6 compiler. This DLL is still shipped with Windows, albeit its sprintf() doesn't support %ll format specification, its time() function assumes that time_t is 32-bit, and in general it feels very 1998y. It required some redist on Win95 and NT4 IIRC.