This question explains the problem; the next question gives some
 remedies.

 DGROUP is a link-time group of data segments, and the compiler typically
 generates code that expects DS to be pointing to DGROUP. (Exception:
 Borland's huge model has no DGROUP.)

 Here's what goes into DGROUP:

 * Tiny models (all pointers near): DGROUP holds the entire program.

 * Small and medium models (data pointers near): DGROUP holds all globals
   and static variables including string literal data, plus the stack and
   the heap.

 * Large, compact, and huge models in Microsoft (data pointers far):
   DGROUP holds only initialized globals and static variables including
   string literal data, plus the stack and the near heap.

 * Large and compact models in Borland (data pointers far): DGROUP holds
   initialized and uninitialized globals and static variables including
   string literal data, but not the stack or heap.

 * Huge model in Borland (data pointers far): there is no DGROUP, so the
   64K limit doesn't apply.

 In all of the above, which is to say all six models in Microsoft C and
 all but huge in Borland C, DGROUP is limited to 64K including string
 literal data (which are treated as static data). This limitation is due
 to the Intel CPU's segmented architecture.

 For more information, see topics like "memory models" and "memory
 management" in the index of your compiler manual. Also for an extended
 general discussion of memory usage in Borland C programs, of which much
 applies to any C compiler in DOS see TI738.asc, downloadable as part of:

 <ftp://garbo.uwasa.fi/pc/c-lang/bchelp10.zip>