From: michael DOT mauch AT gmx DOT de (Michael Mauch)
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp AT delorie DOT com
Subject: Re: RHIDE -- author(s) please read this
Date: Wed, 12 Nov 1997 15:41:58 +0100
Message-Id: <346ea9be.11954179@unidui.uni-duisburg.de>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 971112141210 DOT 20379N-100000 AT is>
In-Reply-To: <Pine.SUN.3.91.971112141210.20379N-100000@is>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 12 Nov 1997 14:12:29 +0200 (IST), Eli Zaretskii wrote:

> On Wed, 12 Nov 1997, Michael Mauch wrote:
> 
> > DJGPP's kbhit() looks just at the keyboard buffer variables in DOS
> > memory - that's a fast method, but it doesn't allow multitaskers to
> > recognize that a program polls the keyboard most of its time.
> 
> IMHO, a better way is to use the `select' library function.  It is
> portable to Linux (and Unix in general) and calls `__dpmi_yield'
> internally while it waits.  It also has a time-out option.  Check it
> out in the library reference.

Yes, thank you for pointing that out. The only draw-back I see is that
it doesn't work if stdin is redirected.

> AFAIK, the effect of `__dpmi_yield' depends on the DPMI host and on
> the details of how the scheduler works and which parameters did you
> set e.g. in the Property Sheet of the DOS box on Windows 95.  Some
> DPMI 0.9 hosts don't do anything with that call.

Yes, somebody else posted that his mouse becomes bumpy in some cases
when he calls __dpmi_yield(). So calling it all the time is probably not
really a Good Idea.

OTOH, what do you think about an environment/_CRT0_FLAG option (like
LFN/_CRT0_FLAG_NO_LFN) that controls if kbhit() should call
__dpmi_yield() internally or not?

Regards...
		Michael