www.delorie.com/djgpp/bugs/show.cgi   search  
Bug 000067

When Created: 03/13/1996 17:12:51
Against DJGPP version: 2.00
By whom: rsmith@baker.ds.boeing.com
Abstract: LS and MSD lock up window after running gcc.exe
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...
        (lists the files in the current directory)
    gcc.exe: No input files
        (lists the files in the current directory)
    set EMU=c:\djgppin\emu387.dxe
    set 387=n
        (lists the files in the current directory)
    gcc.exe: No input files
        (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.

Note added: 03/17/1996 14:52:57
By whom: sandmann@clio.rice.edu
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...

Note added: 04/11/1996 18:44:18
By whom: lehmann@mathematik.th-darmstadt.de
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?

Closed on 04/13/1999 09:00:24: We don't fix Windows bugs around here.
By whom: eliz@is.elta.co.il

  webmaster   donations   bookstore     delorie software   privacy  
  Copyright 2010   by DJ Delorie     Updated Jul 2010