From: michael DOT mauch AT gmx DOT de (Michael Mauch) To: Eli Zaretskii 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: In-Reply-To: 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