Certainly there are lots of things that need work at this point with X.org's Xwin. I also have the same problem as described below. What I did to resolve the problem is to replace the "run" keyword with "start". "run" was a cygwin command (run.exe), while "start" is Windows shell (cmd.exe) intrinsic command.
The other complaint is this: Xwin often closes by itself with NO warning, nothing written in /tmp/XWin.log. Here's my XWin.log quote: [EMAIL PROTECTED] ~ $ cat /tmp/XWin.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 6.7.0.0-8 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -unixkill -nowinkill -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1024 winInitializeDefaultScreens - Returning _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 (II) XF86Config is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 00000007 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - Using Windows display depth of 24 bits per pixel winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shar ed memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: "00000409" (00000409) (EE) Keyboardlayout "US" (00000409) is unknown Rules = "xorg" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)" Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! winPointerWarpCursor - Discarding first warp: 797 480 winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. ------ yip, and not too long after, the X screen disappears! No core dump was found in $HOME directory or /tmp. Note: I use WindowMaker as the window manager. Wirawan OOT: Are you sure that the %CYGWIN_ROOT%\tmp\.X11-unix subdir is properly created? This issue is a disgression from the discussion topic, but let me mention it. It may worth looking into to fix the current implementation of my-startxwin.bat. This directory is actually a problem, if someone cares. In my case, the cygwin "partition" lives on an NTFS filesystem, and I use ntsec (NT Security) to provide the "real" unix file permissions. This poses a problem. The X server needs /tmp/.X11-unix subdir, which may or may not be accessible by any user starting the session. This may in turn fails the whole X session. Why? Since the X session is started by an ordinary _user_ (and not by ROOT as in Linux). The subdir /tmp/.X11-unix, if created by a user, say, XYZ, will not be erasable by another user starting X session (later) on the same machine. Suppose there are 2 users on that machine that can start X sessions (of course not concurrently, I would assume, but that can also happen on an XP box). For simplicity let me assume that they are 2 different users that would start X at different times, and the sessions do not overlap. The first user started it, and my-startxwin.bat creates /tmp/.X11-unix (OWNED by the first user). Now this session is properly terminated. Then the other user tried to start with my-startxwin.bat, but it wouldn't be able to, as /tmp/.X11-unix has been there and created by someone else. NTFS permission is so strict that even administrators can't always able to erase that subdir! Let me outline my solution: I had to customize the script, by replacing %CYGWIN_ROOT%\tmp to another directory which is accessible only to me. In this case, I create C:\cygwin\tmp\wirawan, and MOUNT that subdir as /tmp *for me only*: [EMAIL PROTECTED] ~ $ mount -u -b 'C:\cygwin\tmp\wirawan' /tmp Then all references to %CYGWIN_ROOT%\tmp are replaced with C:\cygwin\tmp\wirawan. This can pose another trickery, but it works for me. My X session would generate .X11-unix subdir in *my* /tmp, not in global tmp (C:\cygwin\tmp). On Thu, 13 May 2004, it was written: > Since updating to the newest xorg distribution weird things are happening > with starting Xwin from startxwin.bat. I used to be able to start multiple > windows in a 800 by 600 screen with the blackbox window manager. Now when > I try that using the -scrollbars -clipboard -screen 0 800 600 no window > appears although when I kill X it thinks there are 2 clients connected?! I > removed "run" from in front of Xwin in the batch file and that works, well, > every other time. I start startxwin.bat and it pops up the X window but then > doesn't start the window manager or xterm. If I kill X and restart, then it > works (although it crashes at random times - it used to never crash). Rootless > and multiwindow work, although I like having all my X stuff in its own window > and using rootless and multiwindow I don't have the benefits of blackbox (i.e. > opening a new xterm session by right-clicking). Is anyone else having these > problems? >
