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

 Dynamic overlays
------------------------------------------------------------------------------
 Dynamic overlays remove the need for an overlay structure and solve many of
 the problems associated with static overlays. At link time, the developer
 need only specify what is to be overlaid, and the overlay manager handles
 the rest. An area of memory is only reserved for the overlays at program run
 time, and each time the program is run, the overlay manager loads the
 overlays into this area in the order in which they are called.

 The overlay manager maintains a table of the overlays and their locations in
 the overlay area, along with information on whether each overlay is
 currently in use, how often it has been used, and when it was last used.
 Once the overlay area is fully utilised, overlays are discarded according to
 their frequency and history of usage to make room for new overlays. This
 process is known as dynamic overlaying, because the loading and discarding
 of overlays varies according to the manner in which the program is run.
 Blinker's overlay manager performs the process of loading and executing an
 overlay in four stages, which are as follows:

 1. Determine if the overlay is in memory; if so, go to 4.
 2. Find the overlay code in the overlay cache or overlay file and load the
    code into an available location in memory within the overlay area.
 3. Relocate any references made by the code to external variables and
    procedures, i.e. those outside of the overlay code itself. This is done
    from a table of relocations stored within the overlay, in much the same
    way as DOS fixes up references to specific segments within an .EXE file
    when it loads the .EXE file at runtime.
 4. Transfer control to the overlay in such a way that the overlay manager
    will regain control once the overlay has finished execution.
    The use of a separate overlay memory area has two benefits. Firstly,
    since dynamic overlays are not required to be loaded at an address
    determined at link time, (unlike static overlays) but can instead be
    loaded anywhere in the overlay area, a larger number of overlays can be
    in memory at one time ready for execution. This enhances execution
    speed. Secondly, the size of the overlay area can be adjusted to suit
    differing runtime memory requirements.

 Blinker allows the developer to dynamically overlay program code for optimum
 use of memory without the complexity of overlay structures. This is easily
 done with one BEGINAREA and one ENDAREA command. All libraries and files
 specified between these two commands will be overlaid; and all code from
 libraries and files listed outside of this overlay area will remain
 permanently in memory while the program is executing.

 FILE Rootfile  # Will remain in memory

 BEGINAREA
    FILE File-x # Will be overlaid
    LIB Lib-y   # Will be overlaid
 ENDAREA

 LIB Rootlib    # Will remain in memory

 To overlay a library it must be placed between the BEGINAREA and ENDAREA
 statements, irrespective of which command is used to specify the library
 (LIBRARY or SEARCH). Also note that Blinker has the capability to overlay
 portions of a library if required - see chapter 9, the MODULE command.

 With dynamic overlay linking, no space for overlays is reserved in the .EXE
 file as it is with static overlays. Blinker uses a 'fixed' overlay
 allocation method whereby a fixed size memory block for the overlay area is
 allocated from DOS by the overlay manager before the main program gets
 control. This memory block is normally located at the top of free DOS
 memory, unless the programmer specifies Upper Memory Blocks or the EMS
 pageframe for overlay use. (For the only exception to this see chapter 8 -
 CA-Clipper Summer `87's use of a dynamic overlay allocation method.)
 The unit for dynamic overlays is a single .OBJ file, i.e. Blinker loads and
 executes overlays on an object module, or, more correctly, a code segment
 basis, rather than the section basis used with static overlays. Blinker
 dynamically resolves cross references among .OBJ files which leads to
 greater memory efficiency and increased granularity.

 Note for CA-Clipper

 Because each CA-Clipper procedure or function is contained in a separate
 segment, Blinker manages overlaid CA-Clipper code at the procedure or
 function level, rather than at the .OBJ file level used with static
 overlays. This allows much more efficient use of memory and much faster
 loading of overlays when they are required.