This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Possibly incorrect explanation of how WaitForSomething works (and how to fix it) [RC and CGF please comment]


----- Original Message -----
From: "Harold Hunt" <huntharo@msu.edu>
To: "'Robert Collins'" <robert.collins@itdomain.com.au>; "'Cygx
(E-mail)'" <cygwin-xfree@sources.redhat.com>
Sent: Wednesday, April 11, 2001 5:12 AM
Subject: RE: Possibly incorrect explanation of how WaitForSomething
works (and how to fix it) [RC and CGF please comment]


> > I thought cygwin had fd support for keyboard and mouse? If it
doesn't,
> > then my suggestion would be: write it.
>
> > Just to be difficult: why not pthreads? mutex's, condition
variables,
> > thread specific data, limited scheduling (soon to be much
> > more) are all
> > present in snapshots at the moment.
>
> Hmm... I didn't think of that because my idea is to make the X/Server
> independent of Cygwin, so that it can be installed easily and without
> worrying about duplicate copies of cygwin1.dll, etc.  However, I want
to
> keep the XLibs dependent upon Cygwin so that local clients will
require
> minimal porting, if any.

I'm not about to discourage a developer... but I will throw in my
opinions :]

1) There is a different project that has an independent X server - the
win32-x11 project - it's hosted at sources.redhat as well.
2) duplicate cygwin1.dll's are no worse to manage than duplicate or
overwritten msvcrt.dll's. Really!.
3) AFAIK the X server already uses a bunch of cygwin stuff - ripping it
out is going to be iffy at best.
4) AFAIK You will not be able use unix domain sockets for client
connections, or shared memory across local clients if you do not link
with cygwin1.dll. Other things like unix permissions and so on come to
mind

> Thus, my development efforts have centered around using only Win32 API
> calls.  I haven't written a function yet that make a Cygwin API call.

There's only about 20 Cygwin calls. I'm not surprised you haven't made
one. Oh! you mean posix calls? That's a different matter. Add to the
list above, mounted directories in the X server path/font path/shared
library path, symlinks in the path. oh, fstat, read, write, open, close
are all coming from cygwin1.dll at the moment. And they will all break
when you build without linking to cygwin1.dll.

Try running a strace over Xwin.exe

> It would be possible, and perhaps beneficial to some, to write an
X/Server
> for Windows that is completely intertwined and dependent on Cygwin...
but
> that's not an itch I have, so I won't be scratching it :)

Uh yeah, that's what Suhaib did. And that's what you're working on isn't
it?!

> In any case, everything you suggested was stuff I hadn't thought of,
and
> some of your suggestions were things that I hadn't even known existed
> (/dev/keyboard, etc.); knowing about these things will probably come
in
> handy in the future should I do some *nix system-level programming or
if I
> give up on my idea of making the X/Server independent of Cygwin :)

IMO, depending on Cygwin is a good thing. It eases development and
porting headaches, whilst allowing access as needed to the Win32 API. If
the only reason for not utilising Cygwin1.dll is difficulties with
version skew, then I say, don't worry.
====
That's trivial compared to the confusion that will arise in shipping an
X-Server than cannot utilise Cygwin paths/mount points/symlinks but
ships with X-Libs that can. We had about 2 weeks preview into that while
the win32-x11 files were in the Xfree86 directory, and I believe it can
only get worse.
 ====
Second key point: cygwin's installer is nearly ready to install X for
the end user - its got alpa support for bzip2 files thanks to Chris. You
won't get much easier than installing via setup.exe.

> Thanks for the feedback,
>
> Harold
>

Always happy to discuss :]

Rob



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]