Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!abcfd20.larc.nasa.gov!ipsun.larc.nasa.gov!jcburt
From: jcburt@ipsun.larc.nasa.gov (John Burton)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Strange results with Turbo C program - Can you help?
Message-ID: <1990Nov19.142112.12313@abcfd20.larc.nasa.gov>
Date: 19 Nov 90 14:21:12 GMT
References: <29857@boulder.Colorado.EDU> <39630@ucbvax.BERKELEY.EDU>
Sender: news@abcfd20.larc.nasa.gov (USENET File Owner)
Organization: NASA Langley Research Center, Hampton, VA  USA
Lines: 47

In article <39630@ucbvax.BERKELEY.EDU> brand@janus.Berkeley.EDU writes:
>
>	I have been trying to port a large C program (actually a set of 
>programs) from Unix to MSDOS 3.3 for some time now but without success.
>After working around the peculiarities of the turbo C compiler and 
>linker I have finally gotten it to compile and link without error. The
>problem is now to run it!! When I do, I get the cryptic (unix-like)
>error message "Divide error". Please note that this EXACT program worked
>on unix without error.
>
>	Not to be put off, I tried using the integrated debugger (I 
>don't have the standalone one) and this time got an even stranger
>error message:
>
>	Write fault error writing device AUX
>	Abort, Retry, Ignore, Fail?
>although, I probably did something wrong when using the integrated 
>debugger.
>
>Each source file is compiled with the options:
>	-1 -mh -K -f -c -y -v
>
>and they are linked with the following options (via a response file):
>	/c /v /3 
>and the following library files:
>	\tc\lib\c0h 
>	\tc\lib\emu 
>	\tc\lib\mathh 
>	\tc\lib\ch
>
>Can anyone shed some light on this perplexing problem?
>
>Cheers,
>-Graham

Sorry I can't offer any help, but I'd be interested to hear 
any suggestions. I had the same problem when trying to port a 
DVI interpreter from unix to PC-DOS 4.01 using Turbo C. Once
I was able to compile it with no warnings/errors I tried 
running it and got DIVIDE ERROR. I was never able to track
down the problem. The only thing that I can think of that might
be the problem is the different memory management between the two
systems, and I was trying to grab too much memory...

John Burton
(jcburt@cs.wm.edu)
(jcburt@ipsun.larc.nasa.gov)