2/17/92 Blink Inc.
Linking for Development and Production for Clipper Summer '87
Generally speaking, the optimal computer environment for application
development differs from that for application production. This is
reflected in the differing approaches to linking when creating a test
version as opposed to the final production version of an application.
The following suggestions should help in optimizing link scripts used
for development and for the final production link when using Clipper
The development link scripts are based on the following assumptions:
1. The top priority during development is a short test cycle turn-around
time, where the test cycle is comprised of editing, compiling, linking,
2. Memory and application execution speed are less of a concern, and
only become critical when using debugging tools or incremental linking,
since the developer generally has more memory and a faster PC than the
For development in Clipper Summer '87:
For the fastest link speed, use Blinker's incremental linking (the
default). A higher ratio of incremental links can be attained by
increasing the BLINKER INCREMENTAL PAD above its default of 128 bytes
Since an incrementally-linked application uses more memory, the
following suggestions are presented to help in reducing a Clipper
application's use of memory, short of turning off incremental linking.
As the application grows in size, these suggestions will prolong your
use of incremental linking, usually at the expense of application
1. Overlay as much as possible.
Place all Clipper .OBJ files and libraries in the BEGIN/ENDAREA. Then
overlay EXTEND.LIB and any overlayable third party products, being
careful to follow each product's dynamic overlay instructions, since
there are many overlaying methods.
2. Specify BLINKER OVERLAY FIXED.
This overlay allocation method is a prerequisite for points 3 and 4.
3. Use BLINKER OVERLAY PAGEFRAME ON.
This allows the Blinker overlay manager to use the EMS Page Frame for
the overlay pool at application run time.
4. Decrease the BLINKER OVERLAY OPSIZE.
If the overlay pool is not placed in EMS or XMS, this command can be
used to allocate the minimum amount of conventional memory for the
overlay pool. The minimum possible is displayed by Blinker at link
5. Overlay portions of CLIPPER.LIB.
The nested link script files CL87MID.LNK and CL87MAX.LNK have been
provided to overlay a medium and maximum portion of CLIPPER.LIB. These
.LNK files will probably result in slower execution speed and may need
to be tailored for each application. Systematically comment out a
number of overlaid CLIPPER.LIB modules to find the few modules that,
when commented out, result in an acceptable execution speed.
6. Combine Clipper-compiled .OBJ files into as few files as possible.
This is a manual technique to compress Clipper's symbol table until
Blinker automatically compresses it in response to turning off
incremental linking. Either combine the .PRG files or use Clipper .CLP
files. For the fastest compile turnaround, keep the few, most
frequently modified programs as separate .OBJs.
7. Utilize the BLINKER INCREMENTAL PAD command.
When necessary, the padding used for incremental linking can be reduced
from the default of 128 bytes. This will result in a lower ratio of
incremental links, but may save enough memory to permit incremental
linking to continue.
Sample for Development in Clipper Summer '87:
BLINKER INCREMENTAL ON # the default
BLINKER INCREMENTAL PAD 128 # the default
BLINKER EXECUTABLE CLIPPER F31;E0;V15;R16
BLINKER MEMORY PACK 10
BLINKER PROCEDURE DEPTH 50
BLINKER OVERLAY OPSIZE 20
BLINKER OVERLAY FIXED
BLINKER OVERLAY PAGEFRAME ON
BLINKER CACHE EMS 50%, 50% # Blinker version 2.0 only
BLINKER CACHE XMS 50%, 50% # Blinker version 2.0 only
FILE prg1.obj # starting program
FILE prg2.obj # individual prg being modified
FILE DEBUG # Clipper S'87's debugger
FILE clpfile1 # a number of combined prgs
FILE clpfile2 # a number of combined prgs
LIB ESCAPE # a 3rd-party overlayable lib
FILE rootfile # non-overlayable .OBJ
@CL87MAX.LNK # tailored
The production link scripts are based on the following assumptions:
1. The top priority is for the application to execute within the amount
of memory that is available at all production sites.
2. Execution speed is the next highest priority.
For Production in Clipper Summer '87:
1. Turn off incremental linking.
Use the command BLINKER INCREMENTAL OFF to save memory.
2. (A) Put Blinker's overlay pool in the EMS Page Frame.
If a number of your users have EMS available, you probably will want to
continue using the Page Frame with the command BLINKER OVERLAY PAGEFRAME
ON. Remember this requires that you also specify BLINKER OVERLAY FIXED.
(B) Use the default overlay allocation method.
If you do not use the Page Frame or UMB's, you may find the default
overlay allocation method faster (BLINKER OVERLAY DYNAMIC).
3. Memory savings suggestions.
If some production sites are running out of memory, see the current
memory-saving suggestions in the Blinker manual chapter 5 or in the
technical support bulletin on Blinker's BBS and Fast Fax systems.
4. Cache overlays.
The overlaid modules can be cached in expanded or extended memory for
faster application execution speed by using the commands, BLINKER CACHE
EMS & BLINKER CACHE XMS.
5. Increase the size of the overlay pool.
Finally, if you have any memory left over, add some of it to the overlay
pool to increase the application execution speed by increasing the
BLINKER OVERLAY OPSIZE.
Sample for Production in Clipper Summer '87:
BLINKER INCREMENTAL OFF
BLINKER EXECUTABLE CLIPPER F31;E0;V15;R32
BLINKER MEMORY PACK 10
#BLINKER OVERLAY DYNAMIC # the default
BLINKER OVERLAY OPSIZE 60
BLINKER PROCEDURE DEPTH 50
BLINKER CACHE EMS 30%, 70% # Blinker version 2.0 only
BLINKER CACHE XMS 30%, 70% # Blinker version 2.0 only
FILE prg1 # first prg of the application
FILE prgn # individual prg
FILE rootfile # non-overlayable prg
@CL87MIN.LNK # overlays only EXTEND.LIB
Copyright Blink, Inc.