popup consoles on Windows 7

[Andy Koppe]

Thanks, Chuck and Dave for pointing me towards 'objdump -p'. I'd got
as far as trying objdump, but hadn't spotted the -p option.

MinTTY is a -mwindows app, which so far seemed to work well on XP and
Vista, because no console is popped up, not even momentarily. Not so
on Windows 7, unfortunately. forkpty() and execve() are used to create
the child process and invoke the command, whereby it appears to be the
exec call that causes a console to pop up.

I guess the fact that rxvt is a CUI app explains why its trick for
creating a hidden console didn't work in MinTTY: rxvt opens that
console in the main process, which in a GUI app isn't passed down to a
child process.

So here's what I've done instead in 0.4-beta1: call AttachConsole(-1)
to attach to any parent console from the main mintty process, and call
it again from the child process to pass it down to that. If there is
no console, create one using AllocConsole (in the child process), and
hide it using ShowWindowAsync.

Unfortunately two problems have been reported with this. The console
isn't always hidden, and a really weird one on a 64-bit Windows 7:
when invoking mintty from a bash running in a console, that console
window locks up. I'm rather stuck on what to do about those, so
suggestions would be welcome.

Also, a couple of questions.

When mintty is invoked from a shortcut or the Run dialog, the main
process actually does get a console, i.e. GetConsoleWindow() returns a
handle, but it doesn't appear on the screen, and the child process
can't attach to it using AttachConsole(). When invoked from a console
or rxvt, GetConsoleWindow() returns null. What's the reason for that?

Furthermore, I'd previously seen the popup console problem on an old
Cygwin install on XP, but updating cured it. So has this been
addressed in the Cygwin DLL in the past, and is it likely that it can
be solved for Windows 7 too? Any idea what might have changed in
Windows that causes this issue?

Btw, XWin is affected by this too. Starting it from a shortcut on
Vista is fine, but on 7 multiple consoles pop up briefly, and one
stays up.

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Andy Koppe]

I think I found the reason why consoles pop up for mintty and XWin on
Windows 7. Cygwin's fhandler_console.cc uses a clever trick where it
allocates a console on an invisible custom "window station". I tried
to do the same in the mintty child process, but found that
AllocConsole() no longer cares whether a custom window station has
been selected with SetProcessWindowStation(): the console window is
opened on the default window station anyway.

Here's what I did, between forkpty() and exec():

    DWORD version = GetVersion();
    version = ((version & 0xff) << 8) | ((version >> 8) & 0xff);
    if (version >= 0x0601) {
      HWINSTA wst0 = GetProcessWindowStation();
      HWINSTA wst = CreateWindowStation (NULL, 1, WINSTA_ALL_ACCESS, &sa);
      SetProcessWindowStation(wst);
      AllocConsole();
      SetProcessWindowStation(wst0);
      CloseWindowStation(wst);
    }

Debug output showed that the function calls all succeeded, and that
CreateWindowStation() did create a station separate from the default
one.

No idea what to do about it ...

Andy


2009/4/5 Andy Koppe:

> MinTTY is a -mwindows app, which so far seemed to work well on XP and
> Vista, because no console is popped up, not even momentarily. Not so
> on Windows 7, unfortunately. forkpty() and execve() are used to create
> the child process and invoke the command, whereby it appears to be the
> exec call that causes a console to pop up.
>
> I guess the fact that rxvt is a CUI app explains why its trick for
> creating a hidden console didn't work in MinTTY: rxvt opens that
> console in the main process, which in a GUI app isn't passed down to a
> child process.
>
> So here's what I've done instead in 0.4-beta1: call AttachConsole(-1)
> to attach to any parent console from the main mintty process, and call
> it again from the child process to pass it down to that. If there is
> no console, create one using AllocConsole (in the child process), and
> hide it using ShowWindowAsync.
>
> Unfortunately two problems have been reported with this. The console
> isn't always hidden, and a really weird one on a 64-bit Windows 7:
> when invoking mintty from a bash running in a console, that console
> window locks up. I'm rather stuck on what to do about those, so
> suggestions would be welcome.
>
> Also, a couple of questions.
>
> When mintty is invoked from a shortcut or the Run dialog, the main
> process actually does get a console, i.e. GetConsoleWindow() returns a
> handle, but it doesn't appear on the screen, and the child process
> can't attach to it using AttachConsole(). When invoked from a console
> or rxvt, GetConsoleWindow() returns null. What's the reason for that?
>
> Furthermore, I'd previously seen the popup console problem on an old
> Cygwin install on XP, but updating cured it. So has this been
> addressed in the Cygwin DLL in the past, and is it likely that it can
> be solved for Windows 7 too? Any idea what might have changed in
> Windows that causes this issue?
>
> Btw, XWin is affected by this too. Starting it from a shortcut on
> Vista is fine, but on 7 multiple consoles pop up briefly, and one
> stays up.
>
> Andy
>

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Corinna Vinschen-2]

On Apr 15 16:14, Andy Koppe wrote:

> I think I found the reason why consoles pop up for mintty and XWin on
> Windows 7. Cygwin's fhandler_console.cc uses a clever trick where it
> allocates a console on an invisible custom "window station". I tried
> to do the same in the mintty child process, but found that
> AllocConsole() no longer cares whether a custom window station has
> been selected with SetProcessWindowStation(): the console window is
> opened on the default window station anyway.
>
> Here's what I did, between forkpty() and exec():
>
>     DWORD version = GetVersion();
>     version = ((version & 0xff) << 8) | ((version >> 8) & 0xff);
>     if (version >= 0x0601) {
>       HWINSTA wst0 = GetProcessWindowStation();
>       HWINSTA wst = CreateWindowStation (NULL, 1, WINSTA_ALL_ACCESS, &sa);
>       SetProcessWindowStation(wst);
>       AllocConsole();
>       SetProcessWindowStation(wst0);
>       CloseWindowStation(wst);
>     }
>
> Debug output showed that the function calls all succeeded, and that
> CreateWindowStation() did create a station separate from the default
> one.
>
> No idea what to do about it ...

Treat it as a bug in Windows 7, probably.  Do you get the console window
as soon as you call AllocConsole, or does it open later?  If so, it
could also be the Cygwin code which allocates another console for some
reason.

If the above code also allocs a console window when run from a non-cygwin
(mingw) application, then this should be reported as a bug to Microsoft.
As long as W7 is beta, there's a good chance it gets fixed before it
will be released.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Andy Koppe]

Corinna Vinschen:
> Treat it as a bug in Windows 7, probably.  Do you get the console window
> as soon as you call AllocConsole, or does it open later?

It opens when invoking AllocConsole(). If I take out both the
AllocConsole() and the execve(), no console is opened.


> If so, it could also be the Cygwin code which allocates another console for some reason.

Without the AllocConsole in mintty, I think it's the AllocConsole in
fhandler_console::need_invisible() that opens the console window.
Previously it went to the invisible window station created for that
purpose, but now it doesn't.


> If the above code also allocs a console window when run from a non-cygwin
> (mingw) application, then this should be reported as a bug to Microsoft.

Okay, I'll try that. Any tips on how best to report Cygwin-related bugs to MS?

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Andy Koppe]

Corinna Vinschen:
> If the above code also allocs a console window when run from a non-cygwin
> (mingw) application, then this should be reported as a bug to Microsoft.

I can confirm this one now. This little test opens a console window on
7, but not Vista, when compiled with 'gcc -mno-cygwin -mwindows'.

int
main(void)
{
  HWINSTA wst = CreateWindowStation (0, 0, WINSTA_ALL_ACCESS, 0);
  SetProcessWindowStation(wst);
  AllocConsole();
  Sleep(3000);
  return 0;
}

There seems to have been quite a bit of rearchitecting in this area.
On 7 there's a process called 'conhost.exe' for every console, which I
don't think I've seen on previous Windows versions.

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Corinna Vinschen-2]

On Apr 15 22:15, Andy Koppe wrote:

> Corinna Vinschen:
> > If the above code also allocs a console window when run from a non-cygwin
> > (mingw) application, then this should be reported as a bug to Microsoft.
>
> I can confirm this one now. This little test opens a console window on
> 7, but not Vista, when compiled with 'gcc -mno-cygwin -mwindows'.
>
> int
> main(void)
> {
>   HWINSTA wst = CreateWindowStation (0, 0, WINSTA_ALL_ACCESS, 0);
>   SetProcessWindowStation(wst);
>   AllocConsole();
>   Sleep(3000);
>   return 0;
> }
>
> There seems to have been quite a bit of rearchitecting in this area.
> On 7 there's a process called 'conhost.exe' for every console, which I
> don't think I've seen on previous Windows versions.

Confirmed.  I'm going to send a bug report to MSFT.


Thanks,
Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Andy Koppe]

2009/4/16 Corinna Vinschen:

>> This little test opens a console window on
>> 7, but not Vista, when compiled with 'gcc -mno-cygwin -mwindows'.
>>
>> int
>> main(void)
>> {
>>   HWINSTA wst = CreateWindowStation (0, 0, WINSTA_ALL_ACCESS, 0);
>>   SetProcessWindowStation(wst);
>>   AllocConsole();
>>   Sleep(3000);
>>   return 0;
>> }
>>
>> There seems to have been quite a bit of rearchitecting in this area.
>> On 7 there's a process called 'conhost.exe' for every console, which I
>> don't think I've seen on previous Windows versions.
>
> Confirmed.  I'm going to send a bug report to MSFT.

Thanks! Is there a way to monitor developments on this issue?

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Corinna Vinschen-2]

On Apr 21 16:35, Andy Koppe wrote:

> 2009/4/16 Corinna Vinschen:
> >> int
> >> main(void)
> >> {
> >>   HWINSTA wst = CreateWindowStation (0, 0, WINSTA_ALL_ACCESS, 0);
> >>   SetProcessWindowStation(wst);
> >>   AllocConsole();
> >>   Sleep(3000);
> >>   return 0;
> >> }
> >>
> >> There seems to have been quite a bit of rearchitecting in this area.
> >> On 7 there's a process called 'conhost.exe' for every console, which I
> >> don't think I've seen on previous Windows versions.
> >
> > Confirmed.  I'm going to send a bug report to MSFT.
>
> Thanks! Is there a way to monitor developments on this issue?

If you have a connect account and are participating officially in the W7
testing, then yes.  Otherwise I fear this is sort of a closed group.
I only got one reply from MSFT so far.  The issue has been forwarded to
the WindowStation/Desktop group.  If I get another reply I'll keep you
informed.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Corinna Vinschen-2]

On Apr 21 18:00, Corinna Vinschen wrote:

> On Apr 21 16:35, Andy Koppe wrote:
> > 2009/4/16 Corinna Vinschen:
> > >> int
> > >> main(void)
> > >> {
> > >>   HWINSTA wst = CreateWindowStation (0, 0, WINSTA_ALL_ACCESS, 0);
> > >>   SetProcessWindowStation(wst);
> > >>   AllocConsole();
> > >>   Sleep(3000);
> > >>   return 0;
> > >> }
> > >>
> > >> There seems to have been quite a bit of rearchitecting in this area.
> > >> On 7 there's a process called 'conhost.exe' for every console, which I
> > >> don't think I've seen on previous Windows versions.
> > >
> > > Confirmed.  I'm going to send a bug report to MSFT.
> >
> > Thanks! Is there a way to monitor developments on this issue?
>
> If you have a connect account and are participating officially in the W7
> testing, then yes.  Otherwise I fear this is sort of a closed group.
> I only got one reply from MSFT so far.  The issue has been forwarded to
> the WindowStation/Desktop group.  If I get another reply I'll keep you
> informed.

Unfortunately I got the reply that this issue cannot be addressed this
time but MSFT will consider addressing the issue in a future version of
Windows.

This is really bad.  I'm still trying to convince them that a fix is
really important, but history is against me.  I'm going to try to get
at least a workaround.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Andy Koppe]

2009/5/8 Corinna Vinschen:
> Unfortunately I got the reply that this issue cannot be addressed this
> time but MSFT will consider addressing the issue in a future version of
> Windows.

Forgot to say: thanks for the update.

> This is really bad.

Yep. And the workaround with ShowWindowAsync() isn't great either.

> I'm still trying to convince them that a fix is really important, but history is against me.
> I'm going to try to get at least a workaround.

Well, good luck anyway!

Andy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

[Corinna Vinschen-2]

On May 13 19:34, Andy Koppe wrote:

> 2009/5/8 Corinna Vinschen:
> > Unfortunately I got the reply that this issue cannot be addressed this
> > time but MSFT will consider addressing the issue in a future version of
> > Windows.
>
> Forgot to say: thanks for the update.
>
> > This is really bad.
>
> Yep. And the workaround with ShowWindowAsync() isn't great either.
>
> > I'm still trying to convince them that a fix is really important, but history is against me.
> > I'm going to try to get at least a workaround.
>
> Well, good luck anyway!

Out of luck.

The issue will definitely not be fixed in RTM.  Oh well.  We will have
to find a W7 workaround for our method of creating a hidden console.  I
have asked Microsoft to provide us with a workaround but I have no
really big hope that they can or will do it.  Any suggestions?


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

[Andy Koppe]

2009/6/26 Corinna Vinschen
> The issue will definitely not be fixed in RTM.  Oh well.

:(

> We will have
> to find a W7 workaround for our method of creating a hidden console.  I
> have asked Microsoft to provide us with a workaround but I have no
> really big hope that they can or will do it.  Any suggestions?

The proper, yet probably completely impractical solution: compile
Cygwin programs for the GUI subsystem instead of the console one and
attach to the parent process' console, if any, with explicit calls at
program startup. POSIX programs don't use the Win32 console API, so
there should be no need to always have a console available.

Otherwise:

    DWORD version = GetVersion();
    version = ((version & 0xff) << 8) | ((version >> 8) & 0xff);
    if (version >= 0x0601 && AllocConsole())
      ShowWindowAsync(GetConsoleWindow(), SW_HIDE);

Still looks bad though, with "subliminal" popups, as demonstrated by
mintty on Windows 7.

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

[Corinna Vinschen-2]

On Jun 26 10:39, Andy Koppe wrote:

> 2009/6/26 Corinna Vinschen
> > The issue will definitely not be fixed in RTM.  Oh well.
>
> :(
>
> > We will have
> > to find a W7 workaround for our method of creating a hidden console.  I
> > have asked Microsoft to provide us with a workaround but I have no
> > really big hope that they can or will do it.  Any suggestions?
>
> The proper, yet probably completely impractical solution: compile
> Cygwin programs for the GUI subsystem instead of the console one and
> attach to the parent process' console, if any, with explicit calls at
> program startup. POSIX programs don't use the Win32 console API, so
> there should be no need to always have a console available.

The problem is rather that you want to be able to run certain native
applications which refuse to run if no console is allocated.  Or they
pop up a console on their own.

> Otherwise:
>
>     DWORD version = GetVersion();
>     version = ((version & 0xff) << 8) | ((version >> 8) & 0xff);
>     if (version >= 0x0601 && AllocConsole())
>       ShowWindowAsync(GetConsoleWindow(), SW_HIDE);
>
> Still looks bad though, with "subliminal" popups, as demonstrated by
> mintty on Windows 7.

And what's really bad is that the console shows up in the taskbar.

I already tried if creating another desktop will help to fix this
problem, but to no avail.  I'm still looking, but it seems to be
a dead end.


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

[Andy Koppe]

2009/6/26 Corinna Vinschen:
>> The proper, yet probably completely impractical solution: compile
>> Cygwin programs for the GUI subsystem instead of the console one and
>> attach to the parent process' console, if any, with explicit calls at
>> program startup. POSIX programs don't use the Win32 console API, so
>> there should be no need to always have a console available.
>
> The problem is rather that you want to be able to run certain native
> applications which refuse to run if no console is allocated.  Or they
> pop up a console on their own.

Good point, that would be rather an unwelcome change. Shame.

>> Otherwise:
>>
>>     DWORD version = GetVersion();
>>     version = ((version & 0xff) << 8) | ((version >> 8) & 0xff);
>>     if (version >= 0x0601 && AllocConsole())
>>       ShowWindowAsync(GetConsoleWindow(), SW_HIDE);
>>
>> Still looks bad though, with "subliminal" popups, as demonstrated by
>> mintty on Windows 7.
>
> And what's really bad is that the console shows up in the taskbar.

Forgot to say: the occurances of this could at least be reduced by
trying AttachConsole to get a hold on the parent process' console, if
any. When I attempted that in MinTTY, though, I couldn't make it work.
Did you previously mention that MS fixed bug in this area?

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

[Corinna Vinschen-2]

On Jun 26 13:03, Andy Koppe wrote:
> 2009/6/26 Corinna Vinschen:
> > And what's really bad is that the console shows up in the taskbar.
>
> Forgot to say: the occurances of this could at least be reduced by
> trying AttachConsole to get a hold on the parent process' console, if
> any. When I attempted that in MinTTY, though, I couldn't make it work.

Yes, I thought of trying AttachConsole first.  It's a band-aid since
it will of course not work if there's just no parent console, as you
observed in MinTTY.

> Did you previously mention that MS fixed bug in this area?

Sorry, I don't understand the question.  I don't think I ever mentioned
anything related to a MS bugfix in terms of AttachConsole.


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

[Andy Koppe]

2009/6/26 Corinna Vinschen:
>> Forgot to say: the occurances of this could at least be reduced by
>> trying AttachConsole to get a hold on the parent process' console, if
>> any. When I attempted that in MinTTY, though, I couldn't make it work.
>
> Yes, I thought of trying AttachConsole first.  It's a band-aid since
> it will of course not work if there's just no parent console

That can be dealt with, because AttachConsole reports back whether it
did manage to attach, so if it doesn't, one can then call AllocConsole
and ShowWindowAsync.

But on 64-bit Windows 7 there were some bizarre problems, where it
just wouldn't attach or it would completely block the parent's
console. See http://code.google.com/p/mintty/issues/detail?id=83

>> Did you previously mention that MS fixed bug in this area?
>
> Sorry, I don't understand the question.  I don't think I ever mentioned
> anything related to a MS bugfix in terms of AttachConsole.

Ah, seems I jumped to conclusions from this, although it does sound
like it might address the problems above:

2009/5/16 Corinna Vinschen:
"That's not a workaround for the problem with consoles popping up, but a
workaround for a W7 x64 specific problem.  There's a bug in the W7 x64
console code (which appears to be mostly rewritten in W7 anyway) which
breaks DLL initialization in child processes which have no copy of the
original console handles from console startup anymore.  This bug has been
reported upstream and is marked as being resolved, which hopefully
means it will be fixed in the final W7 release."

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

[Corinna Vinschen-2]

On Jun 26 13:41, Andy Koppe wrote:

> 2009/6/26 Corinna Vinschen:
> >> Forgot to say: the occurances of this could at least be reduced by
> >> trying AttachConsole to get a hold on the parent process' console, if
> >> any. When I attempted that in MinTTY, though, I couldn't make it work.
> >
> > Yes, I thought of trying AttachConsole first.  It's a band-aid since
> > it will of course not work if there's just no parent console
>
> That can be dealt with, because AttachConsole reports back whether it
> did manage to attach, so if it doesn't, one can then call AllocConsole
> and ShowWindowAsync.

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.

> But on 64-bit Windows 7 there were some bizarre problems, where it
> just wouldn't attach or it would completely block the parent's
> console. See http://code.google.com/p/mintty/issues/detail?id=83

I assume this...

> >> Did you previously mention that MS fixed bug in this area?
> >
> > Sorry, I don't understand the question.  I don't think I ever mentioned
> > anything related to a MS bugfix in terms of AttachConsole.
>
> Ah, seems I jumped to conclusions from this, although it does sound
> like it might address the problems above:
>
> 2009/5/16 Corinna Vinschen:
> "That's not a workaround for the problem with consoles popping up, but a
> workaround for a W7 x64 specific problem.  There's a bug in the W7 x64
> console code (which appears to be mostly rewritten in W7 anyway) which
> breaks DLL initialization in child processes which have no copy of the
> original console handles from console startup anymore.  This bug has been
> reported upstream and is marked as being resolved, which hopefully
> means it will be fixed in the final W7 release."

...and that problem are related.  It's not the same problem as the
AllocConsole shows up on the wrong WindowStation problem we're talking
about in this thread, though.  The problem with the console handles
in 64 bit Windows is fixed in the latest builds.


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

[Julio Costa]

Hi,

On Fri, Jun 26, 2009 at 14:36, Corinna Vinschen wrote:

> On Jun 26 13:41, Andy Koppe wrote:
>> 2009/6/26 Corinna Vinschen:
>> >> Forgot to say: the occurances of this could at least be reduced by
>> >> trying AttachConsole to get a hold on the parent process' console, if
>> >> any. When I attempted that in MinTTY, though, I couldn't make it work.
>> >
>> > Yes, I thought of trying AttachConsole first.  It's a band-aid since
>> > it will of course not work if there's just no parent console
>>
>> That can be dealt with, because AttachConsole reports back whether it
>> did manage to attach, so if it doesn't, one can then call AllocConsole
>> and ShowWindowAsync.
>
> 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?

(crossing fingers)
___________
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

[Corinna Vinschen-2]

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

[Christopher Faylor-8]

On Fri, Jun 26, 2009 at 04:52:13PM +0200, Corinna Vinschen wrote:

>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.

FWIW, I can add another failure point to the mix.  I spent all day one
Saturday trying to come up with a workaround.  It looks like this is one
of the many cases where clever Microsoft programmers have worked around
the clock closing up any loopholes which would allow useful behavior.

Hmm.  As I was typing this I had another idea which I don't think I
tried.  I'll look into that this weekend.

cgf

--
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