Reducing configuration headaches for cygwin-xfree

Reducing configuration headaches for cygwin-xfree

[Øyvind Harboe]

Problem:

CygWin-xfree86 is tricky to install and configure and this limits who
can successfully install and use this software. 

(If you do not agree that this is a problem, then the rest of the
message is obviously irrelevant. :-)

Possible solution:

- 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".
- ssh -X profile.  Create icon(s) on desktop for the various
appliactions, e.g. Importantly xterm(cygwin local), xterm remote,
Evolution remote, OpenOffice remote.
- 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.
- infrequently updated. The users targeted by this sort of installer
never upgrade unless they absolutely have to.
- 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.
- The CygWin installer is a stumbling block itself. For those that
*only* want an X server, a gigantic self-installing .exe file  would be
better.
- "-clipboard" enabled by default.
- multimonitor support enabled by default.

Note, this is not a complaint! I love CygWin and I point to it as one of
the stellar examples of what the open source community can achieve with
minimal resources!

Øyvind

Re: Reducing configuration headaches for cygwin-xfree

[Alexander Gottwald]

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

> - The CygWin installer is a stumbling block itself. For those that
> *only* want an X server, a gigantic self-installing .exe file  would be
> better.

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. 

> - 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. 

> - 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.

> - 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

> - "-clipboard" enabled by default.

As long as it's not stable it will not be enabled by default.

> - multimonitor support enabled by default.

let's see

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723
 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004
 http://www.tu-chemnitz.de/linux/tag

Re: Reducing configuration headaches for cygwin-xfree

[Harold L Hunt II]

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
>>better.
> 
> 
> 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.

Right.

>>- 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.
> 
> 
> let's see

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.

Harold

Re: Reducing configuration headaches for cygwin-xfree

[Christopher Faylor]

On Wed, Mar 03, 2004 at 02:51:01PM +0100, Alexander Gottwald wrote:
>>- 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.

Yes, it comes up periodically in the cygwin mailing list but it is not
something that I, or any other developer, have any interest in
exploring.

It is not impossible to run two installations at the same time, as long
as you don't expect communication between the two.  However, this is
a wonderfully self-selecting type of activity.  If you know what you're
doing, it's not that hard to set up and use.  If you don't know what
you're doing and things like DLLs, shared memory, and source code are
a mystery then you're probably not going to be able to set things up.

That is how it should be.  I really don't want to be debugging problems
from people who have multiple cygwins on their systems but don't really
understand the problems inherent in doing that.  The mantra is that
newer versions of cygwin always work with older versions of programs so
you should only ever need one version of cygwin.

>> - The CygWin installer is a stumbling block itself. For those that
>> *only* want an X server, a gigantic self-installing .exe file  would be
>> better.
>
>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. 

AFAIK, you wouldn't want to install X without also installing some other
things like bash, at least.  I would think you'd want other tools like
'cp', as well.  Since people always complain that the minimal
installation for cygwin (which is the default) doesn't have enough stuff
in it, I don't really understand why the minimal installation + X would
have too much.

However, there was a brief discussion in the cygwin list of introducing
"personalities" to the cygwin setup utility to accommodate different uses.
If this is something that is useful to the Cygwin/X project then hop over
to cygwin-apps and provide a patch or at least discuss this option with
others who are interested in implementing it.

cgf

Re: Reducing configuration headaches for cygwin-xfree

[Alexander Gottwald]

On Thu, 4 Mar 2004, Christopher Faylor wrote:

> AFAIK, you wouldn't want to install X without also installing some other
> things like bash, at least.  I would think you'd want other tools like
> 'cp', as well.  Since people always complain that the minimal
> installation for cygwin (which is the default) doesn't have enough stuff
> in it, I don't really understand why the minimal installation + X would
> have too much.

One scenario is the stand-alone xserver which just acts as terminal for 
remote access. 

bye
	ago 
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723
 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004
 http://www.tu-chemnitz.de/linux/tag

Re: Reducing configuration headaches for cygwin-xfree

[Christopher Faylor]

On Thu, Mar 04, 2004 at 04:07:00PM +0100, Alexander Gottwald wrote:
>On Thu, 4 Mar 2004, Christopher Faylor wrote:
>>AFAIK, you wouldn't want to install X without also installing some
>>other things like bash, at least.  I would think you'd want other tools
>>like 'cp', as well.  Since people always complain that the minimal
>>installation for cygwin (which is the default) doesn't have enough
>>stuff in it, I don't really understand why the minimal installation + X
>>would have too much.
>
>One scenario is the stand-alone xserver which just acts as terminal for
>remote access.

How would you manage remote access if you didn't at least have bash,
though?  Run xterm + cmd.exe, maybe?

cgf

Re: Reducing configuration headaches for cygwin-xfree

[Igor Pechtchanski]

On Thu, 4 Mar 2004, Christopher Faylor wrote:

> On Thu, Mar 04, 2004 at 04:07:00PM +0100, Alexander Gottwald wrote:
> >On Thu, 4 Mar 2004, Christopher Faylor wrote:
> >>AFAIK, you wouldn't want to install X without also installing some
> >>other things like bash, at least.  I would think you'd want other tools
> >>like 'cp', as well.  Since people always complain that the minimal
> >>installation for cygwin (which is the default) doesn't have enough
> >>stuff in it, I don't really understand why the minimal installation + X
> >>would have too much.
> >
> >One scenario is the stand-alone xserver which just acts as terminal for
> >remote access.
>
> How would you manage remote access if you didn't at least have bash,
> though?  Run xterm + cmd.exe, maybe?
>
> cgf

Remote access as in running a remote xterm and displaying it on a local X.
Either that, or XDMCP.  The first obviously also needs some other way of
connecting to the remote machine (e.g., telnet).
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Re: Reducing configuration headaches for cygwin-xfree

[Harold L Hunt II]

Igor Pechtchanski wrote:

> On Thu, 4 Mar 2004, Christopher Faylor wrote:
> 
> 
>>On Thu, Mar 04, 2004 at 04:07:00PM +0100, Alexander Gottwald wrote:
>>
>>>On Thu, 4 Mar 2004, Christopher Faylor wrote:
>>>
>>>>AFAIK, you wouldn't want to install X without also installing some
>>>>other things like bash, at least.  I would think you'd want other tools
>>>>like 'cp', as well.  Since people always complain that the minimal
>>>>installation for cygwin (which is the default) doesn't have enough
>>>>stuff in it, I don't really understand why the minimal installation + X
>>>>would have too much.
>>>
>>>One scenario is the stand-alone xserver which just acts as terminal for
>>>remote access.
>>
>>How would you manage remote access if you didn't at least have bash,
>>though?  Run xterm + cmd.exe, maybe?
>>
>>cgf
> 
> 
> Remote access as in running a remote xterm and displaying it on a local X.
> Either that, or XDMCP.  The first obviously also needs some other way of
> connecting to the remote machine (e.g., telnet).

Note that it also works fine with any ssh implementation, such as PuTTY.

Harold

Re: Reducing configuration headaches for cygwin-xfree

[Alexander Gottwald]

On Thu, 4 Mar 2004, Christopher Faylor wrote:

> How would you manage remote access if you didn't at least have bash,
> though?  Run xterm + cmd.exe, maybe?
> 
> cgf

with XDMCP. Start XWin -query linux-host and you'll get a window just like 
with MS Terminal Service.

This only requires XWin, cygwin1.dll, cygX11-6.dll, cygcygipc.dll an cygz.dll

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723
 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004
 http://www.tu-chemnitz.de/linux/tag

Re: Reducing configuration headaches for cygwin-xfree

[Øyvind Harboe]

I see there is no lack of awareness on this issue :-)


A couple of more comments:

- Regarding cygwin1.dll side-by-side install issue. I do believe that
if multiple different versions of CygWin could be installed side-by-side,
this could improve stability of the applications. I use CygWin for different 
things and I don't want an upgrade to my X server to topple my arm-elf-gcc
toolchain or vice versa.  But as Alexander pointed out: this won't happen.

- Regarding open-source GUI. Here is another alternative. Written in Java and
compiled with w/GCJ + Eclipse SWT. This would result in a native windows executable
with a Windows GUI and no dependencies on anything not shipping in Windows(not even 
msvcrt.dll or cygwin1.dll). GCJ comes w/CygWin. 

gcj -mno-cygwin -fjni -o hello.exe --main=HelloWorld swt_sans_awt.jar HelloWorld.java 



Øyvind