For an answer to this question please refer to CLIPPER 5.0SUPPORT BULLETIN #2. The bulletin is available on NANFORUM indata Library 16 under the name S50002.TXT. Also available inLibrary 16 is INSTCL.BAT, a batch file which will manuallycomplete the installation of the utilities.

1.2 Why are my 5.0 .EXE's bigger than S87 ?

Clipper 5.0 executable (.EXE) files are often (though notalways) larger than equivalent Summer '87 executables. Generally, this is because of the increased size of the Clipperruntime support system (the support code is larger because ofthe larger feature set in Clipper 5.0 and because the runtimesystem is more modular than in previous releases).

PLEASE NOTE: the amount of memory needed to successfully run aClipper 5.0 application is only indirectly related to the sizeof the executable file. In particular, increasing the amount ofcompiled Clipper code (compiled .PRG files) in an applicationhas very little effect on the amount of memory required to runthe application. This is because all compiled Clipper code isautomatically placed into dynamic overlays by .RTLink. Dynamically overlayed code is paged in and out of memory asneeded during execution; the amount of compiled Clipper codeaffects the .EXE size but not the amount of memory required torun the application.

In some cases the physical size of the .EXE file (as opposed tothe amount of memory needed for execution) is a concern. Anexample would be a large application that you wish to distributeon floppy disks. Clipper 5.0 offers several options forbreaking an application into multiple files. For moreinformation, refer to Chapter 4 of your Programming andUtilities Guide.

Compiling with the debugging option (/B) increases the size of

the .EXE file. When you are through debugging your application,you should recompile it without the debugging option. Compilingwith the /L option (omit line number information) reduces thesize of your .EXE file. For information on these options, referto Chapter 3 of your Programming and Utilities Guide.

For information about how dynamic overlays are handled duringexecution (and other runtime memory management issues), refer toCLIPPER 5.0 SUPPORT BULLETIN #3. This bulletin is available onNANFORUM in data Library 16 under the name S50003.TXT.

For information about determining how much memory is required torun 5.0 applications, see below.

1.3 How much memory do 5.0 applications require ?

PLEASE NOTE: the size of the executable (.EXE) file is onlyindirectly related to the amount of free memory required tosuccessfully run the application (see above).

For detailed information on Clipper 5.0 memory management, referto CLIPPER 5.0 SUPPORT BULLETIN #3. This bulletin is availableon NANFORUM in data Library 16 under the name S50003.TXT.

The memory requirements of a Clipper 5.0 application can beroughly divided into three categories:

LOAD SIZE

This is the memory needed to initially read the application'sexecutable image into memory. The load size is determined atlink time; it is always the same for a given .EXE. .RTLinkdisplays the load size in parentheses at the end of every link. Example: (203k). Load size is affected only slightly by theamount of compiled Clipper code in the application (this isbecause, by default, all compiled Clipper code is dynamicallyoverlayed, see above). However, load size is significantlyaffected by the amount of non-Clipper (C and Assembler) codebeing used. This includes Clipper support code and third partylibrary code. Linking with a pre-linked library (.PLL) canunnecessarily increase load size if your application is notactually using all of the code in the .PLL. For information onstatically overlaying C and assembler code and building variousconfigurations of pre-linked libraries refer to Chapter 4 of yourProgramming and Utilities Guide (for .PLLs refer also to theREADME file supplied with Clipper 5.0).

FIXED-MEMORY ALLOCATIONS

Fixed-memory is the memory allocated for system tables and othernon-virtualized data. Memory allocated by C or Assemblerfunctions (for example, Summer87 versions of third partylibraries or overlay managers) is usually fixed memory. Thefixed-memory requirement depends on which features of the systemare being used. For most Clipper applications it ranges from 16Kto 64K. Third party libraries or overlay managers which allocatefixed memory may increase this requirement, as may certainClipper programming practices (for more information onfixed-memory allocations, refer to bulletin #3).

SWAP SPACE

Swap space is the memory used by the Virtual Memory Manager(VMM)to "swap" virtualized data in and out of main memory. Bydefault, the VMM uses all available memory as swap space; fixedallocations decrease the amount of swap space available (for moreinformation, refer to bulletin #3).

The amount of memory needed to successfully run a particularapplication depends primarily on its load size and fixed-memoryrequirements. A general rule of thumb is that an applicationwill require from 100K to 200K in addition to the load sizereported by .RTLink. For large applications that use most of thefeatures of Clipper, the 100K figure is usually a bare minimum;execution may be slow due to heavy swapping activity by the VMM(unless Expanded Memory is available, see bulletin #3).

A "hello world" program, consisting of this simple statement:

? "hello world"

causes .RTLink to report a load size of approximately 125K. Theapplication requires roughly 200K of free memory to execute (loadsize plus 75K). Note that increasing the size of the program (byrepeating the statement 2000 times, for example) has a negligibleeffect on the load size and the memory requirement. As notedabove, this is because of dynamic overlaying.

EXAMPLE: DBU

The database utility program supplied in source code form withClipper 5.0. DBU uses almost all of the features of Clipper 5.0.

.RTLink reports a load size of approximately 285K. Although DBUcan execute in less than 400K, it tends to bog down due to VMMdisk swapping activity. With 425K available, swapping activityis lessened and is generally unobtrusive. As more memory is madeavailable (or if Expanded Memory is available) performanceimproves, especially on large file operations.

1.4 What does "swap space exhausted" mean?

This indicates that the Clipper 5.0 Virtual Memory Manager nolonger has enough main memory to work with. For moreinformation, refer to the sections above. See also CLIPPER 5.0SUPPORT BULLETIN #3. This bulletin is available on NANFORUM indata Library 16 under the name S50003.TXT.

1.5 What is "eut0032" error from RTLink ?

This message appears to have three possible causes:

1) There are Summer 87 compiled .OBJs or .LIBs in the currentdirectory, or they appear in directories referenced in the LIB orOBJ environment variables, or Summer 87 .OBJs or .LIBs arereferenced via a DOS APPEND command. .RTLink is not compatiblewith Summer 87 compiled programs.

2) A function or procedure has been defined twice. Removal of theduplicate declaration will solve the problem.

3) Some reports indicate that this error may occur because asingle object module was very large. If neither of the abovesolutions eliminates this error message, and you have one or more.OBJ files larger than 64K, try compiling your .PRG filesindividually using the /M compiler option. Make sure to supplyall of the resultant .OBJ files to .RTLink for linking. For moreinformation on compiler options and linking multiple .OBJ files,refer to Chapters 3 and 4 of your Programming and UtilitiesGuide.

1.6 Where is the CL.bat file?

This file was inadvertently left off the distribution disks. Itis a simple file. Here are the contents of CL.BAT:

CLIPPER %1 IF NOT ERRORLEVEL 1 RTLINK FI %1

This method of compile and link is good for very smallapplications and test programs.

Most of you will wish to take advantage of a more modular(component) application build strategy and use the RMAKE utilityto only compile those files which have changed since the previouscompile. You might also wish to take advantage of the improvedturn-around times which can be had from using Pre-Linked Library(.PLL) files. Therefore, it should be noted that mostapplications will outgrow this type of simple Batch file quickly.

1.7 Why do I get "memory overbooked" when compiling a large .prg?

This message is generated because the .PRG(s) that the ClipperCompiler was attempting to process required more memory than thecompiler had available.

This error can occur on programs which contain very largefunctions or procedures (greater than 60K), especially when thecompiler is running with very little free memory available (forexample, when using many TSR utilities or executing the compilerfrom within a text editor).

The problem can also occur when attempting to compile amonolithic application that cascades through many multiple .PRGfiles through the use of "DO PrgFileName", or when compiling manymodules into the same .OBJ using a .CLP list.

In all cases, either the program must be reorganized into smallerunits or the compiler must be given more memory to run in.

The preferred solution is to limit individual functions andprocedures to a reasonable size, group them into reasonably sizedsource files, and compile the files individually using the /Mcompiler option. The resultant .OBJ files are then presented asa list to .RTLink. This results in better program structure andalso gives you the option of using the RMAKE utility to avoidunnecessary compilation. For information on compiling, linking,and using RMAKE, refer to your Programming and Utilities Guide.

1.8 Why does my Summer'87 errorsys.prg not work with 5.0?

The Error System has been changed between versions and you mustrework your old ERRORSYS.PRG to conform to the new methods andrecompile with 5.0.

Should an unchanged S87 compiled version of errorsys.prg bepresented to the linker, it might create an "eut0032" error. If the S87 ERRORSYS.PRG is recompiled, then the application willsuccessfully link. However, an Internal Error 612 will occur atruntime when an attempt is made to call the error handler.

See the Clipper 5.0 version of ERRORSYS.PRG (located by defaultin your \CLIPPER5\SOURCE\SYS directory) for an example of aClipper 5.0 error handler.

1.9 Why do I get "input parsing error" with RTLINK FIRST?

RTLink is capable of supporting syntax which is compatible withMicrosoft's LINK (POSITIONAL) and Phoenix Technologies PLINK86(FREEFORMAT).

Page 3-2 of the Getting Started book contains a linking examplewhich reads:

RTLink First

This example assumes the POSITIONAL syntax. By default, however,.RTLink uses the FREEFORMAT syntax. The example should read:

RTLink FI First

The "FI" is short for "FILE," a keyword in the FREEFORMAT syntax.

For more information on .RTLink, refer to Chapter 4 of yourProgramming and Utilitites Guide.

1.10 Why do I get "Undefined Function : " at runtime?

The functions Alltrim() and Right() are not in Extend.LIB. Instead, they are preprocessed into Substr() calls by thepreprocessor with a #translate() directive.

Index (.ntx) files contain the "key" expression as text in thefile header and evaluation of the key at runtime is achieved bymacro-expansion (&). There is no way for the preprocessor toeffect a change to the "key" expresion in the index file.Therefore, at runtime when the key for the index is evaluated theAlltrim() (or Right()) function can't be found.

Anything inside quotation marks ("" or '' or []) will not beaffected by preprocessor directives. Therefore, if an expressionis stored in a memory variable and then macro'ed (&), theAlltrim() function will not be found.

To work around this problem you can change your index keys andmacro's to Substr() calls or add the following program shorts toyour code: