Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!mcvax!ukc!kcl-cs!phil
From: phil@kcl-cs.UUCP
Newsgroups: net.micro.pc
Subject: Re: Help Requested for MicroEMACS 3.6 using Microsoft C
Message-ID: <718@neon.kcl-cs.UUCP>
Date: Wed, 16-Jul-86 10:28:36 EDT
Article-I.D.: neon.718
Posted: Wed Jul 16 10:28:36 1986
Date-Received: Fri, 18-Jul-86 06:25:39 EDT
References: <513@quad1.UUCP>
Reply-To: phil@kcl-cs.UUCP (PUT YOUR NAME HERE)
Organization: Department of Computing, Kings College, University of London.
Lines: 25

In article <513@quad1.UUCP> john@quad1.UUCP writes:
>I am finally getting around to compiling MicroEMACS 3.6 under Microsoft
>C.  I compiled it large model ....
>
>When I run it, I immediately get a "stack overflow" message. I have set
>the stack size for 0x4000. That should be more than enough.  I am not
>aware of any "fixes" that should be applied. Can anybody steer me in
>the right direction?

I had a similar problem when recently developing a large program with this
compiler. It may not be the same problem but it will be of interest to others.

The symptoms where exactly as described above. If you produce a MAP file you
should count up how much space is used by the DGROUP class. I found that this
was more than 64K. DGROUP is the default data segment but the linker does not
check to make sure that it will fit into a physical segment.

Now the solution. Whenever I have a global variable that is only accessed
within a single module (source file) I always declare it in that module as
static. The compiler always puts all such globals in DGROUP. Globals that
are accessable from the whole program are placed in FAR_BSS (as far as I
can remember) which is allocated different physical segments. There all I
had to do was delete the word "static" in the declaration of a large array.

Phil Thompson.