process steering with pipes

[Hans J?rg Brinksmeyer]

Hi,

does anyone have an idea for this problem:

I use anonymous pipes to steer a console program under Win2000 with a
second 'steering aplication'. The stdin and output are redirected to
pipes.

The console application has several fgets() and fgetc() to read
strings and chars. This works very fine with the pipes.

But, there is one point where the console application uses kbhit() and
waits for a key to be hit. It seems not possible to use the pipes to
get out of the loop

while( ! kbhit() )...
I do not want to use the keyboard and I can not change the console
application, since I do not have the sources.

Is there a way to make the one program simulate this event in a way
that the console application's line while(!kbhit())... is satisfied?

Thanks a lot,
Hans J. Brinksmeyer

[Lawrence Kirby]

On Thu, 02 Dec 2004 08:30:13 -0800, Hans J?rg Brinksmeyer wrote:

Hi,

does anyone have an idea for this problem:

I use anonymous pipes to steer a console program under Win2000 with a
second 'steering aplication'. The stdin and output are redirected to
pipes.

The console application has several fgets() and fgetc() to read
strings and chars. This works very fine with the pipes.

But, there is one point where the console application uses kbhit() and
waits for a key to be hit. It seems not possible to use the pipes to
get out of the loop

while( ! kbhit() )...

Unfortunately kbit() (and indeed "anonymous pipes") are not defined by the
C programming language, they are Windows related features. A good place
to discuss them would be comp.os.ms-windows.programmer.win32.
I do not want to use the keyboard and I can not change the console
application, since I do not have the sources.

Is there a way to make the one program simulate this event in a way that
the console application's line while(!kbhit())... is satisfied?

Again, the C language doesn't begin to address an issue like this, ask the
Windows experts.

Lawrence

[Merrill & Michele]

"Lawrence Kirby"

Hans J?rg Brinksmeyer wrote:

[OT OP snipped]
Unfortunately kbit() (and indeed "anonymous pipes") are not defined by the
C programming language, they are Windows related features. A good place
to discuss them would be comp.os.ms-windows.programmer.win32.

Rats! I thought not having to deal with crappy plumbing was the silver
lining to using my platform. A fresh hell awaits.... MPJ

[CBFalconer]

Merrill & Michele wrote:

"Lawrence Kirby"

Hans J?rg Brinksmeyer wrote:

[OT OP snipped]

Unfortunately kbit() (and indeed "anonymous pipes") are not defined by the
C programming language, they are Windows related features. A good place
to discuss them would be comp.os.ms-windows.programmer.win32.

Rats! I thought not having to deal with crappy plumbing was the silver
lining to using my platform. A fresh hell awaits.... MPJ

Now what does this add to the discussion other than noise? Every
article need not be treated as a fresh opportunity for a "witty"
comment. I am not ROTFLMAO.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Hans J?rg Brinksmeyer]

> A good place

to discuss them would be comp.os.ms-windows.programmer.win32.

Lawrence,

thank you for this hint. I'm not a C expert ;-)
Since I thought the console app is designed in plain C I have choosen
this forum here.

Best regards,
Hans

[Merrill & Michele]

"CBFalconer"

Merrill & Michele wrote:

"Lawrence Kirby"
Hans J?rg Brinksmeyer wrote:

[OT OP snipped]

Unfortunately kbit() (and indeed "anonymous pipes") are not defined by the C programming language, they are Windows related features. A good place
to discuss them would be comp.os.ms-windows.programmer.win32.

Rats! I thought not having to deal with crappy plumbing was the silver
lining to using my platform. A fresh hell awaits.... MPJ

Now what does this add to the discussion other than noise? Every
article need not be treated as a fresh opportunity for a "witty"
comment. I am not ROTFLMAO.

Every five minutes, a unix user posts something about pipes not working. I
didn't think it was an issue for my platform, but apparently it is. I was
happy to learn simultaneously of the existence and non-conforming nature of
anonymous pipes. MPJ

[mef526]

If this is REALLY what you've got to do then the remote process and use some
assembly code and do "out"'s to the chip that handles the KB IO. This is
typically an 8048 or 8042 Intel chip, and the port to out to is 60H. Once
this port is written to the 8259 Interrupt controller will fire, and you
could get the address from there instead and just fire that int handler.

An easier way may be to use the MS-DOS interrupt 09 (INT 09) which is a BIOS
handler for the keyboard.

A HUGE downside is that you have to have a controller system where you know
a user is NOT at the keyboard. It is actually a big kluge that I would NEVER
do. Why do you need to use a pipe anyways? Is the code already written for
the process that you are piping to?

"Hans J?rg Brinksmeyer" <ha********************@iav.de> wrote in message
news:9f**************************@posting.google.c om...

Hi,

does anyone have an idea for this problem:

I use anonymous pipes to steer a console program under Win2000 with a
second 'steering aplication'. The stdin and output are redirected to
pipes.

The console application has several fgets() and fgetc() to read
strings and chars. This works very fine with the pipes.

But, there is one point where the console application uses kbhit() and
waits for a key to be hit. It seems not possible to use the pipes to
get out of the loop

while( ! kbhit() )...
I do not want to use the keyboard and I can not change the console
application, since I do not have the sources.

Is there a way to make the one program simulate this event in a way
that the console application's line while(!kbhit())... is satisfied?

Thanks a lot,
Hans J. Brinksmeyer

[Joona I Palaste]

mef526 <mi******@removecodeinsight.com> scribbled the following:

If this is REALLY what you've got to do then the remote process and use some
assembly code and do "out"'s to the chip that handles the KB IO. This is
typically an 8048 or 8042 Intel chip, and the port to out to is 60H. Once
this port is written to the 8259 Interrupt controller will fire, and you
could get the address from there instead and just fire that int handler. An easier way may be to use the MS-DOS interrupt 09 (INT 09) which is a BIOS
handler for the keyboard. A HUGE downside is that you have to have a controller system where you know
a user is NOT at the keyboard. It is actually a big kluge that I would NEVER
do. Why do you need to use a pipe anyways? Is the code already written for
the process that you are piping to?

Could you please discuss implementation-specific issues on an
implementation-specific newsgroup? This might come as a shock to you,
but not all systems have MS-DOS interrupts.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"As we all know, the hardware for the PC is great, but the software sucks."
- Petro Tyschtschenko

[Lawrence Kirby]

On Fri, 03 Dec 2004 00:19:19 -0800, Hans J?rg Brinksmeyer wrote:

A good place
to discuss them would be comp.os.ms-windows.programmer.win32.

Lawrence,

thank you for this hint. I'm not a C expert ;-)
Since I thought the console app is designed in plain C I have choosen
this forum here.

It is possible to run standard C apps as console applications, just as it
is possible to, say, run them from a Unix shell command prompt. However
each platform provides a myriad of extensions (i.e. non-standard features)
that can also be used (AFAIK console application can use pretty much the
full Win32 API). Your question was about keyboards and kbhit() which are
not covered by standard C, i.e. one of those extensions.

Lawrence

[jacob navia]

Hans J?rg Brinksmeyer wrote:

Hi,

does anyone have an idea for this problem:

I use anonymous pipes to steer a console program under Win2000 with a
second 'steering aplication'. The stdin and output are redirected to
pipes.

The console application has several fgets() and fgetc() to read
strings and chars. This works very fine with the pipes.

But, there is one point where the console application uses kbhit() and
waits for a key to be hit. It seems not possible to use the pipes to
get out of the loop

while( ! kbhit() )...
I do not want to use the keyboard and I can not change the console
application, since I do not have the sources.

Is there a way to make the one program simulate this event in a way
that the console application's line while(!kbhit())... is satisfied?

Thanks a lot,
Hans J. Brinksmeyer

I do not think so. The problem is that kbhit() probably doesn't use
stdin or stdout at all but reads directly from the keyboard...