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]

ttyfier (was: Re: Looking for the 'stdout' of a Windows application)


2009/12/13 Renà Berber:
> And there's the old 'ttyfier' which almost worked:
>
> http://sources.redhat.com/ml/cygwin/2006-03/msg00164.html
>
> I say almost because it assumes a fixed terminal size and it fails if
> the output exceeds that size, and there where other problems but the OP
> might find it good enough for the job.

Thanks, I had't heard of ttyfier. Interesting stuff! More
comprehensive than my 'conin' attempt because it tranlates output as
well as input.

The input side is relatively easy  to deal with actually, because
WriteConsoleInput lets you insert events directly into the console
input stream. The output side is much harder because there's no
straightforward way to intercept console output before it reaches the
screen buffer. Which is why ttyfier (in a similar way as Console2) has
to periodically copy the console screen contents to the terminal.

I see it injects the actual console processing code (in ttyfier.cc)
into the child process (via injlib.cc). Is that actually necessary? I
find the console input and output buffers can be accessed from the
parent process anyway, assuming of course it's attached to the same
console.

But the DLL injection makes me wonder: is it possible to override
existing functions such as WriteConsole or ReadConsole?

Andy

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


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