Re: Windows 7 RC1 and Cygwin 1.7
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/
Re: Windows 7 RC1 and Cygwin 1.7
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/
Re: Windows 7 RC1 and Cygwin 1.7
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/
Re: Windows 7 RC1 and Cygwin 1.7
Hi Ben, sorry for the late response. That's what vacation does to you :} On May 19 21:04, richardvo...@gmail.com 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=443006SiteID=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=445558SiteID=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=447597SiteID=647 Marked as resolved but I can still reproduce in the latest build. https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=447443SiteID=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=442994SiteID=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/
Re: Windows 7 RC1 and Cygwin 1.7
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. -- View this message in context: http://www.nabble.com/Windows-7-RC1-and-Cygwin-1.7-tp23566592p23765787.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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/
Re: Windows 7 RC1 and Cygwin 1.7
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 us it to send info about a bug, however I am not sure if they care, and don't know what sort of fedback on to choose. -- View this message in context: http://www.nabble.com/Windows-7-RC1-and-Cygwin-1.7-tp23566592p23771256.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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/
Re: Windows 7 RC1 and Cygwin 1.7
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 jjreis...@alum.mit.edu 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/Ø, jjreis...@alum.mit.edu, 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/
Re: Windows 7 RC1 and Cygwin 1.7
On Sat, May 16, 2009 at 4:41 AM, Corinna Vinschen corinna-cyg...@cygwin.com 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/
Re: Windows 7 RC1 and Cygwin 1.7
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/
RE: Windows 7 RC1 and Cygwin 1.7
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] 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/
Re: Windows 7 RC1 and Cygwin 1.7
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/
