Mail Archives: cygwin/2009/06/26/10:52:40
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
- Raw text -