9. The Linker
The linker is invoked by the command line
M2LINK myprog [/s n] [/h n] [/o] [/l] [/v] [/swap [path]]
where 'myprog' is the main module of the program you are creating. The options are thus:
/s n n is the size of the stack to allocate (default is 8192).
/h n n is the amount of space to reserve for the heap (in paragraphs). The default is all the free memory.
/o invokes the optimizer. The optimizer prevents the output, to the object file, of all the procedures that are part of included modules but are not referenced. This will make your final EXE files smaller. This option (/o) and '/l' are mutually exclusive; The last one seen on the command line is the one that takes precedence.
/l tells the linker to process the line number information in the .M2O files and include it in the .DBG file. This option (/l) and '/o' are mutually exclusive; The last one seen on the command line is the one that takes precedence.
/k tells the linker to ignore module keys, i.e. to not check for module version compatibility. This option should be used with extreme care.
/v enables verbose mode (which was the default in older versions of the linker).
/swap [path] tells the linker to use a swap file. Code segments will be kept in this swap file instead of in main memory during the link process. This allows you to link larger programs.
The linker creates two files: the .EXE file is your executable program, the .DBG file is a file containing symbol information for use by other utilities (see Map file generator, Profiler).
If the /swap directive is used, a swap file is created. You may select the path (drive:directory) where the swap file is to be created. Example:
M2LINK myprog /swap D:
9.1 Module keys
The module header record and the import records written out by the compiler to the object file are stamped with the date of the .DEF file that was processed - this becomes the module key. The linker will assure that these module keys in the module header of the imported module and in the import record match; If they do not match, both modules were not compiled using the same definition module.
Because of the use of module keys, it is imperative that the date of the distributed .DEF files not be modified unless you intend to recompile the implementation modules.
When using OBJ files, you do not have the protection of Module keys.