This is the mail archive of the
mailing list for the Cygwin XFree86 project.
Re: Reducing configuration headaches for cygwin-xfree
Alexander Gottwald wrote:
On Wed, 3 Mar 2004, Øyvind Harboe wrote:
CygWin-xfree86 is tricky to install and configure and this limits who
can successfully install and use this software. (slightly resorted)
My comments on these topics:
- cygwin1.dll side-by-side install issue solved, i.e. it should be
possible to have a stable version of this X server installed next to a
bleeding edge CygWin.
This is an issue that must be solved by the cygwin folks and it is unlikely
that is ever will. the shared memory sections are required for interprocess
communication. if there are two different cygwin1.dlls floating around
(even renamed and the shared memory separated) it will break the xserver
integration into the cygwin layer.
==> no go
I think he is saying that we use the installed cygwin1.dll since it is
not usually the cause of stability problems. That is totally
acceptable. Though, I think it could have been worded better :)
- The CygWin installer is a stumbling block itself. For those that
*only* want an X server, a gigantic self-installing .exe file would be
Separate installers for cygwin programs is pain. Wincvs has done it. OpenSSH
has done it. And a lot more too. And it always leads to _huge_ problems if
you want to use them together. Most installers also install their own
cygwin1.dll with different version and then the programs just bomb.
I'm not going to be writing an installer anytime soon.
- Create an installer that has various preconfigured profiles which then
dictates the rest of the settings. Just like xfree86 has lots of C code
that I don't know or understand, the various configuration options and
.bat files and scripts must be moved out of the "user domain".
There were about 5 tries to build a wrapper which handles this. But always
it was written with Delphi, VisualC++ or some other non-free compiler.
If someone build such a wrapper with plain gcc it is very likely to become
included. But not if it depends on VCL, MFC or some other non-free class
library. Also adding other dependencies to eg QT or GTK is a bad idea.
A simple plain windows application (like cygwin setup) is preferred.
I am actually thinking about finally doing this in a way that everyone
can contribute to. I have built some test programs using OpenWatcom and
they work great; OpenWatcom uses the same w32api headers and libs that
Cygwin uses, so it is possibly to compile native Win32 apps in
OpenWatcom with no trouble. Additionally, the C runtime is linked
statically by default, which means that the distributed executable has
no dependencies on external DLLs like MinGW does. In summary,
OpenWatcom finally makes this sort of thing possible.
Now, whether or not I actually get around to writing this sort of
interface is another question. :)
Oh, one note worth mentioning: I agree that the proper way to do this
sort of "profile" app is via a stand-alone application that creates
command lines for XWin.exe. There is little reason and little benefit
to trying to integrate this sort of thing into XWin.exe. However, one
of the things required by such an approach is a way to get a unique
display number for each invocation of XWin.exe automatically.
- ssh -X profile. Create icon(s) on desktop for the various
appliactions, e.g. Importantly xterm(cygwin local), xterm remote,
Evolution remote, OpenOffice remote.
This is an option for the wrapper. Then it's not only a wrapper but also
a configtool for the whole X11 environment.
- XDCMP. I don't know much about this, so I won't comment, but I see
that this accounts for a lot of the traffic in this mailing list.
The most problems result in problems with disabled xdmcp on linux side.
This is already covered in the faq.
Another problem that still remains is that -query commands (by far the
most popular) do not always send the outbound interface address as the
first address in the list to the XDM server. The XDM server is supposed
to check all addresses in the list, but the sample implementation does
not, nor do KDM and GDM; so in reality, only the first address is looked
at. I just about have a patch in hand that sorts the outbound address
to the top of the list, which will eliminate the remaining cases where
the -from parameter is required for a -query.
Then the only remaining Xdmcp problems will be due to XDM not being
configured properly or do to firewalls.
- infrequently updated. The users targeted by this sort of installer
never upgrade unless they absolutely have to.
A "check for updates" button in the configtool/wrapper
Not a bad idea.
- "-clipboard" enabled by default.
As long as it's not stable it will not be enabled by default.
It is getting very close. At least it doesn't crash XWin.exe anymore
and it doesn't cause problems with Xdmcp... so we are getting close to
enabling it by default.
- multimonitor support enabled by default.
Yes, that is still a matter of preference.
I think it might be a good idea to start launching one X screen per
display and tie them together with Xinerma like a *nix machine would do.
This would allow us to forget about how Windows treats multiple
displays and let people handle it in an X sort of way. Again, this is
more code that would have to be written.