''Object code'' refers to code or files which:

* Are instructions for some machine, either real (a microprocessor's instruction set), virtual (ie JavaByteCode), or abstract (ie MicrosoftIntermediateLanguage)
* Are usually the output of a compiler or assembler, and either generated locally as part of a build or are a 3rd-party deliverable (ObjectCode is typically not hand-edited)
* Is intended to be the input of a LinkerProgram, VirtualMachine, debugger, or an OS program loader.
* Is often in binary form (though not always); even if in text form is generally not fit for human consumption.

In addition, files which are archives of other object code files (such as Unix .a and .sa files, Windows .lib files, COM assemblies, Java .jar files, DotNet assemblies) can, for most intents and purposes, be considered object code (even if the archive file is or can be used for other things--.jar files are really .zip files, the Unix archive tool can be used to archive anything and not just object files).

When object code is targeted for a CPU's instruction set ("machine code"), it frequently (but not always) can be subdivided further as follows:

* Simple object files (.obj in Windows, .o in Unix).  These are only suitable as the input to a LinkerProgram; they cannot be directly executed nor dynamically loaded (lacking the necessary runtime support).  Usually contain undefined symbols which must be further resolved.

* Dynamically linked libraries/shared libraries (.dll in Windows, .so in Unix).  These are generally intended to be input as for a dynamic linker.  They contain additional implementation-dependent stuff to make runtime linkers/loaders more efficient, and often must contain position independent code (most OS's arrange to have only one copy of a given DLL in memory at a time, even if being used by multiple applications).  See DllHell.

* Executables.  These are intended to be directly run by the program loader, and contain the necessary machinery for that (the main program, the language runtime initialization/cleanup code, etc).  Should not contain undefined symbols, other than those found in a DLL.

When object code is IntermediateLanguage, many of the above distinctions vanish.  There is no such thing as static linking in Java; all linking in Java is done by the class loader.  The only difference between an executable and non-executable Java class is the presence of "public static void main(String[])" in the class definition.

----

CategoryLinker