ptys - I give up

Daniel Colascione dancol@dancol.org
Fri Jul 26 17:10:00 GMT 2013


On 7/26/2013 9:35 AM, Corinna Vinschen wrote:
> On Jul 26 09:21, Daniel Colascione wrote:
>> On 7/26/2013 8:27 AM, Christopher Faylor wrote:
>>> On Thu, Jul 25, 2013 at 11:44:32PM -0700, Daniel Colascione wrote:
>>>
>>>> Ugly, only half-implemented, but better: a hook-based pseudoconsole
>>>> system for Windows.
>>>
>>> This is what I was holding out for.  The last time it came up here,
>>> people seemed vehemently opposed to the idea since implementations that
>>> do this (like the Console app and a couple of libraries floating around)
>>> seem to have to poll the console looking for data and that could result
>>> in data loss.
>>>
>>> I have had code (not mine) sitting in my Cygwin directory for years
>>> which does this but I couldn't 100% convince myself that the detractors
>>> for this idea weren't right.  Does your code work around this?
>>
>> I'm also against screen scrapers. That's why I wrote this library: it doesn't
>> poll. It actually intercepts console APIs and implements console handles as
>> pseudohandles, just like Windows <= 7 did, forwarding console API requests to a
>> server. Any console program that works with Windows 7 should work with this
>> library.
> 
> Out of curiosity, can you expand what you mean here?  I see a difference
> between Windows pre-7 and Windows 7 and later. 

Conhost exists to solve the problem Raymond Chen described here:
http://blogs.msdn.com/b/oldnewthing/archive/2007/12/31/6909007.aspx. Conhost
exists so there's something running with lower privileges that can draw console
UI --- it's a broker. The actual console-ing still happens entirely in user mode
though, with the functions in kernel32 conspiring to provide the illusion that
the system has something called a console handle.

In Windows 8, the implementation is completely different. There, console handles
are real kernel objects.

Anyway, that pre-8 Windows used pseudo-handles for console handles is a good
thing now. It means that any library that tries to intercept all console
functions doesn't need to emulate all possible operations on console handles:
instead, it just needs to emulate the operations Windows actually allowed on
console handles, which was actually a fairly limited subset of what's allowed
for handles in general.

Another way of saying it is that it's easy to fake console handles because
Windows, too, was faking all along.

> Before Windows 7, the
> consoles seemed to be handled entirely by the csrss process.  If you
> started bash directly, there was no other visible process involved.
> Starting with Windows 7 there's  suddenly a "conhost" process for each
> console.

Sure --- just like you might have an rxvt for each login shell. Now imagine if
an X server happened to provide an rxvt implementation in-process and that the
pty interface were entirely private to X and implemented by sending special WM
hints to X. That's the Windows pre-7 architecture.

> Just as a side note, Windows 7's new conhost also broke the method to
> start an invisible console by creating it in a new, invisible WindowStation,
> and that still hasn't been fixed in Windows 8, despite my bug report
> during the W7 beta...

I have no idea.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20130726/1084234a/attachment.sig>


More information about the Cygwin mailing list