popup consoles on Windows 7

[Corinna Vinschen-2]

On Jun 26 11:03, Christopher Faylor wrote:

> On Fri, Jun 26, 2009 at 04:52:13PM +0200, Corinna Vinschen wrote:
> >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.

I have a local band-aid using AttachConsole and ShowWindowAsync.  If
your idea doesn't work, we could at least use this pathetic workaround.

Index: autoload.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/autoload.cc,v
retrieving revision 1.160
diff -u -p -r1.160 autoload.cc
--- autoload.cc 9 Jun 2009 09:45:29 -0000 1.160
+++ autoload.cc 26 Jun 2009 15:13:48 -0000
@@ -364,6 +364,7 @@ LoadDLLfunc (SendMessageA, 16, user32)
 LoadDLLfunc (SetClipboardData, 8, user32)
 LoadDLLfunc (SetThreadDesktop, 4, user32)
 LoadDLLfunc (SetProcessWindowStation, 4, user32)
+LoadDLLfuncEx (ShowWindowAsync, 8, user32, 1)
 
 LoadDLLfunc (accept, 12, ws2_32)
 LoadDLLfunc (bind, 12, ws2_32)
@@ -408,6 +409,7 @@ LoadDLLfuncEx2 (SendARP, 16, iphlpapi, 1
 
 LoadDLLfunc (CoTaskMemFree, 4, ole32)
 
+LoadDLLfuncEx (AttachConsole, 0, kernel32, 1)
 LoadDLLfuncEx (FindFirstVolumeA, 8, kernel32, 1)
 LoadDLLfuncEx (FindNextVolumeA, 12, kernel32, 1)
 LoadDLLfuncEx (FindVolumeClose, 4, kernel32, 1)
Index: fhandler_console.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_console.cc,v
retrieving revision 1.195
diff -u -p -r1.195 fhandler_console.cc
--- fhandler_console.cc 4 Jun 2009 14:59:47 -0000 1.195
+++ fhandler_console.cc 26 Jun 2009 15:13:48 -0000
@@ -1977,9 +1977,20 @@ fhandler_console::need_invisible ()
   debug_printf ("window station is not visible");
   invisible_console = true;
  }
-      else
+      /* BandAid for Windows 7.  AllocConsole is broken on W7 in that it
+         doesn't allocate the console in the hidden, active WindowStation,
+ but instead on the WindowStation on which the application has
+ originally been started on.  This effectively disallows to create
+ a hidden console.
+ So what we do now is this.  First we try to attach to an existing
+ console window of the parent process.  If that doesn't work, we
+ skip generating a hidden WIndowStation entirely.  After creating
+ the new console, we hide it.  Unfortunately it's still visible in
+ the taskbar.  Hopefully this will be fixed in SP1... */
+      else if (!wincap.has_broken_alloc_console () || !AttachConsole (-1))
  {
-  if (myself->ctty != TTY_CONSOLE)
+  if (myself->ctty != TTY_CONSOLE
+      && !wincap.has_broken_alloc_console ())
     {
       h = CreateWindowStationW (NULL, 0, WINSTA_ACCESS, NULL);
       termios_printf ("%p = CreateWindowStation(NULL), %E", h);
@@ -1991,6 +2002,8 @@ fhandler_console::need_invisible ()
     }
   b = AllocConsole (); /* will cause flashing if CreateWindowStation
    failed */
+  if (wincap.has_broken_alloc_console ())
+    ShowWindowAsync (GetConsoleWindow (), SW_HIDE);
   debug_printf ("h %p, horig %p, flags %p", h, horig, oi.dwFlags);
   if (horig && h && h != horig && SetProcessWindowStation (horig))
     CloseWindowStation (h);


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

[Corinna Vinschen-2]

On Jun 26 17:14, Corinna Vinschen wrote:

> On Jun 26 11:03, Christopher Faylor wrote:
> > On Fri, Jun 26, 2009 at 04:52:13PM +0200, Corinna Vinschen wrote:
> > >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.
>
> I have a local band-aid using AttachConsole and ShowWindowAsync.  If
> your idea doesn't work, we could at least use this pathetic workaround.

Apart from that, I had no luck toying around with creating another
desktop either.  And maybe, just maybe, Microsoft actually provides
some workaround.


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:

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

Agreed, a proper workaround is still needed.

> You have still cluttered
> your desktop, or rather, your taskbar with console windows.

I don't see that with MinTTY with ShowWindowAsync(GetConsoleWindow(),
SW_HIDE), at least on Windows 7 RC 64-bit. There's a conhost.exe for
each session in Task Manager, but no console icon in the taskbar.

> The problem with the console handles
> in 64 bit Windows is fixed in the latest builds.

Thanks, I better give that a go. Using AttachConsole would at least
get rid of the popups when invoking from an existing Cygwin session.

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

[Andy Koppe]

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

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

[Corinna Vinschen-2]

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

Yeah, that could be an option as a per-session workaround if there's
no other way to accomplish it.


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]

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

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

[Andy Koppe]

2009/7/2 Julio Costa <costaju@...>:

> HKCU\Console\<argv[0]>\WindowPosition = 0x80008000

Good idea!

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

From earlier in the thread:

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

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

So be it, I'd be tempted to say, and point people that do insist on
running native console at /bin/run. But then I haven't been at the
sharp end of a barrage of compatibility complaints.

Actually, couldn't spawn_guts() tell whether it's about to execute a
console program, and only allocate a hidden console in that case?

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

[Christopher Faylor-8]

On Thu, Jul 02, 2009 at 05:41:18PM +0100, Julio Costa wrote:
>HKCU\Console\<argv[0]>\WindowPosition = 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 :(

You haven't programmed many multi-threaded, multi-process aware
applications if you think that setting a registry key is going to work
right.

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

Yeah, what were we thinking?  We went out of our way to set up a hidden
console, expending considerable effort to do so when they really weren't
needed.

How about if you think within the box and do a google search rather than
suggesting that we didn't know what we were doing?

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

[Julio Costa]

On Thu, Jul 2, 2009 at 18:44, Christopher Faylor wrote:

> On Thu, Jul 02, 2009 at 05:41:18PM +0100, Julio Costa wrote:
>>HKCU\Console\<argv[0]>\WindowPosition = 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 :(
>
> You haven't programmed many multi-threaded, multi-process aware
> applications if you think that setting a registry key is going to work
> right.
>

No, I haven't - Damn, I've been discovered! :)
But now that you've mentioned it, I see your point.
I was just reporting a result from an observational experiment.
I even didn't done that with real code.
But the usefulness of this registry hack was limited, as I referred.

Oh well, back to the workbench :)

>>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...
>
> Yeah, what were we thinking?  We went out of our way to set up a hidden
> console, expending considerable effort to do so when they really weren't
> needed.
>

Did I wrote something like that? Well, YOU did.

> How about if you think within the box and do a google search rather than
> suggesting that we didn't know what we were doing?
>

Nice way to help others to help you.
Even if they are waay below in the "mighty coders scale", I don't
think that's a reason to be rude. Not that it is a novelty, I've been
following this mailing list for almost a year now.

You know, you shouldn't take everything that is asked in this list as
a criticism.
I've probably didn't asked in the best way either, but you should have
a much more flexible "filter" because not everyone on this list is
English native. So, maybe there is a little language barrier that
distorted the meaning I was trying to give the question.

I just asked to clarify was a need (da console) expressed in various
places, either in cygwin, in mintty, and probably many others, but
found no explanation on this need, beside what was already said in
this very thread. That only tell me that "it is needed".

Let me rephrase that in three questions:
"What happens if we launch commands without a console created?"
"What are the type of programs that really need that console?"
"Is it possible to identify them prior to launch them?"

--
___________
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 Jul  3 10:18, Julio Costa wrote:
> Let me rephrase that in three questions:
> "What happens if we launch commands without a console created?"

That's actually the same question as the next one, isn't it?

> "What are the type of programs that really need that console?"

Cygwin processes don't worry about the console.  They use what they
get as file descriptors and live with that.

Native processes exist in two variations.  Some of them just use
the stdio handles like Cygwin processes.  Some of them require to
be run in a console becasue they use Console I/O functions directly.
These applications will fail miserably in a Cygwin environment not
attached to a console.  Unfortunately there are quite a lot of them
used for Windows system administration.

At least that's as far as I rememeber this whole issue.  I may have
forgotten some aspect, but I'm fairly sure that we can drop the
hidden console business as far as only Cygwin processes are affected.

> "Is it possible to identify them prior to launch them?"

Cygwin checks for a Cygwin application prior to execv it.
Not a Cygwin application == may need a console.

I have some testing code which only tries to create an invisible console
if the application to execv is not a Cygwin application.  It seems to
work nicely.  I'm just not sure if it's really *that* simple...


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/7/3 Corinna Vinschen:

> I have some testing code which only tries to create an invisible console
> if the application to execv is not a Cygwin application.  It seems to
> work nicely.  I'm just not sure if it's really *that* simple...

Me neither.

Given that Cygwin applications themselves are usually marked as
console applications, shouldn't you therefore get a console popping up
(unless of course the invoking process already has a console)?

Or does Windows delay console allocation until the app actually tries to use it?

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

[Julio Costa]

On Fri, Jul 3, 2009 at 11:44, Corinna Vinschen wrote:
> On Jul  3 10:18, Julio Costa wrote:
>> Let me rephrase that in three questions:
>> "What happens if we launch commands without a console created?"
>
> That's actually the same question as the next one, isn't it?
>

It is now, that I seen the answer to the next one :)

>> "What are the type of programs that really need that console?"
>
> Cygwin processes don't worry about the console.  They use what they
> get as file descriptors and live with that.
>
> Native processes exist in two variations.  Some of them just use
> the stdio handles like Cygwin processes.  Some of them require to
> be run in a console becasue they use Console I/O functions directly.

Ahhh! That's the core problem... I didn't realize that there could be
applications wanting to do that... Duh!

> These applications will fail miserably in a Cygwin environment not
> attached to a console.  Unfortunately there are quite a lot of them
> used for Windows system administration.

Rats!

>
> At least that's as far as I rememeber this whole issue.  I may have
> forgotten some aspect, but I'm fairly sure that we can drop the
> hidden console business as far as only Cygwin processes are affected.
>
>> "Is it possible to identify them prior to launch them?"
>
> Cygwin checks for a Cygwin application prior to execv it.
> Not a Cygwin application == may need a console.
>
> I have some testing code which only tries to create an invisible console
> if the application to execv is not a Cygwin application.  It seems to
> work nicely.  I'm just not sure if it's really *that* simple...
>

Thanks for the clarification!

Besides that, is it possible to distinguish if, being *not* a Cygwin
application, it would *need* direct console IO?
If I understand it correctly, knowing if an application is for
subsystem windows or console does *not* give us a foolproof answer to
if it would need the direct console IO.
That's bad. This identification could be very handy to only try
"risky" and "costly" things only when really needed...

As for the action itself, to hide the console, I've been looking in
the MS documentation and I saw some potential insteresting info about
the STARTUPINFO passed to the CreateProcess:
1) Use STARTF_USEPOSITION, with dwX = dwY = 0x8000 (similar to the
registry hack?);
2) OR, use STARTF_USESHOWWINDOW, with wShowWindow = SW_HIDE;
3) OR (far fetched) use lpDesktop with something 'WinStaHIDE\Default'

I've not tested it (I've no access to a proper build system to do
this, neither to a Win7).
Probable drawbacks:
1) I'm guessing that NO window will show after even the created by
child processess...
Is it possible to change the dwFlags field on the child process, after
it starts? That would solve it;
2) ditto;
3) It force us to do a SetProcessWindowStation and SetThreadDesktop to
something that must be stored and passed to the child, after the
AllocConsole is done ; AND, there is also the probability of Win7 just
plain ignores the lpDesktop setting.

Well, this is all I can see for now. Hope it helps somehow.

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

[Christopher Faylor-8]

On Fri, Jul 03, 2009 at 12:44:23PM +0200, Corinna Vinschen wrote:
>I have some testing code which only tries to create an invisible console
>if the application to execv is not a Cygwin application.  It seems to
>work nicely.  I'm just not sure if it's really *that* simple...

I actually had some plans (which I have talked about here from time to
time) for the invisible console for cygwin apps so I am not ready to
admit defeat for this method yet.

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

[Christopher Faylor-8]

On Fri, Jul 03, 2009 at 10:18:45AM +0100, Julio Costa wrote:
>You know, you shouldn't take everything that is asked in this list as
>a criticism.

I didn't take it as criticism but, you're right, my reply was overly
harsh.  I apologize for the tone.

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

[Christopher Faylor-8]

On Fri, Jul 03, 2009 at 11:02:12AM -0400, Christopher Faylor wrote:
>On Fri, Jul 03, 2009 at 12:44:23PM +0200, Corinna Vinschen wrote:
>>I have some testing code which only tries to create an invisible console
>>if the application to execv is not a Cygwin application.  It seems to
>>work nicely.  I'm just not sure if it's really *that* simple...
>
>I actually had some plans (which I have talked about here from time to
>time) for the invisible console for cygwin apps so I am not ready to
>admit defeat for this method yet.

I think I have a workaround for this which avoids the flashing console
but I won't have time to debug it thoroughly until I return from a July
4th party later today.

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

[Christopher Faylor-8]

On Sat, Jul 04, 2009 at 12:14:31PM -0400, Christopher Faylor wrote:

>On Fri, Jul 03, 2009 at 11:02:12AM -0400, Christopher Faylor wrote:
>>On Fri, Jul 03, 2009 at 12:44:23PM +0200, Corinna Vinschen wrote:
>>>I have some testing code which only tries to create an invisible console
>>>if the application to execv is not a Cygwin application.  It seems to
>>>work nicely.  I'm just not sure if it's really *that* simple...
>>
>>I actually had some plans (which I have talked about here from time to
>>time) for the invisible console for cygwin apps so I am not ready to
>>admit defeat for this method yet.
>
>I think I have a workaround for this which avoids the flashing console...

I've checked in a workaround for the problem:

http://cygwin.com/ml/cygwin-cvs/2009-q3/msg00010.html

I checked this by removing the Windows 7 code from mintty and rebuilding
it.  With the currently released version of Cygwin 1.7.0-50 this causes
a windows console to be displayed on the screen along with the expected
mintty window.  With the 20090703 snapshot, which includes Corinna's
workaround, I got a flashing console.  With the code in CVS I got the
expected behavior of no console flash.

As I type this I realize that I didn't really confirm that the new
invisible console code has the desired effect in mintty.  It is supposed
to make some (native?) apps work better.  I thought that one of the apps
was the "net" command and I don't have any problems running it but does
anyone remember a specific program (maybe even a cygwin program?) which
required the existence of a console to work correctly?  If so, I'd like
to add it to the comments in the source code and verify that it still
works.

If you want to try a snapshot, make sure that you grab the new helper
app "cygwin-console-helper.exe" and put it in /bin.  Without this,
you'll still see the same flashes as the 20090703 snapshot.  The new
.exe file is in here:

http://cygwin.com/snapshots/cygwin-inst-20090704.tar.bz2

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

[Julio Costa]

On Sun, Jul 5, 2009 at 01:11, Christopher Faylor wrote:

> On Sat, Jul 04, 2009 at 12:14:31PM -0400, Christopher Faylor wrote:
>>On Fri, Jul 03, 2009 at 11:02:12AM -0400, Christopher Faylor wrote:
>>>On Fri, Jul 03, 2009 at 12:44:23PM +0200, Corinna Vinschen wrote:
>>>>I have some testing code which only tries to create an invisible console
>>>>if the application to execv is not a Cygwin application.  It seems to
>>>>work nicely.  I'm just not sure if it's really *that* simple...
>>>
>>>I actually had some plans (which I have talked about here from time to
>>>time) for the invisible console for cygwin apps so I am not ready to
>>>admit defeat for this method yet.
>>
>>I think I have a workaround for this which avoids the flashing console...
>
> I've checked in a workaround for the problem:
>
> http://cygwin.com/ml/cygwin-cvs/2009-q3/msg00010.html
>

cgf rules!!

> I checked this by removing the Windows 7 code from mintty and rebuilding
> it.  With the currently released version of Cygwin 1.7.0-50 this causes
> a windows console to be displayed on the screen along with the expected
> mintty window.  With the 20090703 snapshot, which includes Corinna's
> workaround, I got a flashing console.  With the code in CVS I got the
> expected behavior of no console flash.
>

Cool!
But not so cool as if M$FT would correct their bugs :( booo!

> As I type this I realize that I didn't really confirm that the new
> invisible console code has the desired effect in mintty.  It is supposed
> to make some (native?) apps work better.  I thought that one of the apps
> was the "net" command and I don't have any problems running it but does
> anyone remember a specific program (maybe even a cygwin program?) which
> required the existence of a console to work correctly?  If so, I'd like
> to add it to the comments in the source code and verify that it still
> works.
>

Remember old DOS days? EDIT.
It even resizes my cmd window, so I bet it *must* have a strong reason
to want a console.

> If you want to try a snapshot, make sure that you grab the new helper
> app "cygwin-console-helper.exe" and put it in /bin.  Without this,
> you'll still see the same flashes as the 20090703 snapshot.  The new
> .exe file is in here:
>
> http://cygwin.com/snapshots/cygwin-inst-20090704.tar.bz2
>

Thanks for looking (hard) into this.
I've no Win7 right now, but I already downloaded a copy, just because
of these matters. I'll try it during next week.

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

[Christopher Faylor-8]

On Sun, Jul 05, 2009 at 01:34:16AM +0100, Julio Costa wrote:

>On Sun, Jul 5, 2009 at 01:11, Christopher Faylor wrote:
>> I checked this by removing the Windows 7 code from mintty and rebuilding
>> it. ??With the currently released version of Cygwin 1.7.0-50 this causes
>> a windows console to be displayed on the screen along with the expected
>> mintty window. ??With the 20090703 snapshot, which includes Corinna's
>> workaround, I got a flashing console. ??With the code in CVS I got the
>> expected behavior of no console flash.
>>
>
>Cool!
>But not so cool as if M$FT would correct their bugs :( booo!

Yeah, that's for sure.  I think I have a vague inkling as to why they
didn't just fix this problem.  I'll bet it has something to do with the
new conhost.exe program not understanding the windows station of the
process which started the console.  <broken record>I really can't
believe that they would release Windows 7 in such a broken state
though.</broken record>

>> As I type this I realize that I didn't really confirm that the new
>> invisible console code has the desired effect in mintty. ??It is supposed
>> to make some (native?) apps work better. ??I thought that one of the apps
>> was the "net" command and I don't have any problems running it but does
>> anyone remember a specific program (maybe even a cygwin program?) which
>> required the existence of a console to work correctly? ??If so, I'd like
>> to add it to the comments in the source code and verify that it still
>> works.
>>
>
>Remember old DOS days? EDIT.
>It even resizes my cmd window, so I bet it *must* have a strong reason
>to want a console.

I think that's probably one of those programs that won't work at all in
a Cygwin pty.  The invisible console code just helped a certain class of
application.  Apps which want to perform console operations on their
standard input and standard output still are not going to work any
better than they ever did.

I keep saying that I want to fix this and I recently found some public
domain code which purports to allow using consoles as "pipes".  I hope
I'll have time to look into adding this to Cygwin after 1.7 is released.

>> If you want to try a snapshot, make sure that you grab the new helper
>> app "cygwin-console-helper.exe" and put it in /bin. ??Without this,
>> you'll still see the same flashes as the 20090703 snapshot. ??The new
>> .exe file is in here:
>>
>> http://cygwin.com/snapshots/cygwin-inst-20090704.tar.bz2
>>
>
>Thanks for looking (hard) into this.

You have no idea how much time I wasted on this.

>I've no Win7 right now, but I already downloaded a copy, just because
>of these matters.  I'll try it during next week.

I've been running a copy of Windows 7 in Sun's virtualbox.  It really is
cool.  I have a vmware license but, lately, I've been using virtualbox
exclusively.

I know this is slightly off-topic but I can recommend this product for
virtually hosting Windows/Cygwin.  Personally, I really only want XP on
my hardware.  Everything else I run is in VirtualBox.  In fact, last
week, I copied my old NT4 partition from hardware to a virtualbox disk
and it booted up with minimal fuss.

http://www.virtualbox.org/

(Now I just have to copy the apparently defunct Windows 2000 partition
to virtualbox too)

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

[Matt Wozniski-3]

On Sat, Jul 4, 2009 at 8:51 PM, Christopher Faylor wrote:
> I've been running a copy of Windows 7 in Sun's virtualbox.  It really is
> cool.  I have a vmware license but, lately, I've been using virtualbox
> exclusively.

Hopefully not too OT, but an emphatic +1 for VirtualBox.  I rarely
manage to contribute anything terribly useful here, but whenever I do
it's only after testing with cygwin in a VirtualBox VM these days.

~Matt

--
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/7/5 Christopher Faylor:

> I've checked in a workaround for the problem:
>
> http://cygwin.com/ml/cygwin-cvs/2009-q3/msg00010.html
>
> I checked this by removing the Windows 7 code from mintty and rebuilding
> it.  With the currently released version of Cygwin 1.7.0-50 this causes
> a windows console to be displayed on the screen along with the expected
> mintty window.  With the 20090703 snapshot, which includes Corinna's
> workaround, I got a flashing console.  With the code in CVS I got the
> expected behavior of no console flash.

Works for me on Windows 7 RC 64-bit. Thanks you very very much, looks
so much better without those subliminal consoles. And Xwin is fine
too. What was the big idea?

It doesn't appear to suffer from MinTTY issue 83 either. ("MinTTY
hangs the console/shell it launched from on Win7-64",
http://code.google.com/p/mintty/issues/detail?id=83). That issue was
why I'd removed AttachConsole calls from MinTTY, but perhaps MS had
actually fixed whatever caused it in the release candidate.

Now what's the right way to check for this workaround being present in
the Cygwin DLL, so that MinTTY can skip its workaround depending on
that? Should I parse version string from /proc/version? (I intend to
throw out MinTTY's workaround altogether when going 1.7-only, but for
the moment it needs to stay.)


> As I type this I realize that I didn't really confirm that the new
> invisible console code has the desired effect in mintty.  It is supposed
> to make some (native?) apps work better.

No, its main purpose is to stop console subsystem applications from
popping up their own console. This includes most Cygwin programs
(which I think is wrong).


> I thought that one of the apps
> was the "net" command and I don't have any problems running it but does
> anyone remember a specific program (maybe even a cygwin program?) which
> required the existence of a console to work correctly?

I think this concerns apps that directly use the low-level console
API, but I don't know of any specific examples either. I've seen 'net'
mentioned too, so perhaps it does invoke a low-level API function or
two, but without significantly depending on their effects.


> If you want to try a snapshot, make sure that you grab the new helper
> app "cygwin-console-helper.exe" and put it in /bin.  Without this,
> you'll still see the same flashes as the 20090703 snapshot.

I see the code for invoking it, but I don't fully understand it: how
come the helper process doesn't show up in task manager (which is
great, btw)?

A very minor issue in fhandler_console.cc: one of the comments says
"workstation" when it means "window station".


> I keep saying that I want to fix this and I recently found some public
> domain code which purports to allow using consoles as "pipes".  I hope
> I'll have time to look into adding this to Cygwin after 1.7 is released.

Oh, interesting, could you post a link to it?

Thanks again,
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