Well, I've kicked the -63 server around a fair bit this weekend and it seems to be holding up very well. No crashes, and generally no unpleasant surprises. I have still managed to activate the "2 second timeout" code, though, by doing some pathological things, that are probably impossible to work around due to the incompatibilities between the X and Windows conceptions of the clipboard.
Harold: In winClipboardFlushXEvents, I think the line: iReturn = XChangeProperty (pDisplay, event.xselectionrequest.requestor, event.xselectionrequest.property, event.xselectionrequest.target, 8, PropModeReplace, (char *) atomTargetArr, sizeof (atomTargetArr)); should have 32 instead of 8. Also, re the following, changelog, can you tell me where to find the changes. I see no calls to XSync or select at http://pdx.freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xwin/winclipboardxevents.c?rev=1.1.4.1.2.15&root=xorg&only_with_tag=CYGWIN&view=auto and I'd like to see the code that does this. Release 4.3.0-61 Released: 2004-03-25 0055 EST Download source: Now available as src package via setup.exe Changes: winclipboardwndproc.c, winclipboardxevents.c - Attempt to fix clipboard deadlock that was causing hangs. The nature of the fix was to stop calling XPeekIfEvent since it will block until the specified type of event is seen. Instead, we call XSync to flush output events and wait for them to be processed, then we do our own little loop with a call to select() using a timeout of 3 seconds from when we started (the timeout is adjusted after each call to select()). This should alleviate problems with XPeekIfEvent not returning. Finally, since we can detect whether the SelectionNotify event has arrived now, I added code to paste NULL to the Win32 clipboard if the X11 application never returns any useful clipboard data; this should prevent Win32 applications from freezing when there are problems pasting from X11 to Win32. (Harold L Hunt II - CodeWeavers)