> My solution for the time is > pragmatic, but > I'd like to get to the bottom of this eventually. For now I > just reopen the > log file handle in OsVendorInit if it was opened in > ddxProcessArgument:
Okay - a few ErrorF()'s, bit of stracing and recompiles later ... What kills the file handle is fclose(stdio) in os/osinit.c. Why? Well, X, like many programs, makes assumptions about stdio, stdout and stderr (it assumes that they are on fd's 0, 1 and 2). This is bad. Now, what must have happened is that when XWin.exe is started without the /B flag the file descriptor we get when we open our log file is 0 (namely stdin). Why would we get this? Well, why not? XWin doesn't have a console when it starts (is used to according to Harold so this is most likely when it last worked!) so we just get the first FD. Why we don't get this FD when we start XWin.exe with /B is another matter (erm - windows experts out there ... maybe windows does something special with them) The real fix? Well - the bug is in core X and not the cygwin port. Attached is a patch which stops OsInit() from closing stdin and stdout if compiling for cygwin. I still contend that those closes shouldn't be there at all - but that's for an XFree86 developer to decide as it will effect all platforms. This patch just fixes it for cygwin. Stuart
log.patch
Description: Binary data
