From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9701041727.AA15060@clio.rice.edu>
Subject:	Re: EMM386 (OpenDOS/Novell DOS 7 version) vs The World
To:	dj AT delorie DOT com (DJ Delorie)
Date:	Sat, 4 Jan 1997 11:27:25 -0600 (CST)
Cc:	rainer AT nntp-gateMathematik DOT Uni-Bielefeld DOT DE, djgpp-workers AT delorie DOT com
In-Reply-To:	<199701040117.UAA18507@delorie.com> from "DJ Delorie" at Jan 3, 97 08:17:26 pm

> No further work is being done with DJGPP version 1.  Does this problem
> exist in DJGPP version 2 also?

Yes.  We tinker with the FPU state using the DPMI 1.0 EXTENSIONS.  Instead
of just returning a carry flag to indicate this function isn't supported,
I'll guess they don't expect any function number this high and puke?  
In any case, we could add a switch to the "387" environment variable, like
"Y" to bypass all of this code, and hopefully let it work.

> Workers: Can we reliably detect the Novell EMM386 and work around
> this?  Sounds like a kludge, but the whole fpu emulation with DPMI has
> been a trifle sneaky from the beginning.

I would say first before trying to detect it, to see if the above hack
works at all on one of these boxes.  I never had access to one of these
boxes to debug the problem (much less code a fix).  Rainer seems to have
found the problem.  Adding the following lines to npxsetup.c MIGHT be a
way to test for the problem:

*** npxsetup.c	Sun Jan 14 01:56:16 1996
--- npxset2.c	Sat Jan  4 10:25:14 1997
***************
*** 66,69 ****
--- 66,71 ----

    cp = getenv("387");
+   if (cp && (tolower(cp[0]) == 'y'))
+     return;
    if (cp && (tolower(cp[0]) == 'n'))
      have_80387 = 0;


If doing this, linking to it before the libc, and "set 387=y" works around
the problem, then I'd worry about auto detection code.  In any case, this
code might be useful for debugging/diagnosis reasons.

- Raw text -