Date: Mon, 24 May 1999 12:09:47 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Frank Heckenbach 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.