Message-ID:	<B0000032327@stargate.astr.lu.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>,
	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Thu, 11 Jun 1998 21:35:40 +0300
MIME-Version:	1.0
Subject:	Re: __dpmi_yield considered harmful (sometimes)
CC:	djgpp-workers AT delorie DOT com
References:	<m0yjTy8-000S4CC AT inti DOT gov DOT ar>
In-reply-to:	<Pine.SUN.3.91.980611201454.26077B-100000@is>

Date sent:      	Thu, 11 Jun 1998 20:21:39 +0300 (IDT)
From:           	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Subject:        	Re: __dpmi_yield considered harmful (sometimes)

> 
> 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.
> 

I extensively used 'INT 2Fh' in one my TSR. Initially my applications that 
communicates with this TSR were written for real mode (Borland C++ 3.1). 
After that I changed to DJGPP. I now tested the source and saw that I have 
used __dpmi_int for all INT 2Fh calls (even if all data are transfered through 
registers). Initially I used also  INT 2Fh directly (other libc functions, but not 
__dpmi*). I had problems debugging this stuff under Win95 and as the cure 
changed to __dpmi_int(). As I remeber I had problems also when all data
are transfered in registers (not segment ones).

Andris

- Raw text -