about static link and dynamic link (zz)

There are (in most cases, discounting interpreted code) two stages in getting from source code (what you write) to executable code (what you run).

The first is compilation which turns source code into object modules.

The second, linking, is what combines object modules together to form an executable.

The distinction is made for, among other things, allowing third party libraries to be included in your executable without you seeing their source code. Examples are libraries for database access, network communications and graphical user interfaces.

In all these cases, you generally only need to concern yourself with the interfaces to those libraries, not the inner workings of them (unless they have bugs, of course).

When you statically link a file into an executable, the contents of that file are included at link time. In other words, the contents of the file are physically inserted into the executable.

When you dynamically link, a pointer (the file name of the file, for example) is included in the executable and the contents are not included at link time. It's only when you run the executable that these dynamically linked files are bought in and they're only bought into the in-memory copy of the executable, not the one on disk.

It's basically a method of deferred linking. There's an even more deferred method (called late binding on some systems) that won't bring in the dynamically linked file until you actually try to call a function within it.

Statically-linked files are 'locked' to the executable at link time so they never change. A dynamically linked file referenced by an executable can change just by replacing the file on the disk.

This allows updates to functionality without having to re-link the code; the loader re-links every time you run it.

This is both good and bad - on one hand, it allows easier updates and bug fixes, on the other it can lead to programs ceasing to work if the updates are incompatible.

---

As an example, let's look at the case of a user compiling their main.c file for static and dynamic linking.

Phase     Static                    Dynamic --------  ----------------------    ------------------------           +---------+               +---------+           | main.c  |               | main.c  |           +---------+               +---------+ Compile........|.........................|...................           +---------+ +---------+   +---------+ +--------+           | main.o  | | crtlib  |   | main.o  | | crtimp |           +---------+ +---------+   +---------+ +--------+ Link...........|..........|..............|...........|.......                |          |              +-----------+                |          |              |           +---------+     |         +---------+ +--------+           |  main   |-----+         |  main   | | crtdll |           +---------+               +---------+ +--------+ Load/Run.......|.........................|..........|........           +---------+               +---------+     |           | main in |               | main in |-----+           | memory  |               | memory  |           +---------+               +---------+ 

You can see in the static case that the main program and C runtime library are linked together at link time (by the developers). Sine the user typically cannot relink the executable, they're stuck with the behaviour.

In the dynamic case, the main program is linked with the C runtime import library (something which declares what's in the dynamic library but doesn't actually define it). This allows the linker to link even though code is missing.

Then, at runtime, the operating system loader does a late linking of the main program with the C runtime DLL (dynamic link library or shared library or other nomenclature).

The owner of the C runtime can drop in a new DLL at any time to provide updates or bug fixes. As stated earlier, this has both advantages and disadvantages.