Windows 7 RC1 and Cygwin 1.7

[Jim Reisert AD1C]

I have installed Windows 7 RC1 (64-bit) as well as Cygwin 1.7,
including the Xorg stuff in the Cygwin setup-1.7.exe file

I can start the X server OK, as well as xterm and xemacs.

When I start an xterm by right-clicking on the X server icon in the
system tray, in addition to the Xterm windows, I also get what appears
to be two empty DOS windows - one with xwin.exe in the window title,
one with xterm.exe in the window title.  When I close the xterm, those
two DOS windows also disappear.

Can anyone speculate why this is happening?

The system is running a clean install of all this new stuff.

Thanks - Jim

--
Jim Reisert AD1C/Ø, <jjreisert@...>, http://www.ad1c.us

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

[X23G8c]

> From: cygwin-xfree-owner@...
> [mailto:cygwin-xfree-owner@...] On Behalf Of Jim Reisert AD1C
> Sent: Friday, May 15, 2009 1:13 PM

> I have installed Windows 7 RC1 (64-bit) as well as Cygwin 1.7,
> including the Xorg stuff in the Cygwin setup-1.7.exe file
>
> I can start the X server OK, as well as xterm and xemacs.
>
> When I start an xterm by right-clicking on the X server icon in the
> system tray, in addition to the Xterm windows, I also get what appears
> to be two empty DOS windows - one with xwin.exe in the window title,
> one with xterm.exe in the window title.  When I close the xterm, those
> two DOS windows also disappear.
>
> Can anyone speculate why this is happening?

        Speculate?  Heck, yeah!

        1)  Microsoft has decided it doesn't like Cygwin.  Those terminal windows are waiting for you to walk away so they can eat the xterms.

        2)  Space aliens are messing with you.  They want to know if you have a juicy brain before they decide whether to eat it.

        3)  Housing prices will continue to rise at 20% per annum.

        Huh?!  You want *sane* speculation?  Are you sure that's not an oxymoron?  How about:

        1)  The interface for detaching a program from its console window has changed slightly in Windows 7.  A slight code change will be needed.  In the meantime the console windows are harmless - setting the shortcut to run minimized should keep them off the screen if still in the program bar.


        HTH,

Mike

P.S.  That was speculation.  Hopefully someone will have a real answer soon.

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

[Christopher Faylor-8]

On Fri, May 15, 2009 at 01:22:23PM -0700, Mike Ayers wrote:
>P.S.  That was speculation.  Hopefully someone will have a real answer
>soon.

This was already discussed in the main cygwin list.  There is a
workaround in the latest version of Cygwin 1.7.x.

http://cygwin.com/ml/cygwin/2009-05/msg00477.html

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

[Corinna Vinschen-2]

On May 15 23:18, Christopher Faylor wrote:
> On Fri, May 15, 2009 at 01:22:23PM -0700, Mike Ayers wrote:
> >P.S.  That was speculation.  Hopefully someone will have a real answer
> >soon.
>
> This was already discussed in the main cygwin list.  There is a
> workaround in the latest version of Cygwin 1.7.x.
>
> http://cygwin.com/ml/cygwin/2009-05/msg00477.html

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.

As for the console windows popping up, thats a generic bug in the new
console code in W7, affecting 32 and 64 bit versions.  For some reason
the AllocConsole call does not honor the fact that the application
switched to another active WindowStation.  Thus, console windows which
are meant to be hidden in another, hidden WindowStation, are wrongly
created on the desktop of the original, visible WindowStation.

I reported this bug upstream as well, but unfortunately I got the reply
that this bug won't be fixed in this Windows release.  I'm still trying
to convince Microsoft that this is a serious problem, though.


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://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

[Jim Reisert AD1C]

The "two empty DOS windows" are conhost.exe sessions, according to Task Manager.

- Jim

On Fri, May 15, 2009 at 2:13 PM, Jim Reisert AD1C
<jjreisert@...> wrote:

> I have installed Windows 7 RC1 (64-bit) as well as Cygwin 1.7,
> including the Xorg stuff in the Cygwin setup-1.7.exe file
>
> I can start the X server OK, as well as xterm and xemacs.
>
> When I start an xterm by right-clicking on the X server icon in the
> system tray, in addition to the Xterm windows, I also get what appears
> to be two empty DOS windows - one with xwin.exe in the window title,
> one with xterm.exe in the window title.  When I close the xterm, those
> two DOS windows also disappear.
>
> Can anyone speculate why this is happening?
>
> The system is running a clean install of all this new stuff.

--
Jim Reisert AD1C/Ø, <jjreisert@...>, http://www.ad1c.us

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

[Ben Voigt-2]

On Sat, May 16, 2009 at 4:41 AM, Corinna Vinschen
<corinna-cygwin@...> wrote:

> On May 15 23:18, Christopher Faylor wrote:
>> On Fri, May 15, 2009 at 01:22:23PM -0700, Mike Ayers wrote:
>> >P.S.  That was speculation.  Hopefully someone will have a real answer
>> >soon.
>>
>> This was already discussed in the main cygwin list.  There is a
>> workaround in the latest version of Cygwin 1.7.x.
>>
>> http://cygwin.com/ml/cygwin/2009-05/msg00477.html
>
> 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.
>
> As for the console windows popping up, thats a generic bug in the new
> console code in W7, affecting 32 and 64 bit versions.  For some reason
> the AllocConsole call does not honor the fact that the application
> switched to another active WindowStation.  Thus, console windows which
> are meant to be hidden in another, hidden WindowStation, are wrongly
> created on the desktop of the original, visible WindowStation.
>
> I reported this bug upstream as well, but unfortunately I got the reply
> that this bug won't be fixed in this Windows release.  I'm still trying
> to convince Microsoft that this is a serious problem, though.

Corinna,

Do you have a link to a bug report on Connect?  I'll upvote it.

And should I download the latest release in order to validate this, or
are there testing builds?  I haven't installed Cygwin on my 64-bit
Win7RC box yet but I need to, can't use any computer long without an
ssh client.

Are there any other bugs you'd like validated and upvoted?  I'm not
exactly sure how to reproduce that issue you found with the cost to
access directories on NTFS increasing exponentially with nesting
level.... well repro might not be hard but pinpointing MS-provided
code as the problem vs antivirus or just about anything else might not
be the easiest thing.  This new AllocConsole window station thing
seems a lot more straightforward.

After all, what's MVP status good for if not telling 'em they broke
valuable cygwin stuff.

Ben Voigt
(http://mvp.support.microsoft.com/profile/Voigt)

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

[Ravenik]

Corinna Vinschen-2 wrote:

As for the console windows popping up, thats a generic bug in the new
console code in W7, affecting 32 and 64 bit versions.  For some reason
the AllocConsole call does not honor the fact that the application
switched to another active WindowStation.  Thus, console windows which
are meant to be hidden in another, hidden WindowStation, are wrongly
created on the desktop of the original, visible WindowStation.

I reported this bug upstream as well, but unfortunately I got the reply
that this bug won't be fixed in this Windows release.  I'm still trying
to convince Microsoft that this is a serious problem, though.

If there is any possibility for us to support this request to Microsoft, then let us now. I  use Cygwin  1.5.25-15 and have the same problem with "the console windows popping up" in W7 RC. Really annoying. Hope they will correct it before final release. I look forward to hearing about this problem solved or a workaround. Meanwhile I consider reverting to Vista which doesn't have this bug.

[Ravenik]

I have found this option to send feedback to MS from W7 RC x64:
C:\Windows\System32\rundll32.exe FeedbackTool.dll,ShowWizard
Maybe we should send infos about a bug, however I am not sure if they care, and don't know what sort of "fedback on" to choose.

[Corinna Vinschen-2]

Hi Ben,

sorry for the late response.  That's what vacation does to you :}

On May 19 21:04, richardvoigt@... wrote:

> On Sat, May 16, 2009 at 4:41 AM, Corinna Vinschen
> > As for the console windows popping up, thats a generic bug in the new
> > console code in W7, affecting 32 and 64 bit versions.  For some reason
> > the AllocConsole call does not honor the fact that the application
> > switched to another active WindowStation.  Thus, console windows which
> > are meant to be hidden in another, hidden WindowStation, are wrongly
> > created on the desktop of the original, visible WindowStation.
> >
> > I reported this bug upstream as well, but unfortunately I got the reply
> > that this bug won't be fixed in this Windows release.  I'm still trying
> > to convince Microsoft that this is a serious problem, though.
>
> Corinna,
>
> Do you have a link to a bug report on Connect?  I'll upvote it.

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=443006&SiteID=647

I don't know if upvoting will help, but it's worth a try, I guess.

> And should I download the latest release in order to validate this, or
> are there testing builds?  I haven't installed Cygwin on my 64-bit
> Win7RC box yet but I need to, can't use any computer long without an
> ssh client.

The problem is independent of any Cygwin release and actually independent
of Cygwin at all.  The above Connect issue even contains a bare Win32
testcase in source code.

> Are there any other bugs you'd like validated and upvoted?  I'm not

Well, there's this issue:
https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=445558&SiteID=647
The reply I got indicates that it's not yet clear if it will get a fix,
though it's easy to reproduce.  I don't think it's *very* critical, but
I don't like the idea that a process tree can lose handles when the
close-on-exec flag is set for console file descriptors.

My other open issues are:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=447597&SiteID=647
Marked as resolved but I can still reproduce in the latest build.

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=447443&SiteID=647
Has been fixed but introduces a new bug which I'm going to report today
or tomorrow.  A file not found on an NFS share now reports the wrong
error code STATUS_OBJECT_PATH_NOT_FOUND instead of STATUS_NO_SUCH_FILE
in the latest build.  That's bad for Cygwin.  But I still have to verify
on a 32 bit system before I file the issue.

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=442994&SiteID=647
is still heavily worked on.

> exactly sure how to reproduce that issue you found with the cost to
> access directories on NTFS increasing exponentially with nesting
> level.... well repro might not be hard but pinpointing MS-provided

This is an old issue I reported as one of my MSDN cases.  Given that it
only occurs on NT kernels of the 5.x series and has been fixed in the
6.0 kernel, there won't be a fix for that.  I already pulled it through
all instances.

> After all, what's MVP status good for if not telling 'em they broke
> valuable cygwin stuff.

Right :)


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://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

[Yaakov (Cygwin/X)]

On 15/05/2009 15:13, Jim Reisert AD1C wrote:
> I have installed Windows 7 RC1 (64-bit) as well as Cygwin 1.7,
> including the Xorg stuff in the Cygwin setup-1.7.exe file

Same here.  I have also noticed the following issues:

1) In multiwindow mode, all X programs are considered as one wrt taskbar
buttons.  Nothing really new there, but it's more noticeable now that
the default is "Always combine, hide labels".  When combined, the icon
shown is that of the first program launched, which is obviously
inaccurate if several different X programs are running.

If a windowed X server is launched, it shows as one window with the X
icon (as expected), which will be grouped together with X programs
running multiwindow on a different DISPLAY.  Pinning that X icon to the
taskbar has the same effect.

It would be preferable to force ungrouping (or grouping by program in
multiwindow, if possible), but if that's not possible, the X icon should
represent the group no matter which program launched first.

2) It would be nice to port the tray icon menu to the new Jump List.

3) With Aero in multiwindow, fbpanel (in Ports) has a large border
around the panel.  IIRC there was a slight border in XP, but it's much
larger and more noticeable with Aero.

4) In multiwindow, if two programs overlap, then Aero Peek will show the
correct shape for each window but the contents of one window
superimposed on the other in their stacking order.

Anyone else testing 7RC1?


Yaakov
Cygwin/X

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

[Jon TURNEY]

Yaakov (Cygwin/X) wrote:

> On 15/05/2009 15:13, Jim Reisert AD1C wrote:
>> I have installed Windows 7 RC1 (64-bit) as well as Cygwin 1.7,
>> including the Xorg stuff in the Cygwin setup-1.7.exe file
>
> Same here.  I have also noticed the following issues:
>
> 1) In multiwindow mode, all X programs are considered as one wrt taskbar
> buttons.  Nothing really new there, but it's more noticeable now that
> the default is "Always combine, hide labels".  When combined, the icon
> shown is that of the first program launched, which is obviously
> inaccurate if several different X programs are running.
>
> If a windowed X server is launched, it shows as one window with the X
> icon (as expected), which will be grouped together with X programs
> running multiwindow on a different DISPLAY.  Pinning that X icon to the
> taskbar has the same effect.
>
> It would be preferable to force ungrouping (or grouping by program in
> multiwindow, if possible), but if that's not possible, the X icon should
> represent the group no matter which program launched first.

It doesn't seem to be clearly documented how the taskbar makes these
decisions: if it's based on the executable, the window class or name or some
hints associated with it.  It would be neat if we could set things up so that
the X windows group in the same way as native windows, but I'm not aware of a
way to do that...

The shell interface ITaskbarList() seems completely inadequate for this purpose.

> 2) It would be nice to port the tray icon menu to the new Jump List.
>
> 3) With Aero in multiwindow, fbpanel (in Ports) has a large border
> around the panel.  IIRC there was a slight border in XP, but it's much
> larger and more noticeable with Aero.
>
> 4) In multiwindow, if two programs overlap, then Aero Peek will show the
> correct shape for each window but the contents of one window
> superimposed on the other in their stacking order.

Yes, I've seen the same behaviour with the TaskSwitchXP alt+tab replacement.
This is a consequence of the way multiwindow mode is currently implemented:
everything is drawn onto a shadow framebuffer, and then areas from that are
drawn into native windows when they are exposed.  This means that we can only
correctly draw the contents of the X window at the top of the Z-order stack
(as this may be occluding other X windows).  There are probably solutions to this.


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

[Jon TURNEY]

>> 4) In multiwindow, if two programs overlap, then Aero Peek will show
>> the correct shape for each window but the contents of one window
>> superimposed on the other in their stacking order.
>
> Yes, I've seen the same behaviour with the TaskSwitchXP alt+tab
> replacement.
> This is a consequence of the way multiwindow mode is currently
> implemented: everything is drawn onto a shadow framebuffer, and then
> areas from that are drawn into native windows when they are exposed.  
> This means that we can only correctly draw the contents of the X window
> at the top of the Z-order stack (as this may be occluding other X
> windows).  There are probably solutions to this.

Forgive me for being rather too terse, but I am not sure what those solutions
might be.  I think those solutions involve using the rootless extension
(perhaps) or composite (definitely) to gain access to the bitmap for each
window independently.


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