This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: _kbhit


> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Michiel De Hoon
> Sent: Friday, February 10, 2006 5:58 PM
> To: cygwin@cygwin.com
> Subject: Re: _kbhit
> 
> > On Sun, Feb 05, 2006 at 01:17:33PM -0500, Michiel De Hoon wrote:
> > >For one of my software projects, I need the _kbhit 
> function to check 
> > >the console for keyboard input. While this function is present in 
> > >msvcrt.dll,
> it
> > >is missing from cygwin1.dll, so I started writing this function 
> > >myself
> (I'm
> > >hoping to contribute it to Cygwin if it works well).
> >
> > I really appreciate the sentiment of submitting code but 
> _kbhit is not 
> > a linux function (or <echo on>POSIX, POSIX, POSIX...</echo 
> off>) so it 
> > really isn't a candidate for inclusion in the Cygwin DLL.
> > 
> > cgf
> >
> Even though _kbhit is not a POSIX function, I think a valid 
> argument can be made to include it in Cygwin anyway.
> 
> First, some Cygwin programs will need this function to be 
> able to interact with the Windows OS.

That's simply not true.  They may *want* it so that they can interact with
cmd.exe, in which case they're not a "Cygwin program".

> Second, as the Cygwin 
> DLL is a replacement for msvcrt

It isn't intended to be that.  It's intended to be a POSIX-compliant C
runtime.

Sorry, I meant "Linux compliant".

> (and msvcrt.dll and 
> cygwin1.dll cannot be used together), developers may expect 
> to find the same functionality in cygwin1.dll as in msvcrt.dll.

They shouldn't expect that.  Even Microsoft agrees; that's why they put the
"_" on there.

> Whereas it is possible for each developer to add needed 
> functions missing in cygwin1.dll to their own source code, it 
> will lead to ugly #ifdef __CYGWIN__ statements and complicate 
> porting Windows programs to Cygwin (which is what I am 
> effectively doing). Finally, coding the _kbhit function is 
> not entirely
> straightforward: simply doing a select() on file descriptor 0 
> is inconsistent with _kbhit in msvcrt if stdin is redirected.
> 

If you're using _kbhit, I have to assume what you're trying to port is some
sort of DOS or Windows app with one of those glorious text-mode "GUI"s to
Cygwin.  If so, you're in luck: The Unix world has obsessively perfected the
Frankensteinian paradox of the Text-Mode GUI.  You want to look into
ncurses.  Using it, your app's TMGUI(tm) will run on everything from an
ancient VT05 terminal to the very latest multi-bajigahertz quad-banger
double-headed workstation running a VT05 terminal emulator!  WE CALL THIS
"PROGRESS"!

(Note: I am not making fun of your app, but rather 21st-century text-mode
GUIs in general)

> So, .... if I was able to convince you, I'd be happy to 
> submit a patch. If not, ... well for my own project a kbhit() 
> function based on select() is sufficient, so that'll work for 
> me at least.
> 

You may also want to look at MinGW.  They actually link with the real
msvcrt.dll.

> --Michiel.
> 
> Michiel de Hoon
> Center for Computational Biology and Bioinformatics Columbia 
> University 1150 St Nicholas Avenue New York, NY 10032

-- 
Gary R. Van Sickle
 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]