Checking stdin for new data

[veydel]

Has anyone been able to implement it on Windows in such way that the
program can be started from a telnet session, not just from a command
prompt in a native pseudo-DOS window? I tried all kinds of things, but non
worked. Conio.h _kbhit does not work on a redirected stdin, thus it seems
that low level IO library is out. Streams library functions. such as getc,
and scanf block until there's input (by design). Win32 lib (CreateFile,
etc) don't seem to allow asynchronous IO on the handle obtained with
GetStdHandle for the console. Other functions that operate on HANDLEs,
either only do sync IO or fail when called (only in 'telnet' execution
mode, of course). Functions that work on sockets (winsock2) refuse to deal
with file descriptors from other libabries... Does this sound crazy or
what? I hope that maybe I missed something. If you know the solution,
please, help and I promise you a 12-pack of Corona!

Vik

 

[Alexei A. Frounze]

Has anyone been able to implement it on Windows in such way that the
program can be started from a telnet session, not just from a command
prompt in a native pseudo-DOS window? I tried all kinds of things, but non
worked. Conio.h _kbhit does not work on a redirected stdin, thus it seems
that low level IO library is out. Streams library functions. such as getc,
and scanf block until there's input (by design). Win32 lib (CreateFile,
etc) don't seem to allow asynchronous IO on the handle obtained with
GetStdHandle for the console. Other functions that operate on HANDLEs,
either only do sync IO or fail when called (only in 'telnet' execution
mode, of course). Functions that work on sockets (winsock2) refuse to deal
with file descriptors from other libabries... Does this sound crazy or
what? I hope that maybe I missed something. If you know the solution,
please, help and I promise you a 12-pack of Corona!

IMO, what you're talking about is beyond the C (it's rather system specific)
and hence is OT here. Try asking at windows programming groups.

Alex
P.S. Don't drink to much of Corona yourself, it may degrade your thinking
capabilities.

 

[Skarmander]

Has anyone been able to implement it on Windows in such way that the
program can be started from a telnet session, not just from a command
prompt in a native pseudo-DOS window? I tried all kinds of things, but non
worked. Conio.h _kbhit does not work on a redirected stdin, thus it seems
that low level IO library is out. Streams library functions. such as getc,
and scanf block until there's input (by design). Win32 lib (CreateFile,
etc) don't seem to allow asynchronous IO on the handle obtained with
GetStdHandle for the console. Other functions that operate on HANDLEs,
either only do sync IO or fail when called (only in 'telnet' execution
mode, of course). Functions that work on sockets (winsock2) refuse to deal
with file descriptors from other libabries... Does this sound crazy or
what? I hope that maybe I missed something. If you know the solution,
please, help and I promise you a 12-pack of Corona!

Yes, off-topic.

That said, calling GetNumberOfConsoleInputEvents() on the handle you get
with GetStdHandle() should work even if stdin is redirected.

Otherwise, you can use getc() in a separate thread. Threading isn't part
of ISO C either, but it is part of POSIX and moderately more portable
than using the Win32 console functions directly.

S.

 

[Skarmander]

Skarmander wrote:

Otherwise, you can use getc() in a separate thread. Threading isn't part
of ISO C either, but it is part of POSIX and moderately more portable
than using the Win32 console functions directly.

Oh, silly me. You also obviously need a way to read characters one at a
time, rather than the line-oriented behaviour of standard getc().
<termios.h> or similar may be of help there.

S.

 

[veydel]

Getting console events did not seem to work on w2k over telnet. I know that
this post is slightly off topic, but I wasn't getting any responses from
more windows-specific forums... I considered using a separate thread with
stdio calls but it would change the behavior quite a bit... in a bad way.
Although what I ended up doing changed it even more I check if the
program was started from telnet and, if yes, don't check stdin at all. I
use a socket instead and listed to commands that come through the socket.
Which of course forced me to write a send_command piece... Windows lead to
fear, fear lead to anger... etc. Path to the dark side!

Thanks, folks.