Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rex!spool.mu.edu!agate!dog.ee.lbl.gov!nosc!humu!pegasus!tleylan
From: tleylan@pegasus.com (Tom Leylan)
Newsgroups: comp.databases
Subject: Re: Some questions about CLIPPER linking: large EXE's etc.
Message-ID: <1991Jun5.121741.5141@pegasus.com>
Date: 5 Jun 91 12:17:41 GMT
References: <16446.284c1c82@levels.sait.edu.au>
Organization: Pegasus,  Honolulu
Lines: 66

In article <16446.284c1c82@levels.sait.edu.au> marwk@levels.sait.edu.au writes:
>With CLIPPER 5.01 the EXE files for a small TBROWSE object are HHUUGGEE.
>
>Is there a way to use the linker to cleverly only link in the subprograms
>that are used?
>
>HiTech C for the CP/M machines used to do this quite nicely.
>
>Surely NANTUCKET modern-day programmers can do this too.
>
>It must be me, I suppose - please just tell me which switch to use.
>But if it is just a switch, why would it not be the default, and why would
>anyone want to link in all the extra code when it is not used by a program?
>
>Is this because of the ability of macro-substitution to generate calls that are
>not recognised by the compiler?  If so, can this be over-ridden with a
>linker switch?
>
>If the supplied linker cannot do this, is there another product that does?
>
>Why do people like BLINKER and why are there 3rd party linkers for CLIPPER?
>
Ray... so many questions... so little time.

Clipper 5.0 includes only what it needs to operate.  While you may only see
a tbrowse object you your source code I believe that you're opening and
accessing a .DBF file (file handling routines are linked) and are displaying
output to the screen (video drivers are linked).  In addition to that there
is startup code and the tbrowse stuff of course and whatever routines that
have to be there (math and string handling).

.EXE file size is no longer directly related to memory footprint since the
supplied linker .RTLink creates dynamic overlays using a paging system.  It
is quite possible to see a 1.5 MB .EXE running in less than 640K of RAM.

Clipper is not a C compiler and DOS is not CP/M but other than that I can
understand your comparison <g>.  Seriously, I doubt whether you wrote a
tbrowse in C and included .DBF drivers and a virtual memory manager (VMM)
or you would have noticed the same increase in .EXE file size.

Macros do impact the final .EXE size and should be avoided if possible it
is necessary to compile them at runtime since their contents are unknown
and a mini-compiler is linked in.  They can be avoided through the use of
extended expressions and codeblocks with very few places where macros
are required remaining.

The latest version of Blinker can produce the dynamic overlays with paging
that .RTLink produces.  I'm not certain if WarpLink does yet or not.  Both
of those products link faster than .RTLink and that is often times a 
consideration to somebody.  Blinker also provides a number of additional
tools built into the linker.  You can stamp an .EXE as a demo and limit
the time that the program will operate.  Believe that both products offer
symbol table compaction and Warplink I think comes with a profiler.

So basically it is different strokes for different folks.

Hope this has been enlightening.

<watch this spot, BTW, I will be posting information concerning my new
 magazine.  Software Concepts will be "the" magazine for application
 developers.  Of interest to all developers it is of significant interest
 to Clipper developers as all code samples will be in Clipper, C or
 assembler>

tom
<ex-Senior Systems Analyst - Nantucket Corporation>