On Jun 26 15:08, Julio Costa wrote: > On Fri, Jun 26, 2009 at 14:36, Corinna Vinschen wrote: > > Yes, I'm aware how this would work. What I mean is, it's *still* a > > band-aid since in case of a fail to attach, you still have to alloc > > a console and you're back to the original problem. What we could do > > using that technique is to minimize the number of console windows. > > But it doesn't help to avoid them entirely. You have still cluttered > > your desktop, or rather, your taskbar with console windows. > > > > I've been following this discussion, crossing fingers to someone came > to some conclusion, as this is the biggest show-stopper for Cygwin in > several months. > > I've not access to a Win 7, but I would like at least to drop some > ideas to someone with more insight comment on and (hopefully) come to > a solution. > > 1) If we make a service (let's call it cygconsole, or include it in > cygserver, whatever), with no desktop interaction, whose only purpose > is to AllocConsole()... > 1.a) do that console gets created? > 1.b) Is it invisible? > > 2) IF the two answers are true, then > 2.a) Do an arbitary process can do an attachconsole to the PID of that > service? > > IF it is also an YES, we have a framework for an > workaround/alternative implementation! Cool?
It's an interesting idea, but rather tricky to implement. I assume you will get an ERROR_ACCESS_DENIED when trying to attach to a console of another user, and a cygserver service would usually run under SYSTEM. Relying on a service at all doesn't sound overly tempting, either. I'm still hoping for another solution. Thanks anyway, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
