delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/01/03/15:11:48

To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: make/Windows/emu387
Date: Mon, 03 Jan 1994 12:00:27 -0800
From: Darryl Okahata <darrylo AT hpnmhjw DOT sr DOT hp DOT com>

> A current limitation to be aware of: go32 (1.11.maint1 and prior) does not
> support emu387 under DPMI.  make executes some FP instructions and the
> machine will hard crash.  

     Since we're talking about DJGPP make restrictions, I'd like to
point out a problem with DPMI: if DJGPP make uses DPMI instead of VCPI,
it uses 32-bit DPMI, which means that programs that use 16-bit DPMI
cannot be run from make (for some unfathomable reason, you cannot mix
the two, or so I am told).  It just won't work.  In particular, the
Borland compilers use DPMI, and can crash/hang the system if 32-bit DPMI
make tries to spawn them.  Ideally, the 16-bit DPMI program should check
to see if it can properly run, but the Borland 3.1 C/C++ compiler (among
others, I'm sure) does not check for this.

     I was told the following technical reason for this (which I'm not
sure that I understand):

-------------------------------------------------------------------------------
If a 32-bit DPMI client comes up under Windows, Windows'll put 32-bit
interrupt gates in the IDT.  If a 16-bit client then tries to
come up in the same IDT, there would indeed be serious problems.
-------------------------------------------------------------------------------

     If make uses VCPI, there isn't a problem, as mixing VCPI and 16-bit
DPMI appears to work just fine.

     -- Darryl Okahata
	Internet: darrylo AT sr DOT hp DOT com

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion or policy of Hewlett-Packard or of the
little green men that have been following him all day.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019