C Runtime Library 2

Question

I was offered, when I have additional questions about my elders, create a new question and turn to the old one. So this is the original question: What is the C runtime library?

OK, from your answers, now I get statically linked libraries - this is Microsoft's implementation of the standard C functions. Now:

If I understand correctly, the scheme will be as follows: I want to use printf (), so I have to include <stdio.h> , which simply tells the compiler that there is a printf () function with these parameters. Now that I am compiling the code because printf () is defined in the standard C library, and since Microsoft decided to call it C Run Time library, it is automatically statically linked to libcmt.lib (if libcmt.lib is installed in the compiler) at compile time. I ask because in wikipedia, the article on the runtime library has that the runtime library is linked at runtime, but the .lib files are linked at compile time, am I right?

Now that bothers me. There is a .dll version of the C standard library. But I thought that to link a .dll file, you should actually call the winapi program to load this library. So, how can these functions be dynamically linked if there is no static library to provide the code to force Windows to load the necessary functions from the dll?

And really, the last question on this topic are the functions of the standard C library that also call winapi, even they are not .dll files, such as the more advanced WinAPI functions? I mean, at the end, to access the framebuffer and print something, you have to tell Windows to do this, since the OS cannot allow you to directly manipulate HW. I think about it, since the OS must be written to support all standard C library functions in the same way in similar versions, since they are statically linked and can support more complex WinAPI calls in different ways, because the new version of the OS may have settings in the DLL file .

Answer 1

C-related runtime is a wrapper around your "core" function; it initializes everything that is needed before your C code can be run. It does not contain (m) any "functions" that are in the standard C library (which is dynamically linked).

I think you misunderstand dynamic binding: this is done by the OS. This way you tell the OS that your executable needs DLLs a , b , c and d . When you execute an executable file, the OS will load the executable file in a memory location and read in the executable file what is needed to run it. Then it will capture these DLLs and insert them into the memory area of ​​your executable file, and then it tells your code that a loaded into x , b loaded from y , etc. Therefore, your code may call it functions.

Sometimes compilers include a (called static binding) library at compile time: they do this so that the OS does not load it at run time and therefore loads faster.

.lib files are DLL files without a "D" because they can be statically linked. It is also possible to dynamically link library files; this makes your executable file smaller, but makes the loading time of your executable file slower.

About WinAPI: most C library calls are converted to (some) calls in WinAPI; but only if they must interact with the OS (I / O, etc.). The difference is that the C library is the same on most platforms, so it improves portability if you use the C library directly instead of the Windows API.

Update:

You asked how to load a DLL if you are linking your executable file dynamically? Well: you don’t have to! The difference between "load dll" and "call to load dll" is; "load dll" is executed by the OS when the application starts. The OS will search for your executable file for the specific "import table". This is the table in which the DLL is valid before it can execute (i.e. kernel32.dll or user32.dll on Windows). The OS will make a “call to download dll”, even before your code runs.

A “call to download dll” also exists in kernel32.dll for your code that is being called: it can load / unload DLLs at the time your code runs. This may be the case if you have a huge code base and you want to free up memory by unloading this one-time library throughout the entire application life cycle (for example, during startup). If you no longer use this function, you can unload the DLL. But it is also possible that you need some function that you have not yet downloaded to speed up the download. You can then load the DLL if you need the function yourself. This is quite advanced material, and most of the time, the OS replaces unused DLLs (“deleting” memory literally: it moves memory that is not used much (for example, an unused DLL) to the place of mass storage, like a hard disk. If you need it necessary, it will automatically “swap” back!).

So: you don’t have to worry much about loading / unloading DLLs in Windows. If you have a good linker and tell it to dynamically link to libraries, everything will work fine.

Answer 2

To ask your questions in order:

Wikipedia is misleading. The runtime library is not always bound at runtime, and not when you selected a statically linked runtime ( libcmt.lib ).

There is a .dll version of the runtime library (which is linked at runtime), and the compiler knows how to generate the appropriate instructions in the .exe to tell the loader to load the .dll runtime library at runtime.

There are two APIs here. One of them is the Win32 API, which is a list of functions supported by Windows itself. Another API is the C API, which is defined by the C programming language standard. Some C runtime library functions, such as opening and reading files, will eventually cause Win32 API calls to actually perform file I / O. Other functions of the C library, for example, strlen() , do not interact with the OS and are implemented using code completely inside the runtime library itself.

Answer 3

In Visual C ++ and some other compilers, CRT is associated with you unless you explicitly talk about it (sometimes useful for reducing code size).

In the compiler options, you can choose whether to have versions of Debug or Release, as well as their statically linked or dynamic.

Static binding puts all the actual code from all the CRT functions that you call directly into your EXE. This is useful for reducing the number of external dependencies that you need - you can simply run the EXE and not worry about whether you have the correct xxxx.dll installed. The downside is that the CRT functions you sent can have problems (security hacks, crashes, race conditions) and the only way your end user can solve these problems is if you create a new EXE.

Dynamic linking places the link in the CRT functions that you call from your EXE. When your EXE loads and your code makes a call to the specified function, the dynamic OS loader will see that this function is actually located in MSVCRT [D] [version] .dll and loads this DLL, looks at the address of the function and then fix the link in your code to directly point to a function in the DLL, so next time it will be as fast as if you statically linked it. Obviously, here is the initial initial delay (compared to a static link), but the benefits are huge: the system DLL gets a fix from Microsoft, so you can get updates for problems (see above), downloaded DLLs together in memory, so if the DLL the one you're referring to is actually already being used by another process, it takes less time to load it, since the other process has already done most of the work.

Finally, yes, CRT functions such as printf () and scanf () will end up talking to the Win32 API, but not always the ones you think. Use the DEPENDS tool in the Visual Studio / Windows SDK or SysInternals "ProcExp" to find out which DLLs are in a particular process and what functions they use.