--> Jason Hendriks wrote to All  <--
JH>With the Watcom compiler (10.6), I am having the worst time
JH>compiling my programs for DOS.  They work flawlessly in
JH>OS/2, compile without errors or warnings, the dos debugger
JH>even shows things going correctly right up to the moment of
JH>the trap.
JH> 
JH>I found that using "option stack = 9k" in the linker
JH>settings tames the program so that it runs to completion.
JH>Now what is all this about a stack?  What disadvantages are
JH>there for me setting it to 9k from the default 2k?
Make the stack as large as you have to--there is no serious disadvantage 
within reasonable limits. You should have some idea what you are doing 
that is gobbling up stack space. Are you using a lot of very large 
arrays as automatic data objects? Are you using recursive functions? 
Doesn't Watcom have a compiler option to track stack overflows? I would 
enable that and run the program.
JH>Another annoying problem for my DOS programs that
JH>increasing the stack size didn't cure, is sending data to a
JH>custom LogFile class, which writes it to the screen and
JH>then to a file.  Well, the program wouldn't work until I
JH>took out all references to the LogFile object.
Post the code for the LogFile class. It sounds like you are doing 
something wrong to the stream operator.
JH>Why would writing to the stream of this class cause a trap?  Should I
JH>be flushing the streams?  Should I be opening the logfile,
JH>writing to it, then closing it all within the member
JH>function of LogFile.Write (LogFile op<<).
I'd have to see the code. I can't see how flushing/not flushing is 
causing the errors.
X CMPQwk 1.42 1692 X"He that endureth to the end shall be saved." - Bible
--- Maximus/2 3.01
---------------