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

  Most high-level programming languages use dozens of prepared subroutines
  that support the operation of your programs. Naturally, these
  subroutines are in the translated, object-code form. It is very
  inconvenient, however, to have dozens or hundreds of these object files
  taking up space on your disks. It is also inconvenient to have to
  determine which ones need to be combined with your own program's object
  files. To solve this problem, we have object libraries, which are
  collections of object modules gathered together into one file. By
  convention, libraries have the filename extension .LIB.

  Most high-level programming languages come with a ready-to-use library of
  standard supporting subroutines. Some compilers have several
  libraries that provide different versions of standard routines. For
  example, a compiler might have two libraries of equivalent floating-point
  math routines: one with subroutines that use the 8087 coprocessor and the
  other with subroutines that emulate the same floating-point operations in
  software.

  The DOS linker can search through a library to find and use the
  subroutines it needs in order to create a complete, executable program.
  Without this library mechanism, you would be faced with the annoying task
  of telling the linker which object files were needed. If you omitted any,
  the link-editing would fail; if you included any unnecessarily, your
  program would become too large. Libraries let you avoid these problems.

  To manipulate the contents of an object library, you need a special
  utility program called a library manager. (DOS version 3.3. is distributed
  with a library manager called LIB, but earlier versions did not include
  this utility.) Luckily, when you purchase a language translator that
  relies on object libraries, you'll almost always find that a library
  manager accompanies the compiler. The following discussion pertains to the
  Microsoft/IBM library manager, LIB.

  You can use LIB for three main purposes: simply to explore the contents of
  existing libraries (which can be a very illuminating experience), to
  selectively replace modules in existing libraries, or to create new
  libraries.

  The documentation for LIB in the IBM and Microsoft manuals will fully
  explain its operation, but to give you a taste of the ways LIB can be
  used, we have included a few examples to try out. To create a new library
  named TESTLIB, enter this command:

  LIB TESTLIB;

  To list the contents of an existing library, directing the listing to the
  printer LPT1:, enter the following command:

  LIB TESTLIB,LPT1;

  To add the module X.OBJ to a library, enter the following:

  LIB TESTLIB +X;

  To replace an existing module with a new version, enter the following:

  LIB TESTLIB -+X;

  To extract a module for disassembly or other separate use, enter the
  following:

  LIB TESTLIB M *X;

  Most programs call a number of subroutines. The way you organize these
  subroutines determines how much value you'll obtain from LIB:

  .  If you prefer to combine the source code for your subroutines into one
     source file, which means they will all be compiled together, then you
     have little need for LIB.

  .  If you prefer to compile your subroutines separately into separate
     object files, then LIB performs a valuable service: It gathers together
     and organizes your object files. We have no absolute recommendation for
     either style of operation, although many programmers prefer to break a
     large program into separate source code files that can be compiled into
     separate object files and linked together. Such a modular approach can
     be more convenient than maintaining one large source code file that
     must be completely recompiled with each change.