Date:	Mon, 24 May 1999 12:09:47 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Frank Heckenbach <frank AT tim DOT gerwinski DOT de>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: __dpmi_yield()
In-Reply-To:	<5A36B5C3.19990524010901.FOO-2F3A.frank@goedel.fjf.gnu.de>
Message-ID:	<Pine.SUN.3.91.990524120928.14456R-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 24 May 1999, Frank Heckenbach wrote:

> select() calls __dpmi_yield() to give up time slices, but
> __dpmi_yield() returns immediately with an error.

I think this is DOSEmu bug, right there: the *first* (if not the
*only*) way of calling real-mode services that they should support is
via the DPMI function.  Issuing INT 2Fh in protected mode is strictly
speaking a no-no, and relies on undocumented features of the
underlying OS and the DPMI host.

> Now, I don't know if the problem is with DJGPP or another program.
> The relevant program versions are Linux 2.2.9, DosEmu 0.98.4, NWDOS
> 7.0, CWSDPMI 0.90+ (r3), DJGPP 2.02, GCC 2.8.1 -- hope I didn't
> forget anything. ;-)

Perhaps the real cause of the problem is NWDOS?  Could you try this
with another DOS work-alike, or with MS-DOS?

> Anyway, it seems it could be fixed in DJGPP by calling the interrupt
> directly, if this doesn't have any bad side effects.

Alas, it has bad side effects, and very profound ones at that.
__dpmi_yield used to issue INT 2Fh directly, but was changed in v2.02
to go through __dpmi_int because some versions of Windows 9X would
wedge the DOS box when INT 2Fh was issued directly in nested DJGPP
programs.  We had quite a few bug reports like that which were all
traced to programs like RHIDE, Emacs, Less, and Info that called
__dpmi_yield and usually launch other DJGPP programs.

Wasting CPU time is bad, but wedging the entire DOS session is much
worse...

> But if it should be fixed elsewhere, I'd appreciate any pointers to
> the correct place to ask.

Perhaps you could ask the Linux DOSEmu gurus about this (I don't know
the appropriate forum; anybody?).  If they say that it should be
supported, then perhaps the DOS version is the culprit.

Another idea is to test this with other DOSEmu/Linux versions.  Could
people who have easy access to Linux please try that?

In any case, it's impossible to revert to the old behavior of issuing
INT 2Fh directly.  Personally, even doing that for DOSEmu alone
(provided that we have a reliable way of detecting it) is not
something I would recommend.  It is one thing to work around Windows
bugs, but doing the same with free software such as DOSEmu where
everything should be open to scrutiny and any bugs should be fixable,
doesn't sound good.

- Raw text -