How does the C-app layout work?

The compiler builds object files (.obj) in each of them (at the beginning?) contains a symbol table that stores all global variables, their values (if any) , and the addresses of declared functions. What is the rest of the contents of the object file? Compiled code. What does it look like if we have multiple functions? It doesn't all merge into a single sequence of commands...

How does static linking of libraries work? The linker looks for unresolved symbols in the symbol table in the specified libraries. So I understand that the library should also specify where the desired function is located and its size. Next, the function is included in the executable file. It turns out that .lib does not need to be dragged after itself since the function is already in. exe?

How does dynamic linking of libraries work? The OS must use the import table to find the necessary functions in the. dll and load these functions into the RAM of the process?

Please, can I explain in more detail about all these things and what you think is relevant to this issue.

CORRECTED: I clarify my questions:

1. Object files. The compiler creates an object file, which is generally represented by a header containing various information about the program, and compiled code that also depends on RTL and, depending on the compiler, contains certain references to functions from RTL libraries. The header also contains a table of symbols (which contains information about all methods and global variables (size, type, addresses, etc.), as well as, in the case of C++, descriptions of class methods, whose names are written using name decoration due to some restrictions on symbols (in the case of dlls, this makes it difficult to use classes with explicit linking, as I understand)). The compiled code is simply represented by solid instructions, which are somehow separated by functions, into the beginnings of which are indicated by the characters in the character table. When there are several object files, the symbol tables are merged, as is the code, and the most "massive" character is selected from the repeated characters. Is it true? What can you add to this?.
2. Static layout. The linker looks for unresolved symbols from the symbol table of the object file in the plug-in libraries. In the case of a static layout .The lib file is only used as a resource for functions, from where they are copied to the target . exe their contents (i.e.. lib for a drag is not necessary?).
3. Dynamic layout. In dynamic linking, the linker marks the unresolved characters as IOU ("I owe you") (whether it searches for their definitions in the specified ones .dll? you have to be sure that it is .the dll that the user specified exists at all and it has this method. Is not it so?). At startup .The exe OS connects the necessary ones .dll (looks for them in the right places) and loads them into memory. Only, like as with implicit linking, if some. dll is already in memory, it will not be loaded again. But how does the OS know at what address this one is .is the dll loaded? The methods are replaced with references to the loaded function .dll or what? When explicitly loading all functions .dll like just unloaded into memory on a par with the functions of the .exe and in the data table there are addresses of these functions in RAM - or how does it even look like? When passing a variable to a method, its name is replaced with address from the data block? What does it look like?