🚀 go-pugleaf

"Jeffrey P. Overcash" <p00090@mail.psi.net> writes:

>  The header say it all - well almost.  I'm useing Borland C++ and I am 
>currently running into this linking error.  Unfortunately, I have a DLL 
>that requires a large (32K) stacksize and already only use 1024 for 
>heapsize therefore I need to move some of my near data to far.  I've 
>tried several different way of doing this (or so I thought), but nothing 
>seems to be affecting this problem.  The manual says to use the map file 
>to determine the sizes of the componant segments to see which modules 
>contribute what to the DGROUP.  I've done this but nowhere can I find 
>out how to move a module into another segment.  Any and all help will be 
>greatly appriciated.

We ran into the same problem with our application.  What we did to fix it
was to remove the expression string from our asserts and make sure that
the "merge duplicate strings" option is enabled.  Both of these reduce the
size of the automatic data segment.

If these don't help, the space is probably being taken up by a few static
arrays or structures.  If it is possible to change these to be allocated
from the heap, the problem may go away.  If it is not possible to allocate
them from the heap, you can force them to be put into a far segment by
including the _far keyword in the declaration - for instance 

static long _far LargeArray[1000] = { 1, 2, ... 1000, };

The one thing to watch for with this is that by default, Borland will
create a new far segment for each declaration of this type.  There is a
compile switch (and a #pragma) that force them all into the same far
segment but I forget what the switch is.

Hope this helps,

Patrick Breen