home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / mswindo / programm / misc / 4727 < prev    next >
Encoding:
Text File  |  1993-01-07  |  2.0 KB  |  45 lines
  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!world!pbreen
  3. From: pbreen@world.std.com (Patrick D Breen)
  4. Subject: Re: Automatic data segment exceeds 64K
  5. Message-ID: <C0IGp6.777@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <2935516401.1.p00090@mail.psi.net>
  8. Date: Fri, 8 Jan 1993 01:12:41 GMT
  9. Lines: 34
  10.  
  11. "Jeffrey P. Overcash" <p00090@mail.psi.net> writes:
  12.  
  13. >  The header say it all - well almost.  I'm useing Borland C++ and I am 
  14. >currently running into this linking error.  Unfortunately, I have a DLL 
  15. >that requires a large (32K) stacksize and already only use 1024 for 
  16. >heapsize therefore I need to move some of my near data to far.  I've 
  17. >tried several different way of doing this (or so I thought), but nothing 
  18. >seems to be affecting this problem.  The manual says to use the map file 
  19. >to determine the sizes of the componant segments to see which modules 
  20. >contribute what to the DGROUP.  I've done this but nowhere can I find 
  21. >out how to move a module into another segment.  Any and all help will be 
  22. >greatly appriciated.
  23.  
  24. We ran into the same problem with our application.  What we did to fix it
  25. was to remove the expression string from our asserts and make sure that
  26. the "merge duplicate strings" option is enabled.  Both of these reduce the
  27. size of the automatic data segment.
  28.  
  29. If these don't help, the space is probably being taken up by a few static
  30. arrays or structures.  If it is possible to change these to be allocated
  31. from the heap, the problem may go away.  If it is not possible to allocate
  32. them from the heap, you can force them to be put into a far segment by
  33. including the _far keyword in the declaration - for instance 
  34.  
  35. static long _far LargeArray[1000] = { 1, 2, ... 1000, };
  36.  
  37. The one thing to watch for with this is that by default, Borland will
  38. create a new far segment for each declaration of this type.  There is a
  39. compile switch (and a #pragma) that force them all into the same far
  40. segment but I forget what the switch is.
  41.  
  42. Hope this helps,
  43.  
  44. Patrick Breen
  45.