home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1994 #1 / monster.zip / monster / CLIPPER / CLIPTIPS.ZIP / LINKERS.ZIP / LINKERS.DOC
Text File  |  1990-07-07  |  109KB  |  2,602 lines
  1.  
  2.  
  3.  
  4.          ════════════════════════════════════════════════════════════════
  5.  
  6.                             -- CLIPPER LINKERS --
  7.  
  8.                    THE NEW DIRECTION OF CLIPPER DEVELOPMENT
  9.  
  10.          ════════════════════════════════════════════════════════════════
  11.  
  12.  
  13.         Since the introduction of the Clipper-compiler in Winter, 1985,
  14.         a plethora of Clipper third-party products have flooded the
  15.         Clipper aftermarket.  These add-on libraries have successfully
  16.         extended the Clipper language into the most powerful database
  17.         development system for microcomputers.  Applications developed
  18.         with Clipper and third-party libraries are growing larger and
  19.         more powerful, thereby causing some new development problems:
  20.  
  21.          1.  Slower development time
  22.          2.  Excessive application memory usage
  23.  
  24.         The new direction of Clipper Add-on products is to help solve
  25.         these new problems.   The most popular of the new products are
  26.         those which work towards improving the speed of development and
  27.         the memory usage at runtime - "dynamic" linkers.
  28.  
  29.         In this article, I hope to be able to convey information based
  30.         on my own experience as a Clipper developer.  In my opinion,
  31.         there is too much discussion about future products, and too
  32.         little discussion about products which are solving big
  33.         development problems - right now!  The development community
  34.         is moving away from software packages which promise a
  35.         "complete database solution" to those which offer an
  36.         "open architecture" so we developers are free to choose our
  37.         own tools, libraries and development environment.  As the
  38.         developer of dCLIP, a Clipper development platform, we have
  39.         used or are using at least 12 different Clipper linker
  40.         products.
  41.  
  42.         Case studies of successful Clipper applications point to the
  43.         fact that the developer has learned not only to become a
  44.         "library-an" but is also "multi-linkeral".  The professional
  45.         Clipper developer is now accustomed to using more than one
  46.         linker in development projects.   One of our development
  47.         projects consists of 5 Clipper .EXE programs and uses the
  48.         technology of 4 different linkers.
  49.  
  50.         The discussion of linkers raises a lot of questions.  Why can't
  51.         a developer use a single linker for all of his projects?  If
  52.         new linkers are getting better, then why not ring out the old
  53.         and ring in the new?   Are not linkers just a final process in
  54.         converting the compiled object code to be machine readable code?
  55.         The purpose of this article is to help dispel a lot of the myths,
  56.         hype, and (most-of-all) fears that confront the Clipper
  57.         developer today when it comes to the subject of linking.  I am
  58.         constantly amazed at the amount of time a professional Clipper
  59.         programmer will spend in learning the nuances and power of the
  60.         the Clipper language, yet that same professional probably has
  61.         the equivalent of a kindergarten education in the subject of
  62.         linking.
  63.  
  64.  
  65.                   Page 1  - Copyright (c) DONNAY Software
  66.  
  67.  
  68.         Today, the Clipper developer must be more educated about linkers
  69.         to remain competitive.  If you ask the Clipper programmer about
  70.         his biggest frustrations, he/she will virtually always answer
  71.         the same way - memory usage and development time.  The new
  72.         series of linkers are designed to address these problems and
  73.         many others.  Some do it better than others.  Some will use
  74.         "dynamic" techniques, others will use "static" techniques.  Some
  75.         are designed to work best with only Clipper code, others are
  76.         designed to work best with applications that are Clipper/C/ASM.
  77.         Some are designed to link very fast, others are slow but produce
  78.         better memory management.  Some are designed for small
  79.         applications, others are designed for huge applications and
  80.         networks.  Some are designed to help with distribution and disk
  81.         usage, others are designed to help with debugging.  Some are
  82.         designed for ease-of-use and quick-starting, others are designed
  83.         to solve complicated memory and symbol issues.   Some are
  84.         designed to work well with any combination of library and object
  85.         format, others will choke on just about anything.  Some linkers
  86.         are mature, slow and reliable, others are young, frisky and not
  87.         very well-behaved.
  88.  
  89.         As a developer who creates programmer's tools, I talk to many
  90.         Clipper programmers every day, because I also handle technical
  91.         support for our product, dCLIP.  I am constantly amazed at the
  92.         number of Clipper programmers who still use only one linker -
  93.         PLINK86.  Why is this so?  Are their applications so small that
  94.         they don't need better memory management?  Is their time so
  95.         well managed that the speed of linking is not important?  Most
  96.         often, the answer is none of the above.  Clipper programmers,
  97.         like many other professionals, are afraid of making a wrong
  98.         choice, and feeling like a fool for spending good money on a
  99.         folly.  You have heard it said that "the only stupid question is
  100.         the one that is never asked".  Well, I my philosophy is "the only
  101.         folly is one that is never ventured".   My knowledge of linkers
  102.         came from purchasing every one and using each one.  Over the
  103.         years I have developed an understanding of linking by trial and
  104.         error and have gained quite an education.
  105.  
  106.         To the Clipper developer, the quality of his/her end product is
  107.         everything, that is why Clipper is the most popular database
  108.         development language for microcomputers.  Choosing the right
  109.         linker for each job will improve the performance and quality of
  110.         your applications.  This article is designed to help you make
  111.         those choices.  It is not the intent of the author to dump a lot
  112.         of sophisticated "linking terms" on the reader of this article.
  113.         I am a Clipper programmer who has had to work out a knowledge of
  114.         linkers all by myself.  There is still a lot I do not understand
  115.         about linking, but what I have learned has helped me develop a
  116.         sufficient competitive edge and made it possible to produce a
  117.         product such as dCLIP.  I expect that I will learn a lot more as
  118.         you, the reader, responds with your own experiences and
  119.         knowledge, therefore I welcome any feedback.
  120.  
  121.         Together, I think we can battle our way through this linker
  122.         "war zone" and emerge victorious.
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.                   Page 2  - Copyright (c) DONNAY Software
  131.  
  132.  
  133.         The subject of linkers will be addressed in 5 sections:
  134.  
  135.         1.  Introduction/Background
  136.             a. What is linking?
  137.             b. Glossary of linking terms
  138.  
  139.         2.  Linking tips for memory management
  140.             a. Static Overlays
  141.             b. Reloadable Overlays
  142.             c. Dynamic Overlays
  143.             d. Dynamic Linking
  144.             e. Virtual Overlays
  145.             f. Symbol Management
  146.  
  147.         3.  Linking tips for productivity and project management
  148.             a. Pre-linked Libraries
  149.             b. Dynamic Linking
  150.             c. Incremental Linking
  151.             d. Speed-Linking
  152.             e. Library-Module Linking
  153.  
  154.         4.  Feature, price, performance comparison and chart
  155.             a. RTLINK, RTLINK-5.0, RTLINKplus
  156.             b. PLINK86s87, PLINK86plus
  157.             c. BLINKER
  158.             d. ALINK
  159.             e. TLINK
  160.             f. MS-LINK
  161.             g. WARPLINK
  162.             h. NOLINK
  163.             i. dCLIP, dCLIPRUN
  164.  
  165.         5.  Choosing a linker for your projects
  166.             a. Case studies of 5 projects
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.                   Page 3  - Copyright (c) DONNAY Software
  196.  
  197.  
  198.  
  199.          ════════════════════════════════════════════════════════════════
  200.  
  201.                            Introduction/Background
  202.  
  203.          ════════════════════════════════════════════════════════════════
  204.  
  205.  
  206.          What is linking?
  207.  
  208.          Linkers are a subject which most Clipper programmers don't
  209.          like to talk about because of a "fear" that the technology
  210.          will be too sophisticated to understand.  The process of
  211.          linking is no more sophisticated than the compiler itself, it
  212.          is just done at a lower level and produces machine-readable
  213.          code.   It is really the compiler which produces the machine
  214.          readable code, but the linker has the responsibility of insuring
  215.          that the compiled code is accessible or "linked" to other
  216.          code segments.  Linking or "fixing up" references made by the
  217.          the code to external variables and functions is necessary to
  218.          insure that the program will address or call other programs,
  219.          including DOS functions.
  220.  
  221.          Linking can be accomplished at many different stages in the
  222.          development or running of an application.  Most linking occurs at
  223.          the time that an .EXE file is created.  This is usually the most
  224.          sophisticated and time consuming of linking processes.  Linking
  225.          also occurs during "load-time" when an application is being
  226.          loaded into memory for execution.  Even DOS has a built-in linker.
  227.          It fixes up references to specific code segments in an .EXEcutable
  228.          file at the time that it loads the .EXE into memory.  Some linkers
  229.          provide additional load-time linking by using pre-link libraries
  230.          and fixing up references between several files at load-time.
  231.          Other linkers are "dynamic" and load code into memory during
  232.          the running of the application.   Each one of these linking
  233.          techniques provides a specific advantage to the developer.  If
  234.          you don't understand what these advantages are, your development
  235.          projects are probably not "state-of-the-art" and may be lacking
  236.          at some level of performance, usually, in the management of
  237.          memory at runtime.
  238.  
  239.          A linker's basic job is to combine objects which have been
  240.          compiled separately.  Objects contain symbols of three types:
  241.  
  242.          a.  PUBLIC symbols - those symbols which are callable from
  243.                               other objects
  244.  
  245.          b.  STATIC symbols - those symbols which are callable only
  246.                               from within the same object
  247.  
  248.          c.  UNDEFINED symbols - symbols which exist in other objects
  249.                               and are referenced or used by this object
  250.                               (also referred to as EXTERNAL symbols).
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.                   Page 4  - Copyright (c) DONNAY Software
  261.  
  262.  
  263.  
  264.          The linker "resolves" an object's external symbols by scanning
  265.          the other objects public lists either in their object files or
  266.          in library cross-reference indexes.  Linkers usually accomplish
  267.          this task in "2 passes".  The first pass is to locate all the
  268.          symbols by reading the symbol references into memory from all the
  269.          object files and libraries and assigning a segment address to
  270.          each symbol.  The second pass is the actual "fixing up" of the
  271.          symbols and generation of the .EXEcutable program.  During pass 2,
  272.          the linker searches all the object files and libraries again to
  273.          see if one contains a PUBLIC definition for each unresolved
  274.          symbol.  When it finds one, it links the object by assigning an
  275.          address or "fixing-up" the reference from the calling symbol to
  276.          the called symbol.  If none of an object's PUBLIC symbols are
  277.          referenced by another object, that object is not linked into the
  278.          .EXEcutable.
  279.  
  280.  
  281.          GLOSSARY of Linking Terminology
  282.  
  283.  
  284.          .EXEcutable file - A linked program that the operating system
  285.                             can execute.
  286.  
  287.          OBJECT file - A file produced by the compiler used as an input
  288.                        file by the linker.  Also referred to as a
  289.                        relocatable file because it contains code that can
  290.                        be modified by the linker to execute at any memory
  291.                        address.
  292.  
  293.          MODULE -      Another term of reference for an OBJECT.  A module
  294.                        name is assigned by the compiler to each object
  295.                        so it can be referenced in libraries.
  296.  
  297.          SECTION -     A section is a unit of linked, executable code for
  298.                        handling by the overlay manager.  A section is
  299.                        usually an overlay - a portion of the executable
  300.                        file that is loaded into memory as a single unit.
  301.  
  302.          SEGMENT -     A piece of code or data that is manipulated by the
  303.                        linker as an indivisble unit.
  304.  
  305.          PUBLIC  -     Segments of code or data that can be combined
  306.          SEGMENTS      with other segments of the same segment and class
  307.                        name to occupy adjacent locations in memory.
  308.  
  309.          PRIVATE -     Segments of code or data that cannot be
  310.          SEGMENTS      combined with other segments to occupy adjacent
  311.                        memory locations.
  312.  
  313.          OVERLAY -     A section of code or data that shares all or part
  314.                        of its memory allocation with other sections.
  315.  
  316.          LIBRARY -     A file containing relocatable modules which are
  317.                        individually available to the linker.   Libraries
  318.                        usually include indexes of PUBLIC symbols.
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.                   Page 5  - Copyright (c) DONNAY Software
  326.  
  327.  
  328.  
  329.          SYMBOL -      The assigned name for a value that is a constant
  330.                        (absolute symbol) or the address of a program
  331.                        component (relative symbol).
  332.  
  333.          PUBLIC -      A symbol whose relative address is designated by
  334.          SYMBOL        the compiler to be available for modules other than
  335.                        the module that defines it.
  336.  
  337.          STATIC -      A symbol whose relative address is designated by
  338.          SYMBOL        the compiler to be available only for the module
  339.                        that defines it.
  340.  
  341.          EXTERNAL -    A symbol that is not defined in a module that
  342.          SYMBOL        references it.  The linker "fixes" these references
  343.                        when their values become known.
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.                   Page 6  - Copyright (c) DONNAY Software
  391.  
  392.  
  393.          ════════════════════════════════════════════════════════════════
  394.  
  395.                       Linking Tips for Memory-Management
  396.  
  397.          ════════════════════════════════════════════════════════════════
  398.  
  399.  
  400.          In almost all cases, memory management is accomplished by the
  401.          use of "overlays".   Many Clipper programmers have been reluctant
  402.          to use overlay linkers because they heard how difficult they are
  403.          to manage.  This may have been true in the past, but overlay
  404.          managers have become much more sophisticated in the past two
  405.          years.  In order to understand how to choose a linker for memory
  406.          management, we must first examine the methods in which linkers
  407.          accomplish this task.  They are as follows:
  408.  
  409.          1. Static Overlays
  410.          2. Reloadable Overlays
  411.          3. Dynamic Overlays
  412.          4. Dynamic Linking
  413.          5. Virtual Overlays
  414.          6. Symbol Management
  415.          7. Memory Packing
  416.          8. Memory Allocation
  417.  
  418.  
  419.          STATIC OVERLAYS
  420.  
  421.          "Static overlays" are segments of code which are placed into
  422.          overlay sections that occupy the same memory space at runtime.
  423.          Static overlay segments usually look like this in your link
  424.          file:
  425.  
  426.            # area 1
  427.            BEGINAREA
  428.              SECTION FILE A
  429.              SECTION FILE B
  430.              SECTION FILE C
  431.            ENDAREA
  432.  
  433.            # area 2
  434.            BEGINAREA
  435.              SECTION FILE D
  436.              SECTION FILE E
  437.              SECTION FILE F
  438.            ENDAREA
  439.  
  440.          If your linker uses static overlays (PLINK86, PLINK86plus),
  441.          then you must be sure that you properly place your objects in
  442.          the overlay segments to prevent computer "lock-up" or "crashing"
  443.          at runtime.  In the above example, any procedure or function in
  444.          FILE A may call any procedure or function in FILE D - F because
  445.          they are in different areas, however if a function in FILE A
  446.          calls a procedure or function in FILE B, then your program will
  447.          crash as soon as the program returns to FILE A because FILE A
  448.          was removed from memory to load FILE B.
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.                   Page 7  - Copyright (c) DONNAY Software
  456.  
  457.  
  458.  
  459.          Overlay management with "static overlays" is the most time-
  460.          consuming because it requires extensive analysis of the
  461.          structure of the program to insure that the modules are placed
  462.          properly in the overlay areas.
  463.  
  464.  
  465.  
  466.          RELOADABLE OVERLAYS
  467.  
  468.          "Reloadable overlays" are segments of code which are placed
  469.          into overlay sections that occupy the same memory space at
  470.          runtime, however the "calling  module" is automatically
  471.          "reloaded" into memory when returning from the "called module".
  472.  
  473.          Reloadable overlay segments usually look like this in your link
  474.          file:
  475.  
  476.            RELOAD FAR 200
  477.            # area 1
  478.            BEGINAREA
  479.              SECTION FILE A
  480.              SECTION FILE B
  481.              SECTION FILE C
  482.            ENDAREA
  483.  
  484.            # area 2
  485.            BEGINAREA
  486.              SECTION FILE D
  487.              SECTION FILE E
  488.              SECTION FILE F
  489.            ENDAREA
  490.  
  491.          If your linker allows reloadable overlays (RTLINK, RTLINK+),
  492.          then you are not in danger of "lockup" in the event that a
  493.          procedure or function in FILE A calls a function or procedure
  494.          in FILE B because FILE A will be reloaded into memory on return
  495.          from FILE B.
  496.  
  497.          Your application will experience slowing, however, if overlays
  498.          are not structured properly, because each time an overlay is
  499.          reloaded the application must go to disk.  In the above example
  500.          if a function in FILE A repetitiveley calls a function in FILE B
  501.          then your application will be very "disk intensive" and will run
  502.          slowly.  If a function in FILE A repetitively calls a function
  503.          in FILE D there will be no slowing at all because both modules
  504.          will remain in memory.
  505.  
  506.          Overlay management with "reloadable overlays" is the less time-
  507.          consuming than "static overlays" and provides an additional
  508.          advantage of allowing more modules to be overlayed, thereby
  509.          saving additional memory usage.  Overlay managers which provide
  510.          "RELOAD" commands usually limit the automatic reloading to
  511.          either "NEAR" or "FAR" calls.  The Clipper-compiler mixes both
  512.          near and far calls therefore Clipper-compiled code cannot be
  513.          overlayed in this manner.  The generic versions of RTLINK,
  514.          RTLINK+ and PLINK86plus all support overlay reloading, but the
  515.          modules overlayed in this manner must be C/ASM modules from the
  516.          CLIPPER/EXTEND libraries or third-party libraries, NOT
  517.          clipper-compiled objects.
  518.  
  519.  
  520.                   Page 8  - Copyright (c) DONNAY Software
  521.  
  522.  
  523.  
  524.          DYNAMIC OVERLAYS
  525.  
  526.          "Dynamic Overlays" are segments of code which are loaded into a
  527.          "memory pool" at runtime.   Dynamic overlay segments usually
  528.          look like this in your link file:
  529.  
  530.            # only 1 area needed
  531.            BEGINAREA
  532.              SECTION FILE A
  533.              SECTION FILE B
  534.              SECTION FILE C
  535.              SECTION FILE D
  536.              SECTION FILE E
  537.              SECTION FILE F
  538.            ENDAREA
  539.  
  540.          In the above example, if a function in FILE A calls a function
  541.          in FILE B, then FILE B is loaded into the memory pool along with
  542.          FILE A and the memory pool is "dynamically" managed to insure
  543.          that modules which call each other repetitively will remain in
  544.          memory to improve speed performance.  Some dynamic overlay
  545.          linkers also provide automatic "reloading" to insure that the
  546.          application will always have sufficient memory in the pool.
  547.          Modules which don't need to be in the memory pool will be
  548.          removed to allow room for others at runtime.
  549.  
  550.          Dynamic overlay linkers (ALINK, BLINKER, WARPLINK) offer the
  551.          advantage of simpler overlay design and usually better memory
  552.          management.  Some also have a tendency to "fragment" the
  553.          Clipper free memory pool because they share the heap with the
  554.          Clipper application rather than allocating a separate dos memory
  555.          area.  This can cause applications to run out of memory after
  556.          prolonged running of the application if there is not sufficient
  557.          memory overhead at the start of the application.  Some dynamic
  558.          overlay linkers also support overlay management by "frequency of
  559.          usage".  If a module is called often during the running of an
  560.          application, it will remain in the overlay pool rather than
  561.          being "swapped out" to load other overlays.  This insures
  562.          optimum runtime performance.
  563.  
  564.          Dynamic-overlay linkers such as WARPLINK and BLINKER both
  565.          make a disclaimer in their documentation requiring that the
  566.          objects being overlayed are "well-behaved".   There is no
  567.          specification for "well-behaved" objects, but there is a
  568.          specification for "well-behaved" linkers.   It appears that
  569.          these new "dynamic overlay" linkers are hoping to change the
  570.          rules for compilers so they will be compatible with the
  571.          limitations of their technology.  As a third-party products
  572.          developer, this is aggravating to me because it is now
  573.          necessary to develop a special release of the dCLIP
  574.          libraries for compatability with these linkers.  In the long
  575.          run, I believe these linkers will survive only if they work
  576.          flawlessly with existing libraries.
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.                   Page 9  - Copyright (c) DONNAY Software
  586.  
  587.  
  588.          DYNAMIC LINKING
  589.  
  590.          True "Dynamic linkers" should not be confused with "Dynamic
  591.          Overlay" linkers.  Dynamic overlay linkers perform all the
  592.          linking and fix-ups for the entire application at one time
  593.          and then produce an .EXEcutable program.  True "dynamic linkers"
  594.          perform all the linking and fix-ups at "runtime" by linking
  595.          from your .OBJ files or "dynamic-libraries" during the
  596.          running of the application.
  597.  
  598.          Dynamic linkers (dCLIP, dCLIPRUN, NOLINK) provide the best
  599.          memory-management for very large applications.   All other forms
  600.          of linkers still require that each symbol reference in the
  601.          application be resolved at link time and assigned an address in
  602.          the "root" memory area.  Even the most sophisticated of overlay
  603.          management schemes cannot eliminate the need to create this
  604.          "symbol table", therefore the memory usage of a program will
  605.          always increase proportionally with the number of symbols in the
  606.          .OBJects regardless of the overlay technique.
  607.  
  608.          Dynamic linkers solve this problem by adding to the "root-
  609.          memory" symbol table only if a function or procedure is called
  610.          at runtime.  Dynamic linkers will load the executable portion of
  611.          the code into an "object pool" and perform the symbol fixups in
  612.          the main heap area.  Once a symbol has been added to the heap,
  613.          it will stay in memory even after returning from the called
  614.          function, however the executable code may be removed from the
  615.          object pool to make space for new objects which may be called
  616.          by the application.
  617.  
  618.          Dynamic linkers also allow linking from sets of dynamic
  619.          libraries during the running of an application therefore large
  620.          applications such as accounting systems can be distributed
  621.          with one .EXE (the "dynamic-link engine") and multiple "dynamic-
  622.          libraries".
  623.  
  624.  
  625.  
  626.          VIRTUAL OVERLAYS
  627.  
  628.          Virtual Overlaying is a technique developed by Pocket Soft,
  629.          Inc. and is being introduced in the special .RTLINK supplied
  630.          with Clipper 5.0.  Unlike "dynamic overlays" which are "read-
  631.          only", virtual overlay managers not only overlay the CODE
  632.          portion of a module, but also the portion of a module which is
  633.          changed during the running of an application - the DATA.  The
  634.          data changes are written out to disk in temporary files which
  635.          are managed during the running of the application.
  636.  
  637.          When executing a program using virtual overlaying, the code is
  638.          paged from disk to memory on a "least recently used" basis.
  639.          This means that code which has not been used for a while is
  640.          overwritten to make room for the new code, leaving frequently
  641.          used code in memory.
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.                   Page 10  - Copyright (c) DONNAY Software
  651.  
  652.  
  653.          Virtual overlay linkers dynamically allocate the size of the
  654.          object pool for paging code in accordance with the memory
  655.          available during the start of the application.  The more memory
  656.          that is available, the less "disk-intensive" the application
  657.          and the better the speed performance.
  658.  
  659.          At the writing of this article, my experience with this type
  660.          of linking is very limited, therefore I cannot make a good
  661.          comparison of this technique to the more conventional methods
  662.          provided by ALINK, BLINKER and WARPLINK.
  663.  
  664.  
  665.  
  666.          SYMBOL-MANAGEMENT
  667.  
  668.          Symbol Management is a technique that can greatly reduce the
  669.          amount of memory overhead in a linked application.  Symbol
  670.          management is a process in which the "symbol table" is managed
  671.          to prevent unneccessary symbols in the main root memory area.
  672.          There is usually very little that a linker can do to resolve
  673.          this problem because the problem is usually caused by the
  674.          compiler and the programmer.   Every compiled object contains
  675.          symbols, constants, code and data.   Overlay linkers can usually
  676.          do a good job of overlaying code and constants but symbols and
  677.          data must be treated differently.  Symbols must always be placed
  678.          in "root" memory for overlay managers to be able to find and load
  679.          the module which contains the called symbol.  Unfortunately,
  680.          most linkers are not sophisticated enough to eliminate the
  681.          "redundancy" of symbols which are placed in root memory.  For
  682.          example, each Clipper-compiled object makes a call to the
  683.          symbol "__PLANKTON".   The symbol "__PLANKTON" is assigned a
  684.          place in the symbol table for EACH Clipper-compiled object even
  685.          though _PLANKTON exists at only one address.   If you have
  686.          100 Clipper-compiled objects, you will have 100 redundant
  687.          entries in this table.   This consumes value memory.  This
  688.          problem can usually be overcome by compiling your .PRG files
  689.          into less (and larger) .OBJects, thereby reducing the symbol
  690.          count.  This can become a delicate balancing act, however, when
  691.          trying to find the proper balance of .OBJ file size verses
  692.          symbol count to make a difference in memory usage.  Increasing
  693.          the .OBJect size may increase the overlay area size thereby
  694.          nullifying the memory savings from the reduced symbols.
  695.  
  696.          ALINK and BLINKER excel in the area of symbol management.
  697.          .EXEcutables created with these "dynamic-overlay" linkers are
  698.          very memory efficient, because they overlay code segments down
  699.          to the "procedure" level rather than the "module" level.  This
  700.          means that you can now compile your large clipper application
  701.          into just a few huge .OBJect files, thereby greatly reducing
  702.          the number of symbols which are placed into "root" memory.
  703.          It is really this "symbol management" of ALINK and BLINKER
  704.          which make them perform well as memory-management linkers
  705.          as much as their overlaying techniques.
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.                   Page 11  - Copyright (c) DONNAY Software
  716.  
  717.  
  718.  
  719.          NOLINK, dCLIP and dCLIPRUN also provide good symbol management
  720.          because they only create symbols when called for during the
  721.          running of the application.  The symbols from a huge report
  722.          that is run once a week will waste valuable memory with other
  723.          linkers, where "dynamic-linking" will create these symbols only
  724.          at the time the report is being run.
  725.  
  726.          This article is basically intended to provide "linking" tips
  727.          for memory-management, however, it is incumbent upon me to
  728.          also offer additional tips on reducing symbol-count in your
  729.          applications which will work with ALL linkers.
  730.  
  731.          a. USE CONSTANTS INSTEAD OF MEMVARS
  732.  
  733.          Clipper memory variables are always treated as "symbols".
  734.          Refrain from using a memory variable if a constant is sufficient.
  735.          For example, an unnecessary symbol can be eliminated by changing
  736.          the code:
  737.  
  738.             escapekey=27
  739.             DO WHILE INKEY()#escapekey
  740.               *clipper code
  741.             ENDDO
  742.  
  743.          to:
  744.  
  745.             DO WHILE INKEY()#27
  746.               *clipper code
  747.             ENDDO
  748.  
  749.  
  750.          b. USE ARRAYS INSTEAD OF MEMVARS
  751.  
  752.          Every different Clipper memvar name creates a "symbol", whereas
  753.          an array name creates only ONE symbol.  The following example
  754.          shows how to save considerable memory in a clipper application
  755.          by reducing the symbol count with an array.
  756.  
  757.          This code produces 5 symbols:
  758.  
  759.              mname=name
  760.              maddress=address
  761.              mcity=city
  762.              mstate=state
  763.              mzip=zip
  764.              @ 1,1 SAY 'Name ' GET mname
  765.              @ 2,2 SAY 'Address' GET maddress
  766.              @ 3,3 SAY 'City' GET mcity
  767.              @ 4,4 SAY 'State' GET mstate
  768.              @ 5,5 SAY 'Zip' GET mzip
  769.              READ
  770.              REPL name WITH mname, address WITH maddress,;
  771.                   city WITH mcity, state WITH mstate, zip WITH mzip
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.                   Page 12  - Copyright (c) DONNAY Software
  781.  
  782.  
  783.  
  784.          This code produces 1 symbol:
  785.  
  786.              PRIVATE gets[5]
  787.              gets[1]=name
  788.              gets[2]=address
  789.              gets[3]=city
  790.              gets[4]=state
  791.              gets[5]=zip
  792.              @ 1,1 SAY 'Name ' GET gets[1]
  793.              @ 2,2 SAY 'Address' GET gets[2]
  794.              @ 3,3 SAY 'City' GET gets[3]
  795.              @ 4,4 SAY 'State' GET gets[4]
  796.              @ 5,5 SAY 'Zip' GET gets[5]
  797.              READ
  798.              REPL name WITH gets[1], address WITH gets[2],;
  799.                   city WITH gets[3], state WITH gets[4], zip WITH gets[5]
  800.  
  801.  
  802.          c.  USE THE SAME NAME MEMVARS WHENEVER POSSIBLE
  803.  
  804.          Again, every "different" Clipper memvar in a module creates
  805.          a symbol.  If an object contains several procedures, use the
  806.          same name for memvars even though they may not perform the same
  807.          or similar functions.   For example, procedure A and procedure B
  808.          both need 5 memvars.  If procedure A declares its memvars with
  809.          5 unique names and procedure B declares its memvars with 5
  810.          unique names, then 10 symbols are used in the linked application.
  811.          To eliminate 5 symbols, make sure that procedure B assigns the
  812.          same name to the memvars as procedure A.   This is not possible
  813.          of course, if the memvars need to be public to both procedures
  814.          and perform different functions, only if they are private.  This
  815.          also may not be practical in all programming situations because
  816.          of the "cryptic" method in which you must treat your memvar
  817.          declarations.  Clipper 5.0 solves this problem and also makes
  818.          it easier to do steps 1 and 2 above by including a language
  819.          "pre-processor" which allows you to program using non-cryptic
  820.          language extensions then convert your code at compile time to
  821.          memory-efficient use of arrays or constants.
  822.  
  823.  
  824.  
  825.          MEMORY-PACKING
  826.  
  827.          Both BLINKER and dCLIP provide an "automatically-called" and
  828.          "user-callable" function which helps to prevent the common memory
  829.          fragmentation caused by Clipper applications.  Some of the
  830.          fragmentation is actually caused by the linkers themselves
  831.          because "dynamic-linking" creates unresolved symbols at runtime.
  832.          These symbols are placed in the Clipper free-pool or "heap" at
  833.          the most prudent location determined by the Clipper memory
  834.          management system.  Once a symbol has been created, it will
  835.          occupy the same memory space forever, therefore it is desirable
  836.          that the symbols all be placed in adjacent memory locations
  837.          rather than "fragmenting" the free pool.
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.                   Page 13  - Copyright (c) DONNAY Software
  846.  
  847.  
  848.  
  849.          "Memory packing" is a technique developed by Steve Steiner and
  850.          was introduced in his product SMARTMEM.  This is a very simple
  851.          process in which unneccesary memory control boundaries are removed
  852.          thereby giving the Clipper application a large contiguous block
  853.          of memory to work with rather many small blocks placed end to end.
  854.          BLINKER calls its memory pack routine at user-definable intervals
  855.          each time an overlay is loaded.  For example, the command BLINKER
  856.          MEMORY PACK 10 will insure that memory is packed every tenth
  857.          time an overlay is loaded.  BLINKER's overlay pool is also
  858.          "flushed" at this time to insure that fragmented code segments
  859.          are also removed.  dCLIP calls its memory-pack function "every"
  860.          time a module is loaded into memory and only "flushes" its overlay
  861.          pool when it cannot find sufficient space to load a new module.
  862.  
  863.  
  864.  
  865.          MEMORY ALLOCATION
  866.  
  867.          Some linkers provide for complete control of memory allocation
  868.          to help the programmer manage the runtime environment of the
  869.          application.
  870.  
  871.          PLINK86 and RTLINK support a STACK command for allocating the
  872.          amount of memory reserved as the call stack.  This is very
  873.          necessary in sophisticated applications which use windowing
  874.          schemes and nest calls many levels deep.  These linkers also
  875.          support a MEMORY command which will define the heap memory to
  876.          allocate to the application in addition to the .EXE load module.
  877.          If this command is not used, then Clipper grabs all the free
  878.          dos memory.  This command is useful to insure that Clipper uses
  879.          only the memory you want it to use.  This memory control can
  880.          also be accomplished with the SET CLIPPER=<memory parameters>
  881.          in your dos environment, but burning it into the .EXE can some-
  882.          times be more useful.
  883.  
  884.          BLINKER provides a very useful feature for burning the SET
  885.          CLIPPER environment into the .EXEcutable program including the
  886.          files parameter.  For example, the command -
  887.          BLINKER EXECUTABLE CLIPPER V10;R32;F39 will eliminate the
  888.          need to use this command in your AUTOEXEC.BAT file.  BLINKER,
  889.          dCLIP and WARPLINK also provide control of the overlay pool size
  890.          to optimize the object memory allocation.
  891.  
  892.          dCLIP follows the same guidelines as any Clipper application
  893.          and allocates memory from the SET CLIPPER environment variable.
  894.          dCLIP also incorporates a "virtual-memory" technique to allow
  895.          calls to other .EXEcutable programs which are larger than the
  896.          available memory.  This "virtual-memory" is any disk device,
  897.          expanded memory, or a network server.  Memory is released from
  898.          the application and saved as a temporary file, then reallocated
  899.          to dos as new free memory for calling the other program.  After
  900.          returning from the called program, the original memory condition
  901.          is restored from the temporary file.
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.                   Page 14  - Copyright (c) DONNAY Software
  911.  
  912.  
  913.          ════════════════════════════════════════════════════════════════
  914.  
  915.                         Linking Tips for Productivity
  916.  
  917.          ════════════════════════════════════════════════════════════════
  918.  
  919.          When using a compiler language such as Clipper, there is no way
  920.          to eliminate the EDIT-COMPILE-LINK cycle.  This is a necessary
  921.          to produce machine-readable code.   There are a variety of new
  922.          linking techniques, however, which reduce this cumbersome task
  923.          to an acceptable, manageable process.
  924.  
  925.          In order to understand how to choose a linker for productivity
  926.          and project management, we must first examine the methods in which
  927.          linkers accomplish this task.  They are as follows:
  928.  
  929.          1. Pre-linked Libraries
  930.          2. Dynamic Linking
  931.          3. Incremental Linking
  932.          4. Speed-Linking
  933.          5. Library-Module Linking
  934.          6. Debugging
  935.  
  936.  
  937.          PRE-LINKED LIBRARIES
  938.  
  939.          NOLINK introduced the concept of pre-linked libraries to the
  940.          Clipper community about 3 years ago.  Shortly after that,
  941.          RTLINK introduced their .RTL (runtime-library) system for all
  942.          languages.
  943.  
  944.          Pre-linked libraries are files which are built from object
  945.          and libraries into and .EXEcutable format.   The only step
  946.          remaining is the "fixing-up" of any references made by the code
  947.          in the pre-linked library to those in the rest of the application.
  948.          Unlike an .EXEcutable program, a pre-linked library cannot be
  949.          run from dos, but instead is used in conjunction with another
  950.          .EXEcutable program.
  951.  
  952.          RTLINK developed their .RTL (runtime-library) system with the
  953.          intent of saving disk-space for applications which use common
  954.          routines.  For example, every Clipper application links in about
  955.          150k of code from the CLIPPER.LIB library into the .EXE program.
  956.          If you have 10 Clipper .EXE programs, then this code redundancy
  957.          will use up 1.5megs of disk space.  RTLINK allows you to build
  958.          a .RTL file which pre-links this "common" code.  The .RTL file
  959.          is then referenced when you create the .EXE program with all
  960.          the "unique" code.  When you run your .EXE program the pre-
  961.          linked .RTL file will be "fixed-up" to the rest of your
  962.          application code each time you startup your program.
  963.  
  964.          NOLINK, dCLIP, and dCLIPRUN use pre-link libraries for a dual
  965.          purpose - disk management and memory management.  These linkers
  966.          provide linking from .DLB files (dynamic-libraries) at "runtime"
  967.          whereas RTLINK's .RTL system is simply a "load-time" linker.
  968.          Linkers which use "true-dynamic" pre-link libraries will only
  969.          link code into memory if it is called by the application that is
  970.          running.  These systems will also "manage" the object pool to use
  971.          a small amount of memory space for large applications.
  972.  
  973.  
  974.  
  975.                   Page 15  - Copyright (c) DONNAY Software
  976.  
  977.  
  978.  
  979.          DYNAMIC-LINKING
  980.  
  981.          Dynamic-linking is also covered under the "Memory Management"
  982.          section because of its inherent memory-management capabilities.
  983.          Dynamic-linking is probably more useful however in its ability
  984.          to provide a "turbo-style" development system.  All other linkers
  985.          require that you QUIT the program being executed to make changes
  986.          to ANY part of the code.  Even the smallest change, such as
  987.          adding a "CLEAR" to clear the screen will require that you
  988.          (1) Quit to dos, (2) Edit your code, (3) Compile the code,
  989.          (4) Link the code and (5) Restart the application.
  990.  
  991.          The NOLINK dynamic-linker eliminates step (4), the Link cycle,
  992.          because it links code into memory from your .OBJect files.  For
  993.          most Clipper developers, just saving the Link step will double
  994.          the programmer's productivity if he/she is using a slow linker
  995.          like ALINK, PLINK86 or RTLINK.
  996.  
  997.          The dCLIP development platform takes the "dynamic-link"
  998.          concept two steps further and also eliminates step (1) and step
  999.          (5) of the EDIT-COMPILE-LINK cycle.  For many applications this
  1000.          is also a great time savings because sometimes it takes a lot of
  1001.          time to "restart" an application and get back into the desired
  1002.          sub-menu to test the changes.  Some sophisticated application
  1003.          development tools such as ARTFUL.LIB must open as many as 25
  1004.          files, build arrays, set relations, etc. before you can even
  1005.          get into the desired menu.  dCLIP helps during development of
  1006.          these larger application systems by allowing the programmer to
  1007.          (1) suspend execution of the program, (2) Call his/her editor,
  1008.          (3) recompiles the changes, (4) automatically de-links the old
  1009.          code and re-links the new codes into memory, (5) return to
  1010.          the program.  This process does not in any way change the
  1011.          program "environment", only the executable portion of the code,
  1012.          thereby saving even more time in getting back to the desired
  1013.          menu to test the changes.
  1014.  
  1015.          dCLIP does have a limitation when being used in this manner.
  1016.          Let's say that procedure A calls procedure B.  The programmer
  1017.          hits the ALT-D hotkey while running procedure B to get to the
  1018.          interactive dot prompt, then calls his editor and changes
  1019.          something in procedure B.  dCLIP will allow the editing and
  1020.          recompiling of the changes, however the procedure B code cannot
  1021.          be replaced in memory until the application returns back to
  1022.          procedure A and then comes back into B.  It is suggested that
  1023.          if a change needs to be made to a procedure on the fly like
  1024.          this, that the programmer go back one menu in the program
  1025.          before hitting the ALT-D hot key.
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.                   Page 16  - Copyright (c) DONNAY Software
  1041.  
  1042.  
  1043.          INCREMENTAL-LINKING
  1044.  
  1045.          Incremental Linking is a process in which only the code which
  1046.          is changed is linked into the new .EXEcutable program.  RTLINK,
  1047.          NOLINK, dCLIP and dCLIPRUN all support incremental linking
  1048.          however, each uses a different concept.
  1049.  
  1050.          RTLINK's concept of incremental linking is to create an
  1051.          information file (.INF) which is generated containing a list
  1052.          of each module in the program along with a checksum and time
  1053.          stamp.  It is with the use of this file that RTLINK is able
  1054.          to tell what has changed in the program.  RTLINK's incremental
  1055.          linker has the disadvantage of causing the .EXEcutable program
  1056.          to grow larger than usual because of wasted space in the output
  1057.          file which is needed to allow for the growth of modules.  A
  1058.          certain amount of extra space (25% is the default) is needed.
  1059.          This is not really a problem because incremental linking is
  1060.          usually done during the development cycle.  The final product
  1061.          can be linked with NOINCREMENTAL to disable the feature and
  1062.          bring the .EXE back down to normal size.
  1063.  
  1064.          NOLINK's incremental linking system must work differently since
  1065.          linking is normally done "on the fly" and is always activated.
  1066.          When running an application under NOLINK and using dynamic-
  1067.          libraries, each time a module is called and needs to be linked
  1068.          into memory, the date and time of the module in the dynamic
  1069.          library is checked against the date and time of the .OBJ file on
  1070.          the disk.  If there is NO .OBJ file, then the module from the
  1071.          library is linked, if there is an .OBJ file with a later date
  1072.          and time then it is linked instead of the module in the library.
  1073.  
  1074.          dCLIP's incremental linking system uses essentially the same
  1075.          technique as NOLINK, except the DCLIP.SYS file allows the
  1076.          programmer to define the location of the .OBJect files so they
  1077.          may exist on another drive in another directory or on the
  1078.          network server.  This makes project management simpler.  dCLIP
  1079.          also allows the programmer to put a memory variable in the start
  1080.          of his/her program to disable the incremental link system,
  1081.          eliminating the constant disk access and date/time comparisions
  1082.          and link only from the libraries thereby improving the speed of
  1083.          operation.  This feature is usually implemented when using
  1084.          dCLIPRUN rather than dCLIP.
  1085.  
  1086.  
  1087.          SPEED LINKING
  1088.  
  1089.          All Clipper programmers want the link part of the EDIT-COMPILE-
  1090.          LINK cycle to go faster.  The general rule of thumb for speed
  1091.          of linking, is:  "The more sophisticated the linker, the longer
  1092.          the link-time".   Overlay linkers such as PLINK86, PLINK86plus,
  1093.          RTLINK and RTLINKplus usally are quite slow because they were
  1094.          developed as "general-purpose" linkers for all languages and
  1095.          must conform to the requirements of all compilers.
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.                   Page 17  - Copyright (c) DONNAY Software
  1106.  
  1107.  
  1108.  
  1109.          Special-purpose linkers such as NOLINK, BLINKER, dCLIP and
  1110.          ALINK were designed to be used with Clipper only therefore
  1111.          they can eliminate many of the checks such as "static-
  1112.          symbols", "checksums", etc. and concentrate on what is needed
  1113.          only for Clipper applications.
  1114.  
  1115.          The fastest linking method is, and will always be, true
  1116.          "dynamic-linking" because only the code that is called by the
  1117.          application at runtime is linked into memory.  Linking from
  1118.          .OBJect modules does take a slight longer time than from
  1119.          pre-linked "dynamic-libraries" and dynamic-link systems often
  1120.          cause a slight "hesitation" when a module is being linked into
  1121.          memory.  This "hesitation" can be milliseconds for small OBJects
  1122.          (1k - 5k) up to up to 1-2 seconds for large objects (30k - 60k).
  1123.  
  1124.          BLINKER is by far the fastest overlay linker which produces an
  1125.          .EXEcutable program.  Jud Cole claims that he will never write
  1126.          in any language other than assembly-language.  BLINKER will
  1127.          usually produce an .EXE in about 1/5 the time of PLINK86 or
  1128.          RTLINK.
  1129.  
  1130.          TLINK 1.0 is even faster than BLINKER but is limited to
  1131.          non-overlay applications.  TLINK was really designed to be used
  1132.          with the Borland compilers and is not a general-purpose linker
  1133.          therefore it does not work with some Clipper applications which
  1134.          use third-party libraries.
  1135.  
  1136.          WARPLINK was so named because it is supposed to be a fast linker.
  1137.          As general-purpose overlay linkers go, it is definately faster
  1138.          than PLINK86 and RTLINK (about 50%), however is cannot compare
  1139.          with BLINKER or TLINK for speed in linking Clipper applications.
  1140.  
  1141.  
  1142.          LIBRARY-MODULE LINKING
  1143.  
  1144.  
  1145.          One of the most useful features I have found in some linkers
  1146.          is the "MODULE" command.  When a linker does not support this
  1147.          command or a library is improperly created to use this command
  1148.          I get very aggravated because it means that my whole development
  1149.          environment is impacted by these limitations.  PLINK86 and
  1150.          RTLINK are examples of linkers which have a level of sophisti-
  1151.          cation to provide this command.
  1152.  
  1153.          The developers of the new, younger linkers, such as ALINK,
  1154.          BLINKER and WARPLINK have not yet matured to the level of wisdom
  1155.          that comes from developing "sophisticated applications".  If
  1156.          their applications were as complicated as some of mine, they
  1157.          would not have ignored this very useful feature in their
  1158.          products.
  1159.  
  1160.          The development team at Nantucket was also short-sighted when
  1161.          they produced the CLIPPER.LIB and EXTEND.LIB libraries and this
  1162.          also added to my frustration.  Brian Russell, the author of
  1163.          Clipper, assures me that this will not be a problem in Clipper
  1164.          5.0.
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.                   Page 18  - Copyright (c) DONNAY Software
  1171.  
  1172.  
  1173.  
  1174.          The MODULE command is very useful in that it allows overlay
  1175.          linkers to place "modules" from libraries into overlays.
  1176.          This is an "undocumented" feature in PLINK86 that very few
  1177.          Clipper programmers know how to use and even when they find out
  1178.          that PLINK86 supports the MODULE command, they can't use it with
  1179.          the CLIPPER.LIB/EXTEND.LIB libraries.
  1180.  
  1181.          When a compiler creates an .OBJect file it also assigns a
  1182.          "module" name for the linker.  The Clipper compiler assigns the
  1183.          same name as the .OBJ file, however many compilers will assign
  1184.          the name of the SOURCE file as the module name including
  1185.          drive letters and directories.   You can organize your Clipper
  1186.          projects by placing all your Clipper objects in libraries
  1187.          with a library manager such as LIB.EXE or PLIB86.EXE then by
  1188.          using the SECTION MODULE <module> command in your link file
  1189.          you can place any module into any overlay area.
  1190.  
  1191.          Example:
  1192.  
  1193.          LIB mylib
  1194.          BEGINAREA
  1195.            SECTION MODULE myfileA,myfileB
  1196.            SECTION MODULE myfileC
  1197.            SECTION MODULE myfileD
  1198.          ENDAREA
  1199.  
  1200.  
  1201.          It is not only incumbent upon linker developers to support
  1202.          this option, but also developers of third-party libraries.
  1203.          Their documentation should include not only the name of the
  1204.          function but the name of the "module" which includes each
  1205.          function so that module can be overlayed.   Nantucket did not
  1206.          realize the value of this feature of PLINK86 in their Summer 87
  1207.          release, otherwise they would have given each module in
  1208.          CLIPPER.LIB and EXTEND.LIB a "unique" name.  Instead, they
  1209.          assigned the same module name to many different objects -
  1210.          _ASM.ASM.  For example, if the DBEDIT module were named
  1211.          "DBEDIT" instead of "_ASM.ASM" and the MEMOEDIT module were
  1212.          named "MEMOEDIT" instead of "_ASM.ASM" then they could be
  1213.          be overlayed with PLINK86 as follows:
  1214.  
  1215.          LIB extend
  1216.          BEGINAREA
  1217.            SECTION MODULE dbedit
  1218.            SECTION MODULE memoedit
  1219.          ENDAREA
  1220.  
  1221.          The MODULE <module> command in PLINK86 and RTLINK requires that
  1222.          <module> exists in one of the declared libraries and that the
  1223.          name is "unique" to that module otherwise the command will be
  1224.          ignored and the module will be linked into the root memory area.
  1225.  
  1226.          dCLIPFUN.EXE is a development platform for CLIPPER and FUNCKY
  1227.          which includes every module from CLIPPER.LIB, EXTEND.LIB and
  1228.          FUNCKY.LIB.  To accomplish this task and still provide
  1229.          sufficient memory for running Clipper applications we needed to
  1230.          overlay much of the CLIPPER libraries and FUNCKY library.
  1231.  
  1232.  
  1233.  
  1234.  
  1235.                   Page 19  - Copyright (c) DONNAY Software
  1236.  
  1237.  
  1238.  
  1239.          Here is how we did it:
  1240.  
  1241.          1. First we extracted all the modules from CLIPPER.LIB and
  1242.             EXTEND.LIB with PLIB86.EXE.  This gave us a set of files
  1243.             with the same name as the original objects which were used
  1244.             to create these libraries.
  1245.  
  1246.          2. Next we rebuilt CLIPPER.LIB and EXTEND.LIB with PLIB86.EXE
  1247.             and told PLIB86.EXE to "MODRENAME" all modules.  This PLIB86
  1248.             command renamed all the modules from "_ASM.ASM" to the name
  1249.             of the file on disk.
  1250.  
  1251.          3. Next using the LIBRA.EXE library utility, we examined the
  1252.             FUNCKY.LIB library and got the names of each Funcky module.
  1253.             We were lucky because Dirk Lesko's compiler assigned unique
  1254.             names to each of his modules.
  1255.  
  1256.          4. Now all we had to do was create a link file:
  1257.  
  1258.             STACK 1024
  1259.             FI dclip,dclipf1,dclipf2,dclipf3,funcky
  1260.             LIB dclipnl,dclip,dclipr,funcky,dcextend,clipper
  1261.             OUTPUT dclipfun
  1262.             RELOAD FAR 300
  1263.             OVERLAY CODE
  1264.             VERBOSE
  1265.  
  1266.             BEGINAREA
  1267.               # Modules from CLIPPER.LIB and EXTEND.LIB
  1268.               SECTION MODULE memoedit,memotran
  1269.               SECTION MODULE memoline,memoread,memowrit,mlcount,mlpos
  1270.               SECTION MODULE achoice,ascan,adir,afields,asort,ains,acopy,
  1271.               MODULE afill,gete
  1272.               SECTION MODULE report
  1273.               SECTION MODULE dbedit
  1274.               SECTION MODULE icreate,sort,sortof,examplea,examplec,recsize
  1275.               # Modules from DCLIPNL.LIB
  1276.               SECTION MODULE c_call,global,parseobj,msg,kern,omalloc,mtbuf,
  1277.                       MODULE mtobj,screen
  1278.               # Modules from DCLIP.LIB
  1279.               SECTION MODULE overlay,over_22,over_24,over_6
  1280.             ENDAREA
  1281.  
  1282.             BEGINAREA
  1283.               # Modules from CLIPPER.LIB and EXTEND.LIB
  1284.               SECTION MODULE ntx
  1285.               # Modules from DCLIP.LIB
  1286.               SECTION MODULE dbgbrow,dbgio,dbgscrn,dcega43,dcvga50,videoid,dckey
  1287.               SECTION MODULE _dcinit
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298.  
  1299.  
  1300.                   Page 20  - Copyright (c) DONNAY Software
  1301.  
  1302.  
  1303.               # Funcky modules
  1304.               SECTION MODULE aaverage.c,amax.c,amaxn.c,amin.c,atotal.c,
  1305.               beep.asm,border.asm,checkdat.asm,checktim.asm,clusters.asm,
  1306.               coldboot.asm,cominit.asm,comoff.asm,comon.asm,comset.asm,
  1307.               comswap.asm,cputype.asm,crash.asm,csrbot.asm,csrtop.asm,
  1308.               curdir.asm,curdrive.asm,datetype.asm,decimals.asm,default.asm,
  1309.               iszip.asm,delimete.asm,delvolum.asm,disksize.asm,diskspac.asm,
  1310.               dosmem.asm,dosvers.c,drivestr.asm,egamem.asm,execute.asm,
  1311.               expmem.asm,extmem.asm,ferase.asm,ferror.asm,fgetattr.asm,
  1312.               fgetdate.asm,fgettime.asm,fhide.asm,filecoun.asm,findfirs.asm
  1313.  
  1314.               SECTION MODULE flen.asm,fprotect.asm,fre.asm,frename.asm,
  1315.               fsetattr.asm,fsetdate.asm,funhide.asm,funprote.asm,getmode.asm,
  1316.               getpage.asm,getvolum.asm,handles.asm,initscre.asm,insert.asm,
  1317.               iscom.asm,isdir.asm,isdisk.asm,isdrive.asm,isems.asm,
  1318.               isfixed.asm,isfloppy.asm,ishandle.asm,islpt.asm,ismouse.asm,
  1319.               isqueue.asm,kbdstat.asm,lastdriv.asm,lprint.asm,lptset.asm,
  1320.               lptswap.asm,margin.asm,maxcol.asm,maxhandl.asm,mediatyp.asm,
  1321.               mono.asm,mouse.asm,m_pen.asm,m_reset.asm,m_restor.asm,
  1322.  
  1323.               SECTION MODULE m_save.asm,m_speed.asm,m_setpag.asm,
  1324.               m_getpag.asm,ndptype.asm,nexthand.asm,nstuff.asm,palette.asm,
  1325.               prnreset.asm,prnstatu.asm,program.asm,prtscr.asm,q_cancel.asm,
  1326.               q_delete.asm,q_file.asm,q_restar.asm,q_status.asm,q_submit.asm,
  1327.               removeab.asm,romdate.asm,sectors.asm,sectorsi.asm,setdrive.asm,
  1328.               sethandl.asm,setlogic.asm,setmode.asm,setpage.asm,setsnow.asm,
  1329.               setscree.asm,settime.asm,systype.asm,vidtype.asm,warmboot.asm,
  1330.               prnhandl.asm,althandl.asm,setvolume.asm,q_hold.asm,
  1331.               filesize.asm,drivetyp.asm,turbo.asm,typeahea.asm,chdir.asm
  1332.  
  1333.             ENDAREA
  1334.  
  1335.  
  1336.          DEBUGGING
  1337.  
  1338.          Linkers are becoming much more sophisticated in their ability
  1339.          to provide debugging information while running an application.
  1340.          Most often, the ability of the linker to provide adequate
  1341.          debugging information is dependent on the information the
  1342.          compiler provides to the linker in the object code.  Some
  1343.          linkers are very sophisticated in being able to provide
  1344.          debugging at the symbol-level even though the compiler does
  1345.          not provide for this.  Microsoft's LINK.EXE and PocketSoft's
  1346.          RTLINKplus are the only linkers that support Microsoft
  1347.          CODE-VIEW for getting into a Clipper application and finding out
  1348.          what is happening at the low levels.   RTLINKplus is the only
  1349.          "overlay" linker with this feature.
  1350.  
  1351.          Most linkers provide a "DEBUG" command.  This is not a very
  1352.          sophisticated debugging feature and is usually supported in a
  1353.          manner that is aggravating to the person trying to debug.  The
  1354.          DEBUG command in PLINK86 and RTLINK will force the overlay
  1355.          manager to report to the screen each time an overlay segment is
  1356.          being accessed.  Sometimes it is necessary to use this command
  1357.          to figure out overlay strategies.  The annoying thing is that
  1358.          both PLINK86 and RTLINK simply put the message on the screen at
  1359.          line 24 and then scroll the screen up one line.   If you are
  1360.          trying to debug a program which puts information on the screen
  1361.          this can be very aggravating.  Also, once the DEBUG switch is
  1362.          ON, you can't turn it OFF without relinking the application.
  1363.  
  1364.  
  1365.                   Page 21  - Copyright (c) DONNAY Software
  1366.  
  1367.  
  1368.  
  1369.          NOLINK provides a feature that allows the programmers to see
  1370.          a "snapshot" of the object overlay pool at any time while
  1371.          running the program.  This provides useful information by
  1372.          showing the operator which modules are currently in memory,
  1373.          which modules have been linked from .OBJ files and which
  1374.          have been linked from .DLBs (dynamic-libraries), which modules
  1375.          are currently "running" and the size, date and time of each
  1376.          module.
  1377.  
  1378.          dCLIP provides the same feature as NOLINK but also offers a
  1379.          TRACE feature which writes debug information to a DCTRACE file
  1380.          with the procedure name, line number and the current value of
  1381.          any expression loaded into the "WATCH" table.  This DCTRACE
  1382.          file can then be "merged" with your source code to give you
  1383.          a very useful "histogram" of your application.  dCLIP also
  1384.          provides a "source-level" debugger and an "interactive, dot-
  1385.          prompt style" debugger which use nearly the entire Clipper-
  1386.          language as a debugging tool.  Since the Clipper libraries
  1387.          are linked into the dCLIP engine, every Clipper function may
  1388.          be used to help debug a Clipper application.  This kind of
  1389.          debug system lets you select work areas, open and close data
  1390.          files, create memvars and arrays, browse files, jump to dos,
  1391.          change your environment, load other libraries, etc.
  1392.  
  1393.          BLINKER provides a "PROFILING MODE" which is really a User-
  1394.          defined function.  This feature is basically a set of "hooks"
  1395.          for the Clipper programmer to write his/her own debug system
  1396.          to determine the activity of the overlay manager for optimizing
  1397.          the performance of the application.
  1398.  
  1399.  
  1400.  
  1401.  
  1402.  
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430.                   Page 22  - Copyright (c) DONNAY Software
  1431.  
  1432.  
  1433.  
  1434.          ════════════════════════════════════════════════════════════════
  1435.  
  1436.                              PRODUCT COMPARISONS
  1437.  
  1438.          ════════════════════════════════════════════════════════════════
  1439.  
  1440.  
  1441.          PLINK86s87
  1442.  
  1443.          Current Version - Clipper Summer 87
  1444.  
  1445.          List Price - Supplied with Clipper Summer 87
  1446.  
  1447.          PLINK86s87 is the linker provided with Clipper and is
  1448.          compatible with all Clipper-compiled objects, Clipper-compiled
  1449.          libraries, the Clipper libraries, and all third-party libraries.
  1450.          PLINK86 is a "static overlay" linker and requires careful
  1451.          overlay design.
  1452.  
  1453.          PLINK86s87 supports overlaying of "MODULES" from libraries to
  1454.          allow you to take simplify your development environment and
  1455.          work from libraries rather than .OBJ files.
  1456.  
  1457.          PLINK86s87 is a mature, reliable linker which is sophisticated
  1458.          enough to handle linking of most large Clipper applications which
  1459.          requires overlays, provided that you are patient enough to
  1460.          analyze your code and structure your overlays properly.
  1461.  
  1462.  
  1463.  
  1464.          PLINK86plus
  1465.  
  1466.          Current Version - 2.22
  1467.  
  1468.          List Price - $295.00
  1469.  
  1470.          PLINK86plus is a generic, general-purpose version of PLINK86 and
  1471.          includes extra features such as a "RELOAD" command to support
  1472.          "overlay reloading".  It's "reloadable" overlay feature is
  1473.          limited however to C/ASM object files and library modules.  All
  1474.          of the modules in CLIPPER.LIB, EXTEND.LIB and most third-party
  1475.          libraries are reloadable because they were written in C/ASM.
  1476.          All Clipper-compiled modules must be placed in "static-overlays"
  1477.          in the same manner as PLINK86s87.
  1478.  
  1479.          PLINK86plus also includes an overlay design utility which scans
  1480.          your application objects and helps you develop an overlay
  1481.          strategy which will prevent lockup at runtime and design the
  1482.          most memory-efficient architecture.  Caution - this type of
  1483.          utility is not very useful in applications which call programs
  1484.          through indirect symbol references such as "macros" because
  1485.          they have no way of knowing that a call has been made until the
  1486.          programming is actually running.
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.                   Page 23  - Copyright (c) DONNAY Software
  1496.  
  1497.  
  1498.  
  1499.          RTLINK
  1500.  
  1501.          Current Version - 3.1
  1502.  
  1503.          List Price - $295.00
  1504.  
  1505.          RTLINK.EXE is a general-purpose MS-DOS linker for all compiler
  1506.          languages, assembly languages, and Clipper.   RTLINK is compatible
  1507.          with the Clipper libraries, Clipper-compiled objects and all
  1508.          third-party libraries.  RTLINK is is also compatible with all
  1509.          PLINK86 commands and will link your applications from your
  1510.          existing PLINK86 *.LNK files.
  1511.  
  1512.          RTLINK is both a "static" overlay linker and a "reloadable"
  1513.          overlay linker.  It's "reloadable" overlay feature is limited
  1514.          however to C/ASM object files and library modules.  All of the
  1515.          modules in CLIPPER.LIB, EXTEND.LIB and most third-party n
  1516.          libraries are reloadable because they were written in C/ASM.
  1517.          All Clipper-compiled modules must be placed in "static-overlays"
  1518.          in the same manner as PLINK86.
  1519.  
  1520.          RTLINK also allows use of .RTLs (runtime libraries) to help
  1521.          reduce disk space usage of applications.   RTLINK is a mature,
  1522.          reliable linker which is sophisticated enough to handle linking
  1523.          of any large application which requires overlays.
  1524.  
  1525.          RTLINK has a "VIRTUAL OVERLAY" feature which provides the added
  1526.          feature of including the DATA portion of object modules into
  1527.          overlay segments, by writing the data to a "virtual overlay"
  1528.          on disk and restoring the data whenever the overlayed code is
  1529.          reloaded into memory.
  1530.  
  1531.          RTLINK supports overlaying of "MODULES" from libraries to
  1532.          allow you to take simplify your development environment and
  1533.          work from libraries rather than .OBJ files.
  1534.  
  1535.          RTLINK is an excellent linker for all applications, but
  1536.          particularly for applications which are C/ASM code intensive
  1537.          and NOT Clipper-code intensive.
  1538.  
  1539.  
  1540.  
  1541.          RTLINKplus
  1542.  
  1543.          RTLINKplus is an even more sophisticated version of RTLINK which
  1544.          offer much more power in the area of debugging tools.  RTLINKplus
  1545.          includes MicroSoft CODE-VIEW support, a sophisticated runtime
  1546.          PROFILER, and an overlay analyzing system which scans .MAP files
  1547.          and produces graphs of overlay usage to help determine the
  1548.          efficiency of your overlay structures.
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.                   Page 24  - Copyright (c) DONNAY Software
  1561.  
  1562.  
  1563.  
  1564.          RTLINK-5.0
  1565.  
  1566.          RTLINK-5.0 is a custom version of RTLINK which supports all the
  1567.          basic features of RTLINK but with two important new features:
  1568.  
  1569.          1. Automatic Clipper-code overlaying - this feature uses a
  1570.             "dynamic-overlaying" technique which automatically manages
  1571.             Clipper-code overlays in an overlay pool at runtime.
  1572.  
  1573.          2. Incremental linking - this feature provides a faster link
  1574.             cycle than normal linking by maintaining a work file which
  1575.             is a history of past linking sessions.  This work file is
  1576.             then used to insure that only the code "changed" since the
  1577.             last link session is linked into the new executable.
  1578.  
  1579.  
  1580.  
  1581.          ALINK
  1582.  
  1583.          Current Version - 1.08
  1584.  
  1585.          List Price - $179.00
  1586.  
  1587.          ALINK.EXE is a linker specially designed for Clipper
  1588.          applications.   ALINK is compatible with the Clipper libraries
  1589.          and all third-party libraries.  ALINK is also compatible with
  1590.          many PLINK86 commands and will link your applications from your
  1591.          existing PLINK86 *.LNK files with some modifications.
  1592.  
  1593.          ALINK is a "dynamic overlay" linker which provides dynamic
  1594.          overlays for Clipper-compiled object files only.  ALINK will
  1595.          NOT overlay from .LIBrary files therefore all functions from
  1596.          .LIB files will be linked into the ROOT memory area.
  1597.  
  1598.          ALINK is the only linker which is NOT a stand-alone linking
  1599.          system.  It is instead an overlay "pre-processor" which
  1600.          extracts all the code segments from the Clipper-compiled objects
  1601.          down to the function or procedure level, creates an .OVL file
  1602.          of Clipper-executable code, then creates a set of .SYM (symbol)
  1603.          files which are used by PLINK86 or Microsoft LINK to complete
  1604.          the symbol "fix-ups" and generate the .EXEcutable program.
  1605.  
  1606.          ALINK also includes a replacement for OVERLAY.LIB which is the
  1607.          "dynamic overlay" manager.  This manager is linked into the
  1608.          .EXEcutable programs and manages the dynamic overlaying of all
  1609.          the Clipper code.  ALINK uses the Clipper free pool to link its
  1610.          executable code segments, therefore it is recommended that you
  1611.          use a memory-packing utility and call the AL_FLUSH() function
  1612.          regularly in your ALINK-ed programs to reduce memory fragmentation.
  1613.  
  1614.          ALINK is an excellent linker for applications which are
  1615.          Clipper-code intensive.  If you use many functions from third-
  1616.          party libraries, then ALINK will not allow these to be
  1617.          overlayed.
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.                   Page 25  - Copyright (c) DONNAY Software
  1626.  
  1627.  
  1628.  
  1629.          BLINKER
  1630.  
  1631.          Current Version - 1.1
  1632.  
  1633.          List Price - $179.00
  1634.  
  1635.  
  1636.          BLINKER.EXE is a linker specially designed for Clipper
  1637.          applications.
  1638.  
  1639.          BLINKER is compatible with the Clipper libraries, and all third-
  1640.          party libraries.  BLINKER is also compatible with many PLINK86
  1641.          commands and will link your applications from your existing
  1642.          PLINK86 *.LNK files with some modifications.
  1643.  
  1644.          Like ALINK,  BLINKER is a "dynamic overlay" linker which provides
  1645.          dynamic overlays for Clipper-compiled objects and "some" C/ASM
  1646.          objects.  BLINKER will allow overlaying of entire libraries
  1647.          with the "ALLOCATE" command.  This is not always a useful feature
  1648.          because very few libraries have modules which are ALL compatible
  1649.          with BLINKER.  BLINKER requires that C/ASM modules be "well-
  1650.          behaved".  It is not completely clear at this time what "well-
  1651.          behaved" means, however, some libraries appear to fall into this
  1652.          category.  The EXTEND.LIB library is an example of a well-behaved
  1653.          library, therefore, it may be ALLOCATEd in an overlay section.
  1654.  
  1655.          BLINKER's dynamic overlay manager works excellently with
  1656.          Clipper-compiled code and the EXTEND.LIB library.  Once you
  1657.          start experimenting with other libraries, you may find that it
  1658.          is not worth the effort to go any further.  Some third-party
  1659.          library developers such as FUNCKY, FLIPPER, etc. have released
  1660.          special versions of their libraries which are overlayable.
  1661.          BLINKER's "well-behaved" disclaimer in their manual is more
  1662.          of an indictment of BLINKER's behavior, not the third-party
  1663.          products behavior.  As of the writing of this article, BLINKER's
  1664.          "dynamic-overlay" manager has experienced problems with modules
  1665.          which are compiled using "optimization" and also with modules
  1666.          which use STATIC symbols.  These are valid compiler features
  1667.          and it is incumbent upon the developer's of BLINKER to support
  1668.          this capability in their linker rather than expect all the
  1669.          third-party developers to change their products.  Jud Cole
  1670.          has assured me that he intends to upgrade BLINKER to handle
  1671.          the level of sophistication which is necessary to be able to
  1672.          use BLINKER on more complicated projects.  Until then, I can
  1673.          recommend BLINKER only for projects which are Clipper-code
  1674.          intensive.  Be careful when trying to overlay third-party
  1675.          libraries.
  1676.  
  1677.          Even with these limitations, BLINKER provides the best memory
  1678.          management solution for Clipper-code intensive .EXEcutable
  1679.          applications.  BLINKER is not a simple linker.  It also imbeds
  1680.          functions into the linked program which are called between
  1681.          loading of overlay segments for "memory-packing" to help reduce
  1682.          the memory fragmentation caused by "dynamic-overlaying".  This may
  1683.          conflict with any memory-management system you may have built into
  1684.          your application and should be taken into consideration.
  1685.  
  1686.  
  1687.  
  1688.  
  1689.  
  1690.                   Page 26  - Copyright (c) DONNAY Software
  1691.  
  1692.  
  1693.          BLINKER evolved from ALINK's technology therefore it accomplishes
  1694.          its "dynamic-overlaying" in much the same manner, however it is
  1695.          a stand-alone linker and is 5 to 10 times faster than ALINK in
  1696.          producing an executable program.
  1697.  
  1698.  
  1699.  
  1700.          WARPLINK
  1701.  
  1702.          Current version - 1.03b
  1703.  
  1704.          List Price - $149.95
  1705.  
  1706.          WARPLINK is a general-purpose linker designed for "dynamic-
  1707.          overlay" applications.
  1708.  
  1709.          WARPLINK is compatible with the Clipper libraries, and all
  1710.          third-party libraries.  WARPLINK is NOT compatible with PLINK86
  1711.          commands and will NOT link your applications from your existing
  1712.          PLINK86 *.LNK files.
  1713.  
  1714.          WARPLINK is a "dynamic overlay" linker which provides dynamic
  1715.          overlays for Clipper-compiled objects and "some" C/ASM objects.
  1716.          WARPLINK will allow overlaying of called modules from complete
  1717.          libraries by including the library name in (parenthesis).
  1718.  
  1719.          Like BLINKER, WARPLINK requires that C/ASM modules be "well-
  1720.          behaved".  Because WARPLINK is a general-purpose linker it is
  1721.          more compatible with third-party libraries than BLINKER,
  1722.          however it does not produce as memory-efficient executables
  1723.          as BLINKER if the application is Clipper-intensive.  There are
  1724.          applications, however, where WARPLINK will create better memory
  1725.          models than BLINKER due to its ability to overlay code not
  1726.          manageable by BLINKER and other situations where WARPLINK will
  1727.          create better speed performance than RTLINK because its
  1728.          "overlay-pool" technique is more efficient than RTLINK's disk-
  1729.          intensive "overlay-reloading".  WARPLINK "learns" how to manage
  1730.          the pool most efficiently while the application is running.
  1731.  
  1732.          WARPLINK can overlay entire libraries but is NOT capable of
  1733.          overlaying "MODULES" like PLINK86 and RTLINK.
  1734.  
  1735.          WARPLINK is an excellent linker for all applications.  What
  1736.          it lacks in features, it more than makes up for in performance.
  1737.  
  1738.  
  1739.          NOLINK
  1740.  
  1741.          Current Version - 2.1
  1742.  
  1743.          List Price - $89.00
  1744.  
  1745.          NOLINK is a true "dynamic-linker" which does NOT produce an
  1746.          executable file but instead is an "executable-kernel" which
  1747.          contains the CLIPPER.LIB/EXTEND.LIB libraries and runs Clipper
  1748.          applications from .OBJ files and/or dynamic libraries.
  1749.  
  1750.  
  1751.  
  1752.  
  1753.  
  1754.  
  1755.                   Page 27  - Copyright (c) DONNAY Software
  1756.  
  1757.  
  1758.          Like ALINK, NOLINK's dynamic link system is compatible with
  1759.          Clipper-compiled code only and was designed to help develop
  1760.          and test Clipper modules by eliminating the normal link cycle
  1761.          that is required when producing .EXEcutable programs.  NOLINK
  1762.          only links objects into memory when they are "called" by the
  1763.          application that is running.  NOLINK's dynamic-link system is
  1764.          by far the fastest linking technique of all link systems
  1765.          because the symbol "fixups" occur at runtime and only when they
  1766.          are needed by the application.
  1767.  
  1768.          NOLINK's .EXE program is built from the Clipper libraries and
  1769.          the NOLINK "Kernel Builder" library and is somewhat of a memory
  1770.          hog.  NOLINK is an excellent product for testing small portions
  1771.          of Clipper programs or Clipper UDF's, but it can easily run out
  1772.          of memory on large Clipper projects.  NOLINK's standard .EXE
  1773.          program is limited to virgin Clipper applications and is not
  1774.          compatible with third-party libraries.  It is recommended that
  1775.          you use NOLINK's Kernel Builder to create a custom kernel for
  1776.          your more sophisticated applications.
  1777.  
  1778.  
  1779.          NOLINK - Kernel Builder
  1780.  
  1781.          Current Version - 2.1
  1782.  
  1783.          List Price - $89.00
  1784.  
  1785.  
  1786.          The NOLINK Kernel Builder is a LIBRARY which allows the
  1787.          programmer to build a custom "dynamic-link" kernel which also
  1788.          includes compatibility with third-party libraries.  Kernel
  1789.          Builder's Library is used with another "overlay-linker" to
  1790.          create the kernel.  By using overlay segments, I have been
  1791.          successful in creating complete NOLINK kernels in as small
  1792.          as 200k with RTLINK and 230k with PLINK86.
  1793.  
  1794.  
  1795.  
  1796.          dCLIP/dCLIPRUN
  1797.  
  1798.          Current Version -2.50
  1799.  
  1800.          List Price - $295.00
  1801.  
  1802.  
  1803.          dCLIP is a complete development platform for Clipper
  1804.          applications and uses "dynamic-linking" to run clipper .OBJ
  1805.          files or dynamic libraries.  dCLIPRUN has a 40k lower memory
  1806.          overhead than dCLIP because the DOT prompt and debugging tools
  1807.          have been removed.   Both the dCLIP.EXE and dCLIPRUN.EXE
  1808.          "engines" are included in the dCLIP package and a set of
  1809.          .LIBraries are also included to allow the programmer to create
  1810.          custom engines or use dCLIP features in his/her applications.
  1811.          dCLIP also includes a royalty-free dCLIPRUN distribution license
  1812.          to allow the developer to distribute the dCLIPRUN.EXE runtime
  1813.          engine or "custom" runtime engines for running Clipper
  1814.          applications from .OBJects and/or .DLBs.
  1815.  
  1816.  
  1817.  
  1818.  
  1819.  
  1820.                   Page 28  - Copyright (c) DONNAY Software
  1821.  
  1822.  
  1823.          dCLIP's technology uses functions from the NOLINK library to
  1824.          perform it's "dynamic-linking", but other than that, there is
  1825.          absolutely no resemblance to NOLINK.  dCLIP is much more
  1826.          sophisiticated than NOLINK in its dBASE/FoxBASE-style user-
  1827.          interface, memory management and debugging tools.  dCLIP also
  1828.          performs much better in network environments and includes complete
  1829.          documentation for integrating with all other third-party products.
  1830.  
  1831.          dCLIP is the only linking product that is a "runtime" system
  1832.          rather than producing an .EXEcutable program.  dCLIP's .EXE
  1833.          can be customized by re-creating it from the dCLIP libraries,
  1834.          therefore dCLIP provides the advantage of using any other
  1835.          linking technology in conjunction with their "dynamic-linking"
  1836.          system.   This means that a dCLIP.EXE engine built with RTLINK
  1837.          will support all the features of RTLINK .and. all the features
  1838.          of dCLIP.
  1839.  
  1840.          For many Clipper applications, distribution of an .EXEcutable
  1841.          program is the most efficient and beneficial.  dCLIP's runtime
  1842.          system was designed to solve the distribution problems which can't
  1843.          be managed very well in .EXE programs:
  1844.  
  1845.          1. Alpha/Beta testing projects under development
  1846.  
  1847.             Because dCLIPRUN executes the .OBJect files or dynamic
  1848.             libraries, daily updates to offsite testers can be distributed
  1849.             much more quickly and efficiently.  Sending a few .OBJects
  1850.             is quicker and easier than sending large .EXEcutables each
  1851.             time changes are made.
  1852.  
  1853.          2. Configuration control and customization.
  1854.  
  1855.             dCLIPRUN offers a more efficient method of distributing
  1856.             applications which require constant configuration or custom
  1857.             changes.  Custom configuration of a screen or report would
  1858.             normally require rebuilding the .EXEcutable program.  With
  1859.             dCLIPRUN's "incremental linking" capability, a custom change
  1860.             can be accomplished at the customer's site, compiled into
  1861.             an object and ready to run.
  1862.  
  1863.          3. Memory management for large applications.
  1864.  
  1865.             Some applications cannot be linked into an .EXEcutable program
  1866.             with any "overlay" linker because of the large number of
  1867.             symbols which must always go into the "root" memory.  For
  1868.             example, Champion accounting distributes their system in 10
  1869.             .EXEcutable programs.  dCLIPRUN will run Champion's entire
  1870.             accounting package as though it were one integrated system
  1871.             by running the .OBJect files or dynamic-libraries.  This also
  1872.             provides the advantage of reducing the distribution from 10
  1873.             diskettes to 4.
  1874.  
  1875.  
  1876.  
  1877.  
  1878.  
  1879.  
  1880.  
  1881.  
  1882.  
  1883.  
  1884.  
  1885.                   Page 29  - Copyright (c) DONNAY Software
  1886.  
  1887.  
  1888.  
  1889.              Linker Comparison Chart - Memory Management Features
  1890.  
  1891.     ┌──────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
  1892.     │  Linker  │Dynamic │Dynamic │ Static │ Static │ True   │Overlay │Memory  │
  1893.     │          │Overlays│Overlays│Overlays│Overlays│Dynamic │Reload  │Packing │
  1894.     │          │CLIPPER │ C/ASM  │CLIPPER │ C/ASM  │Linking │ C/ASM  │        │
  1895.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1896.     │PLINK86+  │  NO    │  NO    │  YES   │  YES   │  NO    │  YES   │  NO    │
  1897.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1898.     │PLINK86s87│  NO    │  NO    │  YES   │  YES   │  NO    │  NO    │  NO    │
  1899.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1900.     │RTLINK    │  NO    │  NO    │ YES *4 │  YES   │  NO    │  YES   │  NO    │
  1901.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1902.     │RTLINK-5.0│  YES   │  NO    │  NO    │  YES   │  NO    │  YES   │  NO    │
  1903.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1904.     │RTLINK+   │  NO    │  NO    │ YES *4 │  YES   │  NO    │  YES   │  NO    │
  1905.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1906.     │MS LINK   │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │
  1907.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1908.     │ALINK     │  YES   │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │
  1909.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1910.     │BLINKER   │  YES   │ YES *2 │  NO    │  NO    │  NO    │  NO    │  YES   │
  1911.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1912.     │WARPLINK  │  YES   │ YES *2 │  NO    │  NO    │  NO    │  NO    │  NO    │
  1913.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1914.     │TLINK     │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │
  1915.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1916.     │NOLINK    │  YES   │  NO    │ YES *1 │ YES *1 │  YES   │ YES *1 │  NO    │
  1917.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1918.     │NOLINK-KB │  YES   │  NO    │ YES *1 │ YES *1 │  YES   │ YES *1 │  NO    │
  1919.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1920.     │DCLIPRUN  │  YES   │  NO    │ YES *1 │ YES *1 │  YES   │ YES *1 │  YES   │
  1921.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1922.     │DCLIP     │  YES   │  NO    │ YES *1 │ YES *1 │  YES   │ YES *1 │  YES   │
  1923.     └──────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘
  1924.  
  1925.  
  1926.  
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.                   Page 30  - Copyright (c) DONNAY Software
  1951.  
  1952.  
  1953.  
  1954.          Linker Comparison Chart - Memory Management Features (cont.)
  1955.  
  1956.     ┌──────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
  1957.     │  Linker  │Virtual │Virtual │ Symbol │ Memory │Virtual │        │        │
  1958.     │          │Overlays│Overlays│ Re-    │ Alloc- │Memory  │        │        │
  1959.     │          │CLIPPER │ C/ASM  │ duction│ ation  │Swapping│        │        │
  1960.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1961.     │PLINK86+  │  NO    │  NO    │  NO    │  YES   │  NO    │        │        │
  1962.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1963.     │PLINK86s87│  NO    │  NO    │  NO    │  YES   │  NO    │        │        │
  1964.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1965.     │RTLINK    │  YES   │  YES   │  NO    │  YES   │  NO    │        │        │
  1966.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1967.     │RTLINK-5.0│  YES   │  YES   │  YES   │  YES   │  YES   │        │        │
  1968.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1969.     │RTLINK+   │  YES   │  YES   │  NO    │  YES   │  NO    │        │        │
  1970.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1971.     │MS LINK   │  NO    │  NO    │  NO    │  NO    │  NO    │        │        │
  1972.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1973.     │ALINK     │  NO    │  NO    │  YES   │  NO    │  NO    │        │        │
  1974.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1975.     │BLINKER   │  NO    │  NO    │  YES   │ YES *4 │  NO    │        │        │
  1976.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1977.     │WARPLINK  │  NO    │  NO    │  NO    │  NO    │  NO    │        │        │
  1978.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1979.     │TLINK     │  NO    │  NO    │  NO    │  NO    │  NO    │        │        │
  1980.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1981.     │NOLINK    │  NO    │  NO    │  YES   │ YES *5 │  NO    │        │        │
  1982.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1983.     │NOLINK-KB │  NO    │  NO    │  YES   │ YES *5 │  NO    │        │        │
  1984.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1985.     │DCLIPRUN  │  NO    │  NO    │  YES   │ YES *5 │  YES   │        │        │
  1986.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  1987.     │DCLIP     │  NO    │  NO    │  YES   │ YES *5 │  YES   │        │        │
  1988.     └──────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘
  1989.  
  1990.  
  1991.  
  1992.  
  1993.  
  1994.  
  1995.  
  1996.  
  1997.  
  1998.  
  1999.  
  2000.  
  2001.  
  2002.  
  2003.  
  2004.  
  2005.  
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011.  
  2012.  
  2013.  
  2014.  
  2015.                   Page 31  - Copyright (c) DONNAY Software
  2016.  
  2017.  
  2018.               Linker Comparison Chart - Productivity Features 
  2019.  
  2020.     ┌──────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
  2021.     │  Linker  │Incre-  │Overlay │Overlay │Overlay │Pre-    │Overlay │Source- │
  2022.     │          │mental  │complete│  lib   │ .OBJ   │Linked  │de-     │level de│
  2023.     │          │Linking │ .LIBs  │MODULES │ files  │libs    │bugging │-bugging│
  2024.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2025.     │PLINK86+  │  NO    │  NO    │  YES   │  YES   │  NO    │  YES   │  NO    │
  2026.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2027.     │PLINK86s87│  NO    │  NO    │  YES   │  YES   │  NO    │  YES   │  NO    │
  2028.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2029.     │RTLINK    │  NO    │  NO    │  YES   │  YES   │  YES   │  YES   │  NO    │
  2030.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2031.     │RTLINK-5.0│  YES   │  YES   │  YES   │  YES   │  YES   │  YES   │  NO    │
  2032.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2033.     │RTLINK+   │  NO    │  NO    │  YES   │  YES   │  YES   │  YES   │  YES   │
  2034.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2035.     │MS LINK   │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │  YES   │
  2036.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2037.     │ALINK     │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │
  2038.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2039.     │BLINKER   │  NO    │  YES   │  NO    │  YES   │  NO    │  YES   │  NO    │
  2040.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2041.     │WARPLINK  │  NO    │  YES   │  NO    │  YES   │  NO    │  NO    │  NO    │
  2042.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2043.     │TLINK     │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │  NO    │
  2044.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2045.     │NOLINK    │  YES   │  YES   │  YES   │  YES   │  YES   │  YES   │  NO    │
  2046.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2047.     │NOLINK-KB │  YES   │  YES   │  YES   │  YES   │  YES   │  YES   │  NO    │
  2048.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2049.     │DCLIPRUN  │  YES   │  YES   │  YES   │  YES   │  YES   │  NO    │  NO    │
  2050.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2051.     │DCLIP     │  YES   │  YES   │  YES   │  YES   │  YES   │  YES   │  YES   │
  2052.     └──────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074.  
  2075.  
  2076.  
  2077.  
  2078.  
  2079.  
  2080.                   Page 32  - Copyright (c) DONNAY Software
  2081.  
  2082.  
  2083.  
  2084.             Linker Comparison Chart - Productivity Features (cont.)
  2085.  
  2086.     ┌──────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
  2087.     │  Linker  │ Link   │ True   │        │        │        │        │        │
  2088.     │          │ Speed  │Dynamic │        │        │        │        │        │
  2089.     │          │        │Linking │        │        │        │        │        │
  2090.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2091.     │PLINK86+  │ Slow   │  NO    │        │        │        │        │        │
  2092.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2093.     │PLINK86s87│ Slow   │  NO    │        │        │        │        │        │
  2094.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2095.     │RTLINK    │ Slow   │  NO    │        │        │        │        │        │
  2096.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2097.     │RTLINK-5.0│Fast *6 │  NO    │        │        │        │        │        │
  2098.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2099.     │RTLINK+   │ Slow   │  NO    │        │        │        │        │        │
  2100.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2101.     │MS LINK   │ Medium │  NO    │        │        │        │        │        │
  2102.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2103.     │ALINK     │ Slow   │  NO    │        │        │        │        │        │
  2104.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2105.     │BLINKER   │V. Fast │  NO    │        │        │        │        │        │
  2106.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2107.     │WARPLINK  │ Fast   │  NO    │        │        │        │        │        │
  2108.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2109.     │TLINK     │V. Fast │  NO    │        │        │        │        │        │
  2110.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2111.     │NOLINK    │V. Fast │  YES   │        │        │        │        │        │
  2112.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2113.     │NOLINK-KB │V. Fast │  YES   │        │        │        │        │        │
  2114.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2115.     │DCLIPRUN  │V. Fast │  YES   │        │        │        │        │        │
  2116.     ├──────────┼────────┼────────┼────────┼────────┼────────┼────────┼────────┤
  2117.     │DCLIP     │V. Fast │  YES   │        │        │        │        │        │
  2118.     └──────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘
  2119.  
  2120.  
  2121.  
  2122.  
  2123.  
  2124.  
  2125.  
  2126.  
  2127.  
  2128.  
  2129.  
  2130.  
  2131.  
  2132.  
  2133.  
  2134.  
  2135.  
  2136.  
  2137.  
  2138.  
  2139.  
  2140.  
  2141.  
  2142.  
  2143.  
  2144.  
  2145.                   Page 33  - Copyright (c) DONNAY Software
  2146.  
  2147.  
  2148.  
  2149.        NOTES:
  2150.  
  2151.        1.  dCLIP, dCLIPRUN and NOLINK are "runtime" systems rather than
  2152.            linkers which produce an .EXEcutable program.  dCLIP's .EXE
  2153.            can be customized by re-creating it from the dCLIP libraries,
  2154.            therefore dCLIP provides the advantage of using any other
  2155.            linking technology in conjunction with their "dynamic-linking"
  2156.            system.   This means that a dCLIP.EXE engine built with RTLINK
  2157.            will support all the features of RTLINK .AND. all the features
  2158.            of dCLIP.
  2159.  
  2160.        2.  Dynamic overlaying of C/ASM code is tricky and can cause
  2161.            undesirable results when the code includes data or interrupts.
  2162.  
  2163.        3.  RTLINK seems to have occasional problems with Clipper-code
  2164.            static overlays when the modules pass parameters.
  2165.  
  2166.        4.  BLINKER allows the SET CLIPPER=<environment> to be burned
  2167.            into the .EXEcutable program.
  2168.  
  2169.        5.  dCLIP, dCLIPRUN use the SET CLIPPER=<environment> for free
  2170.            pool memory allocation and the OBJMemory=<memory> in DCLIP.SYS
  2171.            for object pool allocation.
  2172.  
  2173.        6.  If using Incremental Linking option then speed is improved
  2174.            dramatically.
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186.  
  2187.  
  2188.  
  2189.  
  2190.  
  2191.  
  2192.  
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200.  
  2201.  
  2202.  
  2203.  
  2204.  
  2205.  
  2206.  
  2207.  
  2208.  
  2209.  
  2210.                   Page 34  - Copyright (c) DONNAY Software
  2211.  
  2212.  
  2213.          ════════════════════════════════════════════════════════════════
  2214.  
  2215.                    Choosing a Linker for your Clipper Projects
  2216.  
  2217.          ════════════════════════════════════════════════════════════════
  2218.  
  2219.          Selecting a linker to use for a Clipper application is not
  2220.          always an easy task.  There are many factors which must be
  2221.          considered before deciding which is the very best possible
  2222.          solution.  Then again, it may not be necessary to always choose
  2223.          the best linker,  but simply a linker which is adequate and will
  2224.          solve the problem with the least effort.
  2225.  
  2226.          To help you decide, I have chosen to use 6 real case studies,
  2227.          in which our staff had to make a choice of a linker or linkers
  2228.          for our different Clipper projects.
  2229.  
  2230.  
  2231.          Case Study #1:  FYI - Work Smarter  (ALINK and BLINKER)
  2232.  
  2233.          FYI - Work Smarter is a Clipper application that is almost
  2234.          entirely written in Clipper with a few functions from
  2235.          several third-party libraries (GET-IT, Overlay(), SMARTMEM, IDL).
  2236.          When development started on Work Smarter, about 1-1/2 years ago,
  2237.          the product was linked using PLINK86 and 4 "static overlay"
  2238.          areas.   As the product evolved, memory usage went up.  No
  2239.          matter how we managed the overlays, the symbol table grew to
  2240.          the point where we had to use a new linker to get more memory.
  2241.          We purchased ALINK, a "dynamic-overlay" linker and with only
  2242.          a few hours effort reduced the memory overhead by 50k.
  2243.          ALINK dynamically overlays ONLY Clipper-compiled .OBJ files.
  2244.          This was not a problem for us since this project was "Clipper-
  2245.          code" intensive.
  2246.  
  2247.          With a little more effort and by compiling our application into
  2248.          larger and less .OBJects we reduced the symbol count further and
  2249.          were successful in reducing the memory overhead an additional
  2250.          30k.  A total investment of about 24 hours of time and $179.00
  2251.          reduced our .EXE load module from 340k to 260k.  ALINK likes
  2252.          to fragment the Clipper memory pool and we were getting OUT OF
  2253.          MEMORY during re-indexing, so we invested in a product named
  2254.          SMARTMEM and made structured calls to the H_PACK() function
  2255.          which packs the free pool.
  2256.  
  2257.          As FYI - Work Smarter evolved, it grew more powerful and larger.
  2258.          The .EXE load module increased another 10k over several months
  2259.          and we were running into memory problems again because now
  2260.          the program was designed to work with a 90k resident TSR.
  2261.  
  2262.          Enter BLINKER, (designed by Jud Cole, the author of ALINK).
  2263.          BLINKER uses the same basic overlaying concept as ALINK,
  2264.          however it offers the ability to also dynamically overlay the
  2265.          EXTEND.LIB library.  This brought the .EXE load module down
  2266.          from 270k to 230k.
  2267.  
  2268.  
  2269.  
  2270.  
  2271.  
  2272.  
  2273.  
  2274.  
  2275.                   Page 35  - Copyright (c) DONNAY Software
  2276.  
  2277.  
  2278.          Our BLINKER link file:
  2279.  
  2280.          FILE hoa,swapattr,resident
  2281.          OUTPUT fyi.EXE
  2282.          BLINKER MEMORY PACK 10
  2283.          BLINKER OVERLAY OPSIZE 50
  2284.          BLINKER EXECUTABLE CLIPPER V10;R32;F39
  2285.          SECTION INTO fyi.OVL
  2286.          BEGINAREA
  2287.            FILE errorsys
  2288.            FILE hoaovl1.OBJ
  2289.            FILE hoaovl2.OBJ
  2290.            FILE hoaovl3.OBJ
  2291.            FILE hoaovl4.OBJ
  2292.            FILE hoaovl5.OBJ
  2293.            FILE hoaovl6.OBH
  2294.            ALLOCATE overcl.LIB
  2295.            ALLOCATE dclip.LIB
  2296.            ALLOCATE extend.LIB
  2297.          ENDAREA
  2298.          LIB dclipr,getit,smartmem,clipper,idl
  2299.  
  2300.  
  2301.          Case Study #2: FYI - LetterWriter (.RTLINK and .RTLINKplus)
  2302.  
  2303.          FYI - LetterWriter is a Clipper application which is a data-
  2304.          merging word-processor, spell-checker and thesaurus.  FYI -
  2305.          LetterWriter is approximately 30% Clipper-compiled code and 70%
  2306.          C/ASM code.  When this project started, about 1 year ago, it was
  2307.          linked using PLINK86 and 5 "static overlay" areas.  After
  2308.          many "crashes" we determined that this application was far too
  2309.          sophisticated to be managed with "static overlays", so we
  2310.          purchased .RTLINK, reduced our overlay areas from 5 to 3, and
  2311.          completely eliminated computer lock-up problems while reducing
  2312.          the .EXE load module by 50k.
  2313.  
  2314.          The Clipper-code portion of the program was still overlayed
  2315.          "static" so we had to be careful to structure the Clipper-code
  2316.          segments properly to prevent lockup, however the C/ASM code was
  2317.          all automatically reloaded simply by entering the command:
  2318.          "RELOAD FAR 300" in our link file.
  2319.  
  2320.          We tried using dynamic-overlay linkers like BLINKER and
  2321.          WARPLINK for this project, but they could not dynamically
  2322.          overlay the sophisticated C/ASM routines we used in the spell
  2323.          checker and thesaurus.   During development we use RTLINK+
  2324.          because it supports Microsoft Code-View, then we link the
  2325.          final product with RTLINK 3.1.
  2326.  
  2327.          Our link file:
  2328.  
  2329.          Sorry, but this is information is proprietary
  2330.  
  2331.  
  2332.  
  2333.  
  2334.  
  2335.  
  2336.  
  2337.  
  2338.  
  2339.  
  2340.                   Page 36  - Copyright (c) DONNAY Software
  2341.  
  2342.  
  2343.  
  2344.          Case Study #3: dCLIP/dCLIPRUN (.RTLINK and NOLINK 2.1)
  2345.  
  2346.          dCLIP is a development platform and runtime system for Clipper
  2347.          which runs Clipper applications from .OBJect files or dynamic
  2348.          libraries.  dCLIP is basically a Clipper application, however,
  2349.          the dCLIP.EXE program contains about 5% Clipper-compiled code
  2350.          and 95% C/ASM code.  The dCLIP dot-prompt interpreter, debug
  2351.          system, database manager, report writer, query-builder, etc.
  2352.          are all written in Clipper, yet none of this Clipper-code is
  2353.          included in the DCLIP.EXE program, but instead is included in
  2354.          a "dynamic-library" which is linked into memory only as the
  2355.          functions are needed.
  2356.  
  2357.          dCLIP and dCLIPRUN are an example of 2 linking technologies
  2358.          working together to produce the very best memory management
  2359.          solution.  NOLINK is a "dynamic link" library which is linked
  2360.          into the dCLIP.EXE "engine" using .RTLINK.  The engine also
  2361.          includes the entire CLIPPER.LIB and EXTEND.LIB libraries and
  2362.          makes provisions for including any third-party libraries.
  2363.  
  2364.          When dCLIP development started 2 years ago, we used PLINK86
  2365.          and NOLINK version 1.2.  Our dCLIP.EXE engine load module
  2366.          size was approximately 310k.  This left very little room for
  2367.          the Clipper application so dCLIP version 1.0 could handle
  2368.          only small Clipper programs or it would run out of memory.
  2369.          Like ALINK and BLINKER, the NOLINK-1.2 "dynamic linker" used
  2370.          the Clipper free pool to link the Clipper-compiled code.  This
  2371.          caused memory fragmentation and eventually the program would
  2372.          run out of memory.
  2373.  
  2374.          dCLIP 2.0 used a whole new approach to the problem of overlay
  2375.          linking.  First, we threw away "static overlays" and found that
  2376.          we could extract modules from the CLIPPER.LIB and EXTEND.LIB
  2377.          libraries and overlay them using .RTLINK and the "MODULE"
  2378.          command.  The Clipper libraries are all C/ASM code, so we use
  2379.          the "RELOAD FAR 200" command to insure that the overlayed
  2380.          segments get properly reloaded.  RTLINK allowed us to overlay
  2381.          the "dynamic-link" functions from the new NOLINK-2.1 library as
  2382.          well, so now our DCLIP.EXE load module was reduced from the
  2383.          original 310k to only 230k.  With this additional 80k memory
  2384.          overhead, rewriting the "dynamic-linker" to allocate a seperate
  2385.          object pool and including a "memory-packing" utility for memory
  2386.          defragmentation, we improved dCLIP to now be capable of running
  2387.          any large Clipper application without running out of memory.
  2388.  
  2389.  
  2390.  
  2391.  
  2392.  
  2393.  
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.                   Page 37  - Copyright (c) DONNAY Software
  2406.  
  2407.  
  2408.          Our link file:
  2409.  
  2410.          STACK 1024
  2411.          FI dclip.OBJ
  2412.          LIB dclipnl,dclip,dclipr,dcextend,clipper
  2413.          OUTPUT dclip.EXE
  2414.          RELOAD FAR 200
  2415.          OVERLAY CODE
  2416.          VERBOSE
  2417.  
  2418.          BEGINAREA
  2419.            #modules from DCEXTEND.LIB
  2420.            SECTION MODULE memoedit,memotran
  2421.            SECTION MODULE memoline,memoread,memowrit,mlcount,mlpos
  2422.            SECTION MODULE achoice,ascan,adir,afields,asort,ains,acopy
  2423.                    MODULE afill,gete
  2424.            SECTION MODULE report
  2425.            SECTION MODULE dbedit
  2426.            SECTION MODULE icreate,sort,sortof,examplea,examplec,recsize
  2427.            #modules from DCLIPNL.LIB
  2428.            SECTION MODULE c_call,global,parseobj,msg,kern,omalloc,mtbuf
  2429.                    MODULE mtobj,screen
  2430.            #modules from DCLIP.LIB
  2431.            SECTION MODULE overlay,over_6,over_22,over_24
  2432.          ENDAREA
  2433.  
  2434.          BEGINAREA
  2435.            #modules from DCEXTEND.LIB
  2436.            SECTION MODULE ntx
  2437.            #modules from DCLIP.LIB
  2438.            SECTION MODULE dbgbrow,dbgio,dbgscrn,dcega43,dcvga50,videoid,dckey
  2439.            SECTION MODULE txtstuff
  2440.            SECTION MODULE _dcinit
  2441.          ENDAREA
  2442.  
  2443.  
  2444.  
  2445.  
  2446.  
  2447.  
  2448.  
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466.  
  2467.  
  2468.  
  2469.  
  2470.                   Page 38  - Copyright (c) DONNAY Software
  2471.  
  2472.  
  2473.  
  2474.          Case Study #4: dCLIPFLP.EXE -Flipper engine
  2475.  
  2476.                           (WARPLINK and dCLIP 2.5)
  2477.  
  2478.          dCLIPFLP is a development platform and runtime system for
  2479.          Clipper applications which use the FLIPPER graphics library.
  2480.          WARPLINK was the best choice for this application for reasons
  2481.          of speed performance more than memory performance.  RTLINK
  2482.          actually performed better from a memory-management point of
  2483.          view, however, the constant "reloading" of overlay segments
  2484.          proved to be too "disk-intensive" and very slow.  WARPLINK's
  2485.          link "pool" management scheme produces better speed performance
  2486.          because it keeps routines which are called most often in memory.
  2487.  
  2488.          WARPLINK is an example of a "dynamic-overlay" linker which
  2489.          has limitations on the modules which can be overlayed. It is
  2490.          very unclear how to determine which modules CAN be overlayed
  2491.          other than by constant trial and error.  The link file below
  2492.          was developed after much of this trial and error.  Objects and
  2493.          libraries which are to be overlayed are placed in ()
  2494.          parenthesis.  Gary Prothero, the developer of Flipper is
  2495.          currently working on breaking his libraries out into sub-
  2496.          libraries which will allow all the (OVERLAYABLE) code to be
  2497.          overlayed as a .LIBrary rather than many .OBJects.  This, of
  2498.          course, makes project management simpler.
  2499.  
  2500.          /r /op:62 /em (dclipflp) + ovlmgr
  2501.          # flipper objects
  2502.          (ARC + AREASET + ASCIISET + AT_SET + AXISCALC + AXISSET) +
  2503.          (BEE_BOP + CALLBIOS + CLIPSET  + CLS + COLOR + COLORSET) +
  2504.          (COM + CWAIT + DR_CURVE + EGA_HERC + ERRORSET + FALIGN) +
  2505.          (FASTFILL + FASTLINE + FILLBOX + FIND_PEL + FLIPINIT + GETFHGT) +
  2506.          (GETLNATT + GETLNLEN + GET_FATT) + GET_PEL + (GET_PT + GFXCLOSE) +
  2507.          (GFXLSEEK + GFXOPEN + GFX_RDWR + GRAPHIC + GRAPHICS + HP_CLIP) +
  2508.          (HP_PLOTS + INITSET LABELSET + LEGEND + LINE) +
  2509.          (LINES + LN_JUST + LO_PRINT + MALOCPIC + MATHSET + MISS_SET) +
  2510.          (MODESET + OPEN_FNT + PIC_ASM + PIECHART + PIE_CLIP + PRINT) +
  2511.          (PSET + REGRESS + RESET + RETXYSET + ROTFCN) +
  2512.          (ROT_180 + ROT_270 + ROT_90 + SAVEFONT + SAYMARK + SCALESET) +
  2513.          (SCANKEY + SCL_DRAW + SCREEN + SET_XOR + TEXT + WORLDSET) +
  2514.          (WRTCHAR + XAXISSET + XYSET + YAXISSET + _IDIV + _LINES)
  2515.          # output file name
  2516.          dclipflp
  2517.          # map file name
  2518.          dclipflp
  2519.          # libraries
  2520.          dclipnl+(dclip)+(dcextend)+dclipr+clipper+flip88
  2521.  
  2522.  
  2523.  
  2524.  
  2525.  
  2526.  
  2527.  
  2528.  
  2529.  
  2530.  
  2531.  
  2532.  
  2533.  
  2534.  
  2535.                   Page 39  - Copyright (c) DONNAY Software
  2536.  
  2537.  
  2538.  
  2539.          Case Study #5: DONNAY Accounting System
  2540.  
  2541.                           (dCLIPRUN - dynamic linker)
  2542.  
  2543.          Our DONNAY Software Accounting system is written entirely in
  2544.          Clipper and handles Sales Orders, Customers, Accounts Receivable,
  2545.          Accounts Payable, Inventory Control, General Ledger and reports.
  2546.          Is also uses the entire SOFT.CLIP library, and has a gateway
  2547.          system to call other programs such as FYI - Work Smarter.
  2548.  
  2549.          This program was originally written in dBASE-II and has evolved
  2550.          into a large, custom program which is about 1.5Meg of executable
  2551.          code.  Until 1 year ago, this system consisted of several
  2552.          .EXEcutable sub-programs.  Our accounting department was always
  2553.          frustrated because we were reluctant to provide needed changes
  2554.          due to the complexity of the system.  Each one was linked with
  2555.          PLINK86 and had a sophisticated internal overlay structure.
  2556.          Finally we decided to solve this problem by converting the
  2557.          program into several "dynamic-libraries" and then running it
  2558.          entirely under the dCLIPRUN "dynamic-link" system.  The conversion
  2559.          took about 2 hours because all that was needed was to take all
  2560.          the Clipper objects and "pre-link" them into sets of .DLB
  2561.          (dynamic-library) files.  Now, providing simple changes is easy
  2562.          because we simply edit and compile the desired .PRG and distribute
  2563.          the new .OBJect file.  dCLIPRUN's incremental link system insures
  2564.          that the new object is executed rather than the old one in the
  2565.          dynamic library.  About every two weeks we update the dynamic
  2566.          libraries and distribute them.
  2567.  
  2568.  
  2569.  
  2570.          ABOUT THE AUTHOR
  2571.  
  2572.  
  2573.          Roger Donnay is the President and founder of DONNAY Software
  2574.          Designs, a Newport Beach, California firm which specializes
  2575.          in the development of database systems for microcomputers.
  2576.  
  2577.          Roger is the creater of the SOFT.CLIP and TIME-TRAK add-on
  2578.          libraries for Clipper, the dCLIP development platform/runtime
  2579.          system for Clipper, and "FYI - Work Smarter", a home-office
  2580.          management system.   Roger's programming background includes
  2581.          assembly-language in "real-time" applications, basic, pascal,
  2582.          plz, dBASE-II, dBASE-III, Clipper and miscellaneous technical
  2583.          support languages.  Roger holds a BSEE degree from West Coast
  2584.          University in Southern California and is a Vietnam veteran with
  2585.          8-years of U.S. Navy electronics background in radar and
  2586.          communications.
  2587.  
  2588.          Roger J. Donnay
  2589.          DONNAY Software Designs
  2590.          1880 Park Newport,  Suite 104
  2591.          Newport Beach, CA 92660
  2592.          Voice: 714-721-6720
  2593.          Fax  : 714-721-9495
  2594.          BBS  : 619-728-4318 or 619-728-0633
  2595.          Compuserve ID : 73227,1225
  2596.  
  2597.          This documented is dated July 7, 1990
  2598.  
  2599.  
  2600.                   Page 40  - Copyright (c) DONNAY Software
  2601.  
  2602.