Date:	Thu, 11 Jun 1998 20:21:39 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc:	djgpp-workers AT delorie DOT com, Morten Welinder <terra AT diku DOT dk>
Subject:	Re: __dpmi_yield considered harmful (sometimes)
In-Reply-To:	<m0yjTy8-000S4CC@inti.gov.ar>
Message-ID:	<Pine.SUN.3.91.980611201454.26077B-100000@is>
MIME-Version:	1.0

On Tue, 9 Jun 1998, Salvador Eduardo Tropea (SET) wrote:

> Machine without problems (clean installation): vmm32.vxd 697318 bytes 
> 1998-06-04, 12:02
> Machine with more software installed: vmm32.vxd 710034 1998-05-19 12:21

Yes, I also see widely different VxDs.  Probably, optional packages come 
with their private versions of vmm32.vxd.  One particularly nasty fella 
I'd suspect is MSIE v4 (did you maybe installed one on the problematic 
machine?).

> But wait ... that isn't even the original!!! in the .cabs the file is 411132 
> bytes long.

That's the compressed size, I'd guess.

> Looks that the problem could be there, but is hard to know how or why the files 
> are so different. 

It actuallu turns out that not only function 1680h, but ALL functions of 
Int 2Fh wedge the DOS box when invoked from nested DPMI clients, if they 
are called via INT 2Fh instruction.  __dpmi_int works okay.

I searched the entire libc.a, but fortunately only __dpmi_yield calls
Int 2Fh.

It *is* something to avoid, though.  For example, Emacs called another 
function of 2Fh and it hung for me on that machine while building (where 
it is run from Make).

Seems like the Int 2Fh handler on Windows 95 is badly broken.

- Raw text -