Click above to get retro games delivered to your door ever month!

  Next, let's consider what is surely the most common linking circumstance.
  Say you've compiled a program in a high-level language, such as Microsoft
  C. As you know, every compiled C program needs to be linked with one or
  more standard object libraries that contain all the usual C functions.
  Consider what happens when you compile even a simple C program like this
  one:

  main()
  {
          printf( "Hello, world" );
  }

  If your source code is stored in a file called HELLO.C, the compiler
  generates an object file called HELLO.OBJ. This object module isn't yet
  ready to execute. You must use LINK to combine HELLO.OBJ with another
  object module that contains the printf() function. The printf() object
  module is in one of the C compiler's standard libraries; if you use the C
  compiler's small memory model, the name of the standard subroutine library
  is SLIBC.LIB.

  To link the two object modules and generate an executable file, simply
  specify the name of the program's object module and the name of library
  that contains printf()'s object module:

  LINK HELLO,,,SLIBC;

  LINK then searches through SLIBC.LIB for printf(), links printf() to
  HELLO.OBJ, and leaves the resulting executable file in HELLO.EXE.

  Even this simple example is more complicated than it has to be. Most
  modern compilers, including the Microsoft C compiler in this example, can
  include the names of their standard libraries in the object modules they
  generate. This means that LINK can do its job without being told
  explicitly about standard libraries:

  LINK HELLO;

  Of course, if you want LINK to use a nonstandard library, you still need
  to specify its name.