Re: _kbhit

Re: _kbhit

[Michiel De Hoon]

Gary R. Van Sickle wrote:
> > First, some Cygwin programs will need _kbhit 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".

If:
1) A program needs to run a Windows message loop;
2) This message loop should be exited when user input is available on stdin;
3) The program needs to link to cygwin1.dll;
then it is a Cygwin program that needs _kbhit (either present in the DLL or
implemented by myself using select()), isn't it?

--Michiel.

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


--
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/

Re: _kbhit

[Christopher Faylor]

On Mon, Feb 13, 2006 at 12:10:25PM -0500, Michiel De Hoon wrote:
>Gary R. Van Sickle wrote:
>>> First, some Cygwin programs will need _kbhit 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".
>
>If:
>1) A program needs to run a Windows message loop;
>2) This message loop should be exited when user input is available on stdin;
>3) The program needs to link to cygwin1.dll;
>then it is a Cygwin program that needs _kbhit (either present in the DLL or
>implemented by myself using select()), isn't it?

Please go back and read the first few sentences at the cygwin web site.
When you do that, you'll note that this project is not intended to offer
the Windows API to programs.

Please stop arguing about this.  As much as you may want this, it's not
going to happen.

cgf

--
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/

RE: _kbhit

[Dave Korn]

On 13 February 2006 17:10, Michiel De Hoon wrote:

> Gary R. Van Sickle wrote:
>>> First, some Cygwin programs will need _kbhit 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".
> 
> If:
> 1) A program needs to run a Windows message loop;

-  Then it's not a POSIX program.

> 2) This message loop should be exited when user input is available on stdin;

-  Then if it's running a windows message loop, it should be looking for
WM_KEYDOWN.  (_kbhit is a remnant from the late '80s DOS 3.x int 21h call
interface; I don't know if it's even guaranteeed to play nicely with windows
message queues in any case, is it?  It certainly requires a console to be
available at the very least...)

-  And if it's trying to be a POSIX program, it should use the POSIX way of
doing that (cf. select/ncurses/footnote[*] qv).

> 3) The program needs to link to cygwin1.dll;
> then it is a Cygwin program that needs _kbhit (either present in the DLL or
> implemented by myself using select()), isn't it?

  No.

  It's a MinGW program that has been compiled for the wrong environment.





  The key is in the word "needs" to link to cygwin1.dll.

  Why would any app (in general, and yours in particular) /need/ to link to
cygwin1.dll?  The only reason is for the POSIX/Unix/Linux compatibility it
provides, because that is _all_ that cygwin1.dll does.

  You will never want to write a fullly POSIX/Unix/Linux-compatible
application that contains a Windows message loop, because then it's not a
POSIX/Unix/Linux-compatible application, by definition.

  If you're writing what is fundamentally a Windows program, and just want a
few library functions to provide you with posix-alike functionality, that is
/exactly/ the definition of MinGW.  Use it instead.

  If you want a full POSIX/Unix/Linux-compatible environment that runs on
windows, you want Cygwin, but then you don't want to write windows message
loops, or your code won't be POSIX/Unix/Linux-compatible.

 
    cheers,
      DaveK

[*] - Ok.  Here ya go: "_kbhit() for Linux".
http://www.flipcode.org/cgi-bin/fcarticles.cgi?show=64166
Considering that this is hit #1 on google when you enter the term "_kbhit", it
seems blatantly clear that you haven't made even a token effort to STFW.
-- 
Can't think of a witty .sigline today....


--
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/

RE: _kbhit

[skaller]

On Mon, 2006-02-13 at 18:11 +0000, Dave Korn wrote:

>   Why would any app (in general, and yours in particular) /need/ to link to
> cygwin1.dll?  The only reason is for the POSIX/Unix/Linux compatibility it
> provides, because that is _all_ that cygwin1.dll does.

It is quite possible this need arises naturally in a dynamically 
linked application, where for one reason or another you end up 
mixing and matching plugins. After all, cygwin1.dll is just a 
Windows dll.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


--
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/

Re: _kbhit

[Arend-Jan Westhoff]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

At 18:58 2006-02-10 -0500, Michiel de Hoon wrote:
>> 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.
>>=20
>> 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. Second, as the Cygwin DLL is a replacement for msvcrt
>(and msvcrt.dll and cygwin1.dll cannot be used together), [snip]

I cannot confirm your assertion that msvcrt.dll and cygwin1.dll cannot be
used 
together. If I compile the attached (almost C) file that dynamically links to 
msvcrt.dll using Cygwin:
	gcc -o kbhit.exe kbhit.cpp
it compiles, links and works (on CMD and bash on CMD but not on rxvt; as 
stated elsewhere in this thread the Microsoft _kbhit is not very good).

HTH,

Arend-Jan Westhoff.

[-- Attachment #2: kbhit.cpp --]
[-- Type: text/plain, Size: 459 bytes --]

#include <stdio.h>
#include <windows.h>

extern "C" {
	typedef int (*int_function_void_t)(void);

	HINSTANCE gimmeMSVCRT() {
		static HINSTANCE retval = LoadLibrary("MSVCRT.DLL");
		return retval;
	}

	int _kbhit(void) {
		static int_function_void_t f = (int_function_void_t) GetProcAddress(gimmeMSVCRT(), "_kbhit");
		return f();
	}
} // extern "C"

int main() {
	printf("Hit me!"); fflush(stdout);
	while(!_kbhit())
		;
	printf("\nOuch!!\n");
	return 0;
}


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/

RE: _kbhit

[Gary R. Van Sickle]

> 
> I cannot confirm your assertion that msvcrt.dll and 
> cygwin1.dll cannot be used together. If I compile the 
> attached (almost C) file that dynamically links to msvcrt.dll 
> using Cygwin:
> 	gcc -o kbhit.exe kbhit.cpp
> it compiles, links and works (on CMD and bash on CMD but not 
> on rxvt; as stated elsewhere in this thread the Microsoft 
> _kbhit is not very good).
> 
> HTH,
> 
> Arend-Jan Westhoff.

The Gary Exclusion Principle:  Two C runtimes cannot occupy the same point
in space at the same moment in time.  

A corollary to that:  "Worked" and "Works" are not the same thing.

-- 
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/

Re: _kbhit

[Shankar Unni]

Gary R. Van Sickle wrote:

 > Arend-Jan Westhoff writes:
>> I cannot confirm your assertion that msvcrt.dll and 
>> cygwin1.dll cannot be used together. 

> The Gary Exclusion Principle:  Two C runtimes cannot occupy the same point
> in space at the same moment in time.  

The problem here is that unfortunately they *can* occupy the same point 
in space at the same time, with the same bad effects as in science 
fiction movies when one object materializes in the middle of another :-).

The problem is that, for instance, some of your malloc calls will link 
to the cygwin libc, while others (from within the Windows DLLs) will 
link to MSVCRT, and if you free the pointer with the "other" library, 
terrible things will happen.


--
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/

Re: _kbhit

[Christopher Faylor]

On Fri, Feb 17, 2006 at 12:27:52PM -0800, Shankar Unni wrote:
>Gary R. Van Sickle wrote:
>>Arend-Jan Westhoff writes:
>>>I cannot confirm your assertion that msvcrt.dll and cygwin1.dll cannot
>>>be used together.
>
>>The Gary Exclusion Principle: Two C runtimes cannot occupy the same
>>point in space at the same moment in time.
>
>The problem here is that unfortunately they *can* occupy the same point
>in space at the same time, with the same bad effects as in science
>fiction movies when one object materializes in the middle of another
>:-).
>
>The problem is that, for instance, some of your malloc calls will link
>to the cygwin libc, while others (from within the Windows DLLs) will
>link to MSVCRT, and if you free the pointer with the "other" library,
>terrible things will happen.

Details, details.

The bottom line comes down to sheer will.  If someone really wants
_kbhit then, with enough reinstalls, and email messages stating that
fact, it will surely happen regardless of runtimes or exclusionary
principles.

Human spirit and indomitable determination trumps all!

cgf

--
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/

RE: _kbhit

[Gary R. Van Sickle]

> From: Shankar Unni
> Sent: Friday, February 17, 2006 2:28 PM
> To: cygwin@cygwin.com
> Subject: Re: _kbhit
> 
> Gary R. Van Sickle wrote:
> 
>  > Arend-Jan Westhoff writes:
> >> I cannot confirm your assertion that msvcrt.dll and cygwin1.dll 
> >> cannot be used together.
> 
> > The Gary Exclusion Principle:  Two C runtimes cannot occupy 
> the same 
> > point in space at the same moment in time.
> 
> The problem here is that unfortunately they *can* occupy the 
> same point in space at the same time, with the same bad 
> effects as in science fiction movies when one object 
> materializes in the middle of another :-).
> 

Exactly: Attempting to violate the Gary Exclusion Principle can only result
in tragedy.  In this case, the computer turns into a particle so dense not
even light can escape.

> The problem is that, for instance, some of your malloc calls 
> will link to the cygwin libc, while others (from within the 
> Windows DLLs) will link to MSVCRT, and if you free the 
> pointer with the "other" library, terrible things will happen.

Ah yes, the Gump Uncertainty Principle: You never know which malloc you're
going to get.

-- 
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/

Re: _kbhit

[Michiel De Hoon]

> 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. Second, as the Cygwin DLL is a replacement for msvcrt
(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.
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.

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.

--Michiel.

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


--
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/

RE: _kbhit

[Gary R. Van Sickle]

> 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/