Mail Archives: cygwin/2009/07/02/12:41:56
On Sun, Jun 28, 2009 at 11:30, Corinna Vinschen wrote:
> On Jun 27 09:39, Andy Koppe wrote:
>> 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 tha=
t 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. =C2=A0I assu=
me
>> > 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 SYSTE=
M.
>> > Relying on a service at all doesn't sound overly tempting, either. =C2=
=A0I'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.
That could be better only because it's more "manageable".
But the service idea was precisely because I guess it's now the only
way in Win7 to get an invisible console.
>>
>> 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.
Yes, that is another downside, but still, it's an evolution
>
> Yeah, that could be an option as a per-session workaround if there's
> no other way to accomplish it.
>
Speaking of that, I don't yet have another proposal or even a more
concrete on my own proposed design, but until happier days, I' ve
found that we can skip the console window flashing altogether if we
write this registry key PRIOR to AllocConsole():
HKCU\Console\<argv[0]>\WindowPosition =3D 0x80008000, where <argv[0]>
is the name of current command being launched
Yes, I know, more klumsy workaround... I'm not happy with that also,
but at least avoids the console *window* flashing.
Alas, the ShowWindow stuff it's still needed for the taskbar icon :(
As for my service proposal, the only concrete result so far is an
error (bleah!) when AttachConsole.
Curiously, not the ERROR_ACCESS DENIED, but the 31 (ERROR_GEN_FAILURE)...
The next step is to play a little with security descriptors on the
created console, but before I dive deeper, I'd like to make a stupid
question...
Why on Earth are we having this trouble to have an available console
all the time? Is it necessary to redirect the in/out streams? Is it
another thing?
I'm really trying to think 'out of the box', because it could be the
case that there is another implementation path that doesn't really
need consoles at all...
--=20
___________
Julio Costa
--
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 -