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.
signature.asc
Description: OpenPGP digital signature
