I use CYGWIN a lot with 64-bit Windows 7 and have been transitioning from 32-bit CYGWIN to 64-bit CYGWIN primarily in hopes of avoiding repeated STATUS_ACCESS_VIOLATION errors. If I could set up 64-bit CYGWIN (= C64) to behave exactly the same way as my 32-bit CYGWIN (= C32) set up I would, but the applications don't match up exactly and they don't behave exactly the same way. One difference I notice is that opening a urxvt in C64 creates a separate button associated with the Cygwin/X server process in the taskbar, whereas opening an rxvt in C32 does not. (rxvt is not available as a C64 application, but I would expect urxvt to operate similarly). In both cases an icon for the Cygwin/X server process shows up in the notification area. Both are started from a Windows shortcut: C32 target: C:\win32app\cygwin\bin\run.exe C:\win32app\cygwin\rxvtermX.bat C64 target: C:\win64app\cygwin\bin\run.exe C:\win64app\cygwin\urxvtermX.bat The batch files that run are similar. Both start 'XWin' if it is not already running, then run 'rxvt/urxvt'. Contents of 'rxvterm.bat' (C32): ================================= @echo off C: chdir C:\win32app\cygwin\bin ps -ef | grep /usr/bin/XWin > nul if ERRORLEVEL 1 ( start /DC:\win32app\cygwin\bin /B XWin -multiwindow ) set DISPLAY=localhost:0.0 rxvt -fn 10x20 -sl 10000 +sr -fg yellow -bg navyblue -title "RXVTerm w/X" -e /usr/bin/bash --login -i Contents of 'urxvterm.bat' (C64): ================================= @echo off C: chdir C:\win64app\cygwin\bin ps -ef | grep /usr/bin/XWin > nul if ERRORLEVEL 1 ( start /DC:\win64app\cygwin\bin /B XWin -multiwindow ) set DISPLAY=localhost:0.0 urxvt -fn 10x20 -sl 10000 +sr -fg yellow -bg navyblue -title "URXVTerm w/X" -e /usr/bin/bash --login -i I prefer NOT to have the taskbar button for the Cygwin/X server process show up. Having an icon show up in the notification area is cleaner. Why are they behaving differently? Is there a way to make the urxvt version (C64) behave like the rxvt version (C32)? John Ottusch -- 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/
On 29/11/2015 02:56, John J Ottusch wrote: > I use CYGWIN a lot with 64-bit Windows 7 and have been transitioning > from 32-bit CYGWIN to 64-bit CYGWIN primarily in hopes of avoiding > repeated STATUS_ACCESS_VIOLATION errors. > > If I could set up 64-bit CYGWIN (= C64) to behave exactly the same way > as my 32-bit CYGWIN (= C32) set up I would, but the applications don't > match up exactly and they don't behave exactly the same way. > > One difference I notice is that opening a urxvt in C64 creates a > separate button associated with the Cygwin/X server process in the > taskbar, whereas opening an rxvt in C32 does not. (rxvt is not available > as a C64 application, but I would expect urxvt to operate similarly). In Yes, please use rxvt-unicode (urxvt). rxvt has been dead upstream for a decade. > both cases an icon for the Cygwin/X server process shows up in the > notification area. > > Both are started from a Windows shortcut: > > C32 target: > C:\win32app\cygwin\bin\run.exe C:\win32app\cygwin\rxvtermX.bat > > C64 target: > C:\win64app\cygwin\bin\run.exe C:\win64app\cygwin\urxvtermX.bat > > The batch files that run are similar. Both start 'XWin' if it is not > already running, then run 'rxvt/urxvt'. > [...] > I prefer NOT to have the taskbar button for the Cygwin/X server process > show up. Having an icon show up in the notification area is cleaner. > > Why are they behaving differently? Is there a way to make the urxvt > version (C64) behave like the rxvt version (C32)? I think this is not a problem with the X server, but with the Cygwin run utility, which is supposed to run the .bat file with a hidden console. See [1] a previous discussion of this problem. I've built an x86_64 run.exe with that patch applied and uploaded it at [2]. Perhaps you could try that and see if it improves things. [1] http://cygwin.com/ml/cygwin-xfree/2012-08/msg00000.html [2] ftp://cygwin.com/pub/cygwinx/x86_64/run.exe -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/
> I think this is not a problem with the X server, but with the Cygwin run > utility, which is supposed to run the .bat file with a hidden console. > See [1] a previous discussion of this problem. > I've built an x86_64 run.exe with that patch applied and uploaded it at > [2]. Perhaps you could try that and see if it improves things. > [1] http://cygwin.com/ml/cygwin-xfree/2012-08/msg00000.html > [2] ftp://cygwin.com/pub/cygwinx/x86_64/run.exe -- Makes sense that it could be run.exe behavior. However, the version of run.exe from [2] (which is 220K in size vs. 68K for the original version ?!?) does not seem to do anything. Running it from a CMD window with urxvtermX.bat as the argument does not produce an error message, a urxvt term, nothing. BTW, I made an effort to give both versions of run.exe (I renamed the new one runX.exe) the same ownership and permissions, but to no avail. Am I missing something essential? jjo P.S. My apologies if this message is not properly threaded. I see how one can post an original message from 'http://post.gmane.org/post.php? group=gmane.os.cygwin.xfree', but not how one goes about replying to a previously posted message. -- 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/
On 02/12/2015 00:16, John J Ottusch wrote: > Makes sense that it could be run.exe behavior. > > However, the version of run.exe from [2] (which is 220K in size vs. 68K > for the original version ?!?) does not seem to do anything. Running it > from a CMD window with urxvtermX.bat as the argument does not produce an > error message, a urxvt term, nothing. It's larger because it doesn't have debug information stripped. > BTW, I made an effort to give both versions of run.exe (I renamed the > new one runX.exe) the same ownership and permissions, but to no avail. > > Am I missing something essential? Just chmod +x should be sufficient. I've probably done something wrong, although I have re-tested this run.exe and it seems to work for me. Perhaps you could try 'strace ./run XWin', that might shed some light on what's going wrong? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/
Thanks for the tip. First of all, using 'strace' I determined that testing is not advisable with the 'run.exe' executable named anything other than just 'run.exe'. Renaming the executable to 'runX.exe' ends up being interpreted as 'run X' and things go wrong from there. The good news is that the version of 'run' Jon Turney provided does indeed withhold taskbar display of the CMD window from which urxvtermX.bat is run. The bad news is that I have to execute the target 'C:\win64app\cygwin\bin\run.exe C:\win64app\cygwin\urxvtermX.bat' twice (or sometimes more). The first time through starts up 'Cygwin/X Server:0.0'. The second and any subsequent times it creates a new 'urxvt' term. jjo -- 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/