It doesn't work for me. Here is my command line:
C:\cygwin\usr\X11R6\bin\XWin.exe -fullscreen -nowinkill -once -query jeeves -clipboard The XWinrl.log: ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (==) Using config file: "/etc/X11/XF86Config-4" Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (??) unknown. (**) FontPath set to "/usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/l ib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/ X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0000001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel winAllocateFBShadowDDNL - Not changing video mode winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 6400 winAllocateFBShadowDDNL - Created shadow pitch: 6400 winAllocateFBShadowDDNL - Created shadow stride: 1600 winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff winInitVisualsShadowDDNL - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - Calling winInitClipboard. winInitClipboard () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. winClipboardProc - Hello winClipboardProc - Calling pthread_mutex_lock () (**) Using keyboard "Keyboard1" as primary keyboard (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "gb" (**) XKB: layout: "gb" Rules = "xfree86" Model = "pc105" Layout = "gb" Variant = "(null)" Options = "(null)" winBlockHandler - Releasing pmServerStarted winClipboardProc - pthread_mutex_lock () returned. DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - Calling setlocale () winBlockHandler - pthread_mutex_unlock () returned winClipboardProc - setlocale () returned winClipboardProc - pthread_mutex_unlock () returned. winClipboardProc - XInitThreads () returned. winClipboardProc - DISPLAY=127.0.0.1:0.0 AUDIT: Thu Jan 30 19:42:54 2003: 2168 XWin: client 2 rejected from IP 127.0.0.1 port 3398 winClipboardProc - Could not open display, try: 1, sleeping: 4 AUDIT: Thu Jan 30 19:42:58 2003: 2168 XWin: client 5 rejected from IP 127.0.0.1 port 3849 winClipboardProc - Could not open display, try: 2, sleeping: 4 AUDIT: Thu Jan 30 19:43:03 2003: 2168 XWin: client 6 rejected from IP 127.0.0.1 port 3063 winClipboardProc - Could not open display, try: 3, sleeping: 4 winClipboardProc - Failed opening the display, giving up I have a local (global to the local machine, set via 'My Computer icon - w2k) environment variable DISPLAY=tuppy:0.0. I have this because the x server doesn't seem to be serving on localhost. If I run xterm locally, I get an xterm on my display (I have set up the permissions to do that). I can run xwinclip.exe and that works fine. It seems that the winClipboardProc should pick up what IP address(es) the server is serving on, now it is built in. Is there currently any way of telling it either to serve on localhost as well as the Ethernet adapter, or telling the clipboard function which adaptor the x server is serving on? Regards, Nigel Hathaway ************************************ Barnabas Projects Limited Tel: +44 117 937 4197 Internet: http://www.bprj.co.uk