I have identified some programs that work correctly before running
gcc (V2) but hang the DOS window if I run them afterwards.  The
environment is either an 80386, 80486, or Pentium, and either
Windows 3.1 or Windows 95.  This problem only occurs if I try to
use one of the math coprocessor emulators (emu387.dxe or wmemu387.dxe)
with gcc.
 
The following is a list of programs identified so far...
 
LS       EXE        17,792  01-10-89  4:00p LS.EXE
MSD      EXE       155,538  03-10-92  3:10a MSD.EXE (version 2.00)
MSD      EXE       166,302  11-01-93  3:11a MSD.EXE (version 2.10)
MSD      EXE       166,099  07-11-95  9:50a MSD.EXE (version 2.13)
 
Here's a sample of what's happening...
 
    C:\>ls
        (lists the files in the current directory)
 
    C:\>gcc
    gcc.exe: No input files
 
    C:\>ls
        (lists the files in the current directory)
 
    set EMU=c:\djgppin\emu387.dxe
    set 387=n
 
    C:\>ls
        (lists the files in the current directory)
 
    C:\>gcc
    gcc.exe: No input files
 
    C:\>ls
        (window hangs until I kill it, even ^C doesn't do anything)
 
Does anybody have a clue about what's going on here?  This is keeping
me from transitioning from V1.12r4 to V2.00 because my home computer
is a 386 running Win95 without a 387 math coprocessor.

This is a bug in the Windows handling of the DPMI 1.0 extensions for
software FPU support.  The only workarounds are to get MS to fix it
(fat chance), find some other operating environment, or buy a box with
a built-in FPU.  Since the cost of the last option is almost free...

This looks about like a problem I encountered with djgpp2 and Win95, after calling gcc, programs compiled
with the old djgpp with go32 do not run (they seem to get caught in some busy loop). After killing the DOS
window and starting a new one, it works again.

I am not sure how the fpu exception trapping works, wouldn't it be possible to deinstall the
handler at the exit of the program?