Xref: news-dnh.mv.net comp.os.msdos.djgpp:1747
Path: news-dnh.mv.net!mv!news.sprintlink.net!gatech!newsfeed.pitt.edu!nntp.club.cc.cmu.edu!cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!newsfeed.rice.edu!rice!news!sandmann
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP V2.0 beta and Coprocessors
Date: Fri, 25 Aug 1995 00:34:50 CDT
Organization: Rice University, Houston, Texas
Lines: 13
References: <9523212 DOT 5107 AT mulga DOT cs DOT mu DOT OZ DOT AU>
Reply-To: sandmann AT clio DOT rice DOT edu
Nntp-Posting-Host: clio.rice.edu
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

> V2 message saying something like coprocessor not availiable at address so'n'so.
> I haven't tried EMU387=, but set 387=n works. (note: dos env, not djgpp.env)

The environment variable EMU387 is needed to run FPU requiring programs which
aren't in %djdir%/bin (which is probably only your apps).  Putting 387=N in
djgpp.env should be functionally the same as putting it as a DOS env variable
for this purpose.

But anyway, code was added to beta 2 to supposedly fix this, but I guess with
nested programs it's still not right yet.  The problem is the developer who
did this work (me) doesn't have any FPU-less machines to test it on, so I
tested it with 387=n on my box.  Someone with a real FPU-less box is going
to have to do some work on this to find my bug.