What are similarities and differences between dynamic loading and late binding?

What are the differences and similarities between various terms such as object file, executable, dynamic linking, dynamic loading, run time, load time, and compile time?

• Answer:

  While writing this answer I'm assuming that the reader has basic programming knowledge. Some definitions -  they may not be descriptive, but are good enough for our purposes here:  - Central Processing Unit (or CPU, or processor) is the term used to signify the piece of silicon responsible for the computational work. It primarily comprises of electronic switches (called transistors) which are the building-blocks of logic-gates. These logic-gates are the basic unit of all compute-modules in a CPU.  - Machine Instructions are what the CPU understands. It lets the CPU know what sub-units of the processor are to be 'invoked' and where (and how) to read the data to be 'processed' by those sub-units.  - Scheduler is a component in Operating Systems (OS, eg Windows, Linux, Unix, VxWorks) which is responsible to provide machine-instructions present in the system-memory (RAM) to the CPU for consumption.  - Compiler coverts (translates) the programming-instructions written by the programmer (called source-code, usually written in English-based programming-languages, eg, C/C++) into machine-instructions. Usually, compiler works on each 'file' of source-code.  - Linker is responsible for 'merging' the compiler-output of various source-files into a single output, which may be used by the Linker in subsequent stages, or is usable by the OS to 'instruct' the hardware.  - Loader is what helps an OS read the machine-instructions (from the Linker's output) and stores them in RAM for quick access by OS's scheduler Moving to the terms asked for in question now: - object files (in compiler based languages, eg C/C++) are the output of Compiler. These primarily contain the machine instructions generated while 'decomposing' the high-level-programming-language source into machine-instructions.     As noted above, compiler works on single source-files (called 'units'). To avoid complexity while writing the source-code, it is preferable to break the source-code in units which are 'logically-aggregated'. However, it is very much possible for one unit to refer to (or use functionality of) a portion of source-code written in other unit. To facilitate this behaviour, compiler allows (with a certain set of rules) the programmer to 'skip' some portion of code. A good analogy would be how an author would add a footnote/citation/cross-references to a certain paragraph in a book - till the book is bound and printed, the 'page-numbers' of the footnote and the paragraph aren't finalized. Similarly, compiler generates the 'incomplete' machine-instructions, which has the constructs to indicate 'references'. It is the Linker's job to resolve these 'references' appropriately while merging the objects. Post resolution of references, a Linker may either generate a 'relocatable object' (which can simply be used by Linker as if it was generated by the compiler), an 'executable', or a 'dynamic object'  - An executable contains the machine-instructions which can be 'dispatched' to the CPU by the OS. An executable can either be statically-linked, or dynamically-linked.     A statically-linked-executable has the complete-set of machine-instructions the OS's scheduler would need while 'dispatching' the executable to the CPU. All the OS (scheduler) needs to do is to read the instructions (from relative memory location(s) specified within the executable itself) and give them to the CPU for processing as-and-when-required.     To understand a dynamically-linked-executable, it is important to understand dynamic-objects, which are quite like statically-linked-executables in structure, but with an important difference - other executables can 'ask' this special type of object to 'run its machine-instructions' when asked for by the executable.     A good analogy will be cooking - if you need tomato-puree while preparing a dish, you can either wash+chop+blend the tomatoes yourself, or you can 'ask' someone else to prepare it for you and give it to you when you need it while you concentrate on your dish. It would be instructive to think of a 'dynamic-object' as a domestic help which prepares puree, mashes potatoes, grinds spices, etc. for you and give them to you 'on demand' while you concentrate on preparing the dishes. Just like two (or more) chefs can take advantage of a single domestic help while preparing separate dishes, a number of different executables can ask the OS to run machine-instructions from dynamic-objects when they require so. This considerably reduces the effort a programmer must put in to write a program, as he can use common functionality from dynamic-objects. Such executables, which depend on machine-instructions present in dynamic-objects are called dynamically-linked-executables.  - Dynamic-loading is a special feature an OS's Loader module provides - it allows dynamically-linked-executables to load/unload dynamic-objects into/out-of system memory as and when needed. This helps in keeping the system-memory-usage of a dynamically linked executable to a value lower than what would have been need if all the dynamic-objects needed by executable were loaded into system-memory at once.  - Compile/Load/Run-time define various stages a certain programming construct is defined/created.     As an analogy, consider a vacation to a foreign land.     If you plan your itinerary well before your vacation begins (including what to eat, when and where), then it would be equivalent to defining a programming construct (say, a code-branch) at compile-time, since you know which branch of code to take at the time of executable creation (before your vacation begins, as per the analogy). The disadvantage of such a strategy is that sometimes, user of the executable might want to control the behaviour of executable as per his/her 'wishes' - eg, you may like a tourist spot more than you expected and would want to stay longer than you'd have planned for, but a rigid itinerary wouldn't allow you to do so without affecting rest of your plans for the day.     While defining programming constucts at compile-time has it advantages  - usually the programs (source-code) written like this will be fastest - defining all possible programming constructs at compile-time severely affects the usability of an executable. Thus, is recommended that some programming constructs are made load-time and/or run-time definable. These allow for the programming constructs to acquire values when their machine-instructions are copied into system-memory (load-time) or while they are being scheduled by the OS's scheduler (run-time). In our vacation analogy, this means 'deferring' some decisions to be taken once the vacation begins (load-time), or when you are ON vacation (run-time).     Usually, making a programming construct compile-time-configurable achieves fastest execution times, with run-time-configuration being slowest (and load-time being somewhere in-between). Conversely, usually run-time-definition-of-constructs allow for more flexible configuration, whereas compile-time-construct-definition is not-at-all configurable (again, with load-time being intermediate). Depending on the intended usage of an executable, different programming constructs are defined at complie/load/run-time to achieve perfect balance between execution-speed and configurability.