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

 Special Memory Considerations
--------------------------------------------------------------------------------

 When you start building a very large Clipper and FiveWin you may
 follow the following recommendations:

 FiveWin 1.9.2 upgrade has a set of new funtions to analize the
 DGroup of your application. A new ErrorSysW.prg uses these
 functions to analize your DG memory and help you in properly fine
 tune it.

 Basically there are two main rules:

 1. Reduce the amount of static variables used in your app. This
    is very easy just using a static array instead of several
    variables:

    static one
    static two
    static three

 change them into

    static aVars := {,,}

 where

    #define ONE aVars[ 1 ]
    #define TWO aVars[ 2 ]
    etc...

 This does not have sense with few statics, but it do has sense
 when you are managing a large amount of statics (I know of
 customers that use over 1000 statics). FW 192 has a new function
 that counts the number of statics variables your app has.

 2. There is a powerfull utility named DGPIG (it can be found
 on the CA-Clipper forum) produced by Michael Devore (CauseWay)
 that analizes LIBs and OBJs and reports about DG consume. Clipper
 OBJs consume 8 bytes which it is normal and can not be fixed. But
 the problem normally comes from C language modules. There are many
 ways why a C module can consume DG space. Normally for declaring
 a literal inside the C code or cause declaring a static array.
 This both problems can be fixed using the C clause 'far' that
 forces them into a different data segment:

 This is a sample:

 // Correct way:
 static far char Alert[] = "Alert";

 CLIPPER nMsgBox()
 {
   _MsgBox( Alert, 0 );
 }

 // wrong way:
 CLIPPER nMsgBox()
 {
   _MsgBox( "Alert", 0 );
 }

 //wrong way
 static byte Buffer[200];

 //right way
 static far byte Buffer[200];

 DGPIG will report you about these problems.

 Just keep this in mind:

 The less initial DGroup your app consumes (FW 192 reports you
 this initial size), and the less Clipper static variables you
 manage, the larger Clipper stack you may have:

 <----------------------------- 64 Ks -------------------------------->
 DATA,_BSS (SYMP) | STACK_C | HEAP_C | CLIPPER STACK |  CLIPPER STATICS
 <----------- initial DG size ------->

 Clipper will use the remaining DG space for its stack.

 From FiveWin 1.9.2 we are allocating dynamic heap when building GETs and
 MultiGets from source code ( @ ..., ... GET ... ), so we have been able
 to successfully reduce the LNK (or DEF) file HeapSize value down to
 1024 bytes and the applications are working successfully. This was not
 possible before as Gets and MultiGets used that area for internal working.
 Doing this HeapSize reduction you will get an extra 7,5 Ks for your
 Clipper stack!