Mail Archives: cygwin/2009/06/27/04:39:40
2009/6/26 Corinna Vinschen:
> On Jun 26 15:08, Julio Costa wrote:
>> 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 s=
ervice?
>>
>> 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. =C2=A0I 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. =C2=A0=
I'm
> still hoping for another solution.
How about implementing this idea solely in the Cygwin DLL rather than
through a service, i.e. the first process that needs a hidden console
allocates one, and any subsequent processes attach to that.
Only problem is that the console is automatically freed once all
processes using it have finished, so a new one would have to be
allocated again when another process comes along that needs one.
Still, the number of subliminal consoles flashing up would be much
reduced, and the proliferation of conhost.exes in the task manager
(and taskbar?) would be avoided.
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
- Raw text -