For example, there are seperate and distinct redists for each of the following: This package is called a "redistributable" (or "redist"), and there is a different one for every combination of exact compiler version and target platform.
As a result, applications that ship to end users are often (usually?) also shipped with a package of these DLLs. Functions like printf, memcpy and the like are implemented in these DLLs.Įvery program that is compiled with a particular compiler and dynamically linked to the C++ runtimes must somehow have the correct version of the CRT binaries on the target machine.
The MSVCRT is a set of DLLs that implements parts of the C++ language. This is an oversimplification, but it will give you the gist. I mean, lets say GDI, I tell it to draw picture, it makes all the hard work in user mode and than call kernel function which puts it all in framebuffer?Īnd last thought, why is this even solved this way? I mean, if VC++ runtime is just layer between C and WinAPI, why cant VC++ call directly WinAPI? So, am I right, when I know get it that "simple" functions like printf need to be linked directly and than use only Kernel part of OS directly, and more sophisticated Windows API functions are linked as dlls, therefore ARE NOT distributed with compiler but with OS? And they subsequently access Kernel? But I thought even functions like printf and so are in some windows file. Also, that Win32API are from kernel and user parts.īut I always thought that functions like GDI are accessed as DLL (which I still believe they are). I mean, the first part, that Windows internally has its win32 API and so, that's OK, I knew it.
I thing now I have bad idea of runtime libraries in windows. I thought that Windows C runtime libraries come with Windows? Not with VC++? Thanks.įirst, thanks for answers. What's in MS Visual C++ runtime library? I mean, I googled it, and I always found things like help, app xxxx gives me MS Visual C++ runtime library error, with no explanation.
0 kommentar(er)
