Not enough core

[tif at cpe.UUCP]

Written  9:59 pm  Sep 12, 1988 by remsit.UUCP!rem in cpe:comp.unix.xenix
>I added the first one and put in added a few statements so I could
>check to see that it worked.  I then put in the second function (which calls
>the first) and everything compiled away just fine but when I went to run it,
>I got "Not enough core".
>Almost forgot: I'm running SCO Xenix 2.0.4.  The program is small model with
>               the -i switch, but medium model without it.  :-)

Once again (this is one of the questions that is up for election to be
added to news.newusers :-).  No offense, I've just answered it at least
a half-dozen times):

	1)  DGROUP is the limiting factor that will cause linking
	    problems or load-time problems.

	2)  (in small model) DGROUP contains everything but actual code.
	    We all know that both the code and ALL the data must be < 64K.
	    That's code + data < 64K if no -i option, or
	    code < 64K AND data < 64K if you use the -i option.

	3)  (In medium model) Code may be > 64K, data must be < 64K.  We
	    already knew that too.

	4)  (In large model) Code may be > 64K, ONLY UNITIALIZED GLOBAL
	    DATA may be > 64K, all other data (static, constants, initialized
	    globals, and stack) MUST BE < 64K.

	5)  (In huge model) The ONLY difference between huge and large is
	    that a single item (i.e. array) may be > 64K.

	6)  (In large model) If static + constants + initialized globals < 64K
	    then the linker will succeed.  Stack must be < (64K - static -
	    constants - initialized globals) for the executable to successfully
	    load.

In summary, in your case, it means that all the stuff in your program
fits inside of 64K.  But when the linker added the stack space it went
over 64K.  The linker doesn't report this, rather it shows up when the
executable is loaded (I mean executed).

Possible solutions are
	1.	go to large model, unitiliazed global data will be
		placed in a different segment.  That may be enough.
	2.	Reduce your stack size (-F #) where # < 0x1000.  Only
		you can decide if this is an option.
	2.	use -Gt##, try something between 32 and 256 for ##.
		Any global data larger than ## bytes will be put in
		a different segment.  Smaller ## are more likely to
		succeed but cause slower executables.

			Paul Chamberlain
			Computer Product Engineering, Tandy Corp.
			{convex,killer}!ninja!cpe!tif