The short answer is that Windows installers usually include all the necessary libraries as DLL's, which are usually installed into the same directory as the app, and are usually only useable by that one app. This means if you have two or three Windows products which use the same source library (for example, a compression library, or a GUI element), they'll all have the same DLL's installed, potentially at different versions.
That leads to bloat, and can lead to security vulnerabilities as patches may not be applied consistently to all the installed copies of the same library.
Some shared libraries do exist (obviously. the OS supplied libraries are included), in which case you need to ensure you have them installed and there's no simple built-in Windows solution to this (it's often handled by the installers themselves).
Modern Linux distributions come with package managers which should handle dependencies for any applications in the distribution's repository. That is most of the work of packaging a distribution (along with customising elements to provide consistency). For example, apt handles dependencies in Debian so you don't need to worry, as along as you're installing from the Debian repository.
If you're downloading and installing your own packages or compiling from source, then yes, you'll need to manage dependencies yourself.
.DLLfiles (analogous to.sofiles in Linux) which are libraries the program uses. Folks are not allowed to distribute the Visual C++ libraries themselves as part of another package, which is why MS provides the VC++ Redistributable Libraries package to send alongside software that requires them.