broken links in Cygwin-X menu on win7 64 Error could not start C:\cygwin\bin\xemacs-21.4.22.exe(a single strange character kind of I)!! -display 127.0.0.1:0.0
Hi I have just installed cygwin on my Win7 Home Premium 64 machine. I installed everything from the cygwin repository following instructions on the setup page. However, some of the links on Cygwin-X menu as well as the shortcuts on the desktop are broken. As an example the Xemacs shortcut is broken while the gvim shortcut just works fine. I have the following properties for these links: Xemacs Target=C:\cygwin\bin\run.exe -p /usr/X11R6/bin xemacs -display 127.0.0.1:0.0 Start in=C:\cygwin\bin gvim Target=C:\cygwin\bin\run.exe -p /usr/X11R6/bin gvim -display 127.0.0.1:0.0 Start in=C:\cygwin\bin Both shortcuts look pretty similar however, starting xemacs using the shortcut results in the following Run.exe error message Error could not start C:\cygwin\bin\xemacs-21.4.22.exe(a single strange character kind of I)!! -display 127.0.0.1:0.0 The strange character added to the 2 exclamation marks at the end of the executable name is already intringuing. Looks like windows is messing up with some string termination. The file xemacs-21.4.22.exe does exists in the bin directory and I can manually start xemacs from the console without problem using either xemacs or xemacs-21.4.22. Strangely enough, the emacs shortcut with the following properties works pretty well too emacs Target=C:\cygwin\bin\run.exe -p /usr/X11R6/bin emacs -display 127.0.0.1:0.0 Start in=C:\cygwin\bin The postinstallation script also created Singular 3 shortcuts on the desktop. The shortcuts Singular (Terminal) and the shotcut Singular (Rxvt) work without problem. The third one Singular (Emacs and X-server) does not work. No error message is dispalyed and nothing happens when clicking on this shortcut. I am using a french version of win7 home premium. Thanks for any hint Guy -- 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: bug report/suggested temp. patch: handling bursts of sent keys
I've done a bit more investigating. It appears that winWindowProc can block at the cost of preventing processing of any Windows messages until it returns. Does anyone know how fast the mieq queue drains? If this isn't very fast, then having winWindowProc block waiting for the mieq queue is probably a bad idea. There are a number of comments in mieq.c that may shed light on why the queue is statically allocated: mieq.c:76: EventRec events[QUEUE_SIZE]; /* static allocation for signals */ mieq.c:138: /* * Must be reentrant with ProcessInputEvents. Assumption: mieqEnqueue * will never be interrupted. If this is called from both signal * handlers and regular code, make sure the signal is suspended when * called from regular code. */ void mieqEnqueue(DeviceIntPtr pDev, InternalEvent *e) Does anyone understand this? Does this bar dynamically allocating the queue? The queue does not appear to use locking unless XQUARTZ is defined. Does anyone know what conditions that is defined under? I'm beginning to think that simply patching the queue to be very large is the best solution. - Mark -- 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: bug report/suggested temp. patch: handling bursts of sent keys
On 2010-02-01 12:33 AM, Mark Lillibridge wrote: I've done a bit more investigating. It appears that winWindowProc can block at the cost of preventing processing of any Windows messages until it returns. Does anyone know how fast the mieq queue drains? If this isn't very fast, then having winWindowProc block waiting for the mieq queue is probably a bad idea. There are a number of comments in mieq.c that may shed light on why the queue is statically allocated: mieq.c:76: EventRec events[QUEUE_SIZE]; /* static allocation for signals */ mieq.c:138: /* * Must be reentrant with ProcessInputEvents. Assumption: mieqEnqueue * will never be interrupted. If this is called from both signal * handlers and regular code, make sure the signal is suspended when * called from regular code. */ void mieqEnqueue(DeviceIntPtr pDev, InternalEvent *e) Does anyone understand this? Does this bar dynamically allocating the queue? The queue does not appear to use locking unless XQUARTZ is defined. Does anyone know what conditions that is defined under? I'm beginning to think that simply patching the queue to be very large is the best solution. - Mark Well XQuartz is what the server is called on Mac OS 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/
