Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!samsung!umich!sharkey!cfctech!teemc!fmeed1!cage
From: cage@fmeed1.UUCP (Russ Cage)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Porting UNIX apps. to MS-DOS
Summary: There are no quick fixes.
Message-ID: <8623@fmeed1.UUCP>
Date: 1 Nov 90 18:40:23 GMT
References: <1990Oct26.223541.26634@NCoast.ORG> <9449@jarthur.Claremont.EDU> <1990Oct31.190520.11526@Octopus.COM> <9478@jarthur.Claremont.EDU>
Reply-To: russ@m-net.ann-arbor.mi.us (Russ Cage)
Organization: Ford Motor Co., Electronics Div., Dearborn, MI
Lines: 25

In article <9478@jarthur.Claremont.EDU> dfoster@jarthur.Claremont.EDU (Derek R. Foster) writes:
>.... The technique I am using first fills up the "default"
>stack segment, <= 64k, then switches to a new one when that one is
>full, also <= 64k, for a resultant "effective" stack size of >64k.

There are two serious problems with this.

1.)	Unless all pointers are 'far', automatic variables
	from one function will not be accessible to functions
	past the stack-overflow mark; they will be in a
	different segment.

2.)	Unless careful copying of data from stack frame to
	stack frame is done on stack overflow, parameters to
	the called function could get lost.  Worse, the
	size of the parameter list in C is not known to
	functions such as printf()!

In my experience, it is easier to re-write the code to remove
the features which require excessive stack space.
-- 
Russ Cage	Ford Powertrain Engineering Development Department
Work:  itivax.iti.org!cfctech!fmeed1!cage   (CHATTY MAIL NOT ANSWERED HERE)
Home:  russ@m-net.ann-arbor.mi.us  (All non-business mail)
Member:  HASA, "S" division.