Why Xming.exe?

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

First of all: I love CygWin! 

If I didn't, I would not passionatly dive into this discussion. :-)

Here are a couple of reasons why I think a discussion of 
Xming.exe can bring something to CygWin.

Basically, I believe that the Xming.exe would never have seen the
light of day if if all was well with CygWin. It is a cry for help.

Also, I believe the next useful solution to the set of problems that
CygWin is facing is non-local. I think it is in the interest of CygWin
to allow discussions and hacks to wander somewhat freely. 

If you stomp out this discussion, you are going to make people look elsewhere 
for a solution to "the CygWin mess". See bottom of this message for 
what I mean.

Some issues that CygWin could address to make Xming.exe moot:

- Side-by-side install. There is a need for e.g. SSH + and an X server in
a single package that is easily deployable. This package 
*must* be unaffected by updates to CygWin. This would of course
not be uniquely useful for X server, but would be useful for e.g. multiple
independent GCC toolchains used for embedded development. E.g. its more
than once that CygWin updates have broken http://sources.redhat.com/ecos
tools, without bringing any new features or improvements for those tools.
The many examples of cygwin1.dll being distributed along with various applications,
is further evidence of this need(which is contrary to the CygWin license, BTW).

- Side-by-side means CygWin next to CygWin, and CygWin next to any Windows
program.

- It is currently impossible for the casual programmer to debug CygWin
X using GDB. See http://cygwin.com/ml/cygwin-xfree/2004-10/msg00159.html

- CygWin is a pain to install. It takes long to download(many files more than
size with a broad connection), takes long to install and many things can and do
go wrong. 

- CygWin messes with Windows environment variables, breaking other programs. 

- CygWin is broken by other programs using the Windows environment variables.

- CygWin is always in motion.  There is no "CygWin distribution version" 
like the Linux distributions operate with. There is no way to install
"a specific old boring CygWin" to run some tools that never change.


--- ever-so-slightly off topic :-) ---

Could I delete CygWin?

What I would need in it is place was the ability for Windows programs to interface
to Linux programs.  Where those programs run(under Linux or under Windows) is somewhat
secondary.

If I could somehow tell the Windows programs to talk to a Linux box
(http://www.colinux.org  or a real Linux box) as if those Linux programs ran
under Windows, then it would do the trick. http://www.colinux.org is an 
interesting case, because they pretty much support side-by-side installs already.

The Windows programs that need to interface to the Linux programs only talk to
those programs through the following mechanisms:

- stdin/stdout/stderr 
- ctrl-c to abort applications(there is a name for this communication channel, 
but I don't know what it is).
- current directory
- files (from Windows to Linux box and vice versa).
- console

(What did I leave out?)

Below is an a rough idea on how this might be solved:

- create a Windows filing system that makes the Linux box filing system
available through e.g. a drive letter. This filing system is different from
Samba. This filing system talks to the Linux box using SSH, say.
- when Windows is accessing a Linux executable via this filing system, it
does not serve up the Linux executable. Instead it serves up a Windows executable.
This Windows executable uses, say, SSH to communicate with the Linux box to
execute the command. Lets call this executable an SSH-Proxy. 
- The Linux box needs to be able to see the files on the Windows machine. Mechanism 
TBD. The SSH-Proxy knows how to translate from a Windows filename to the Linux
filename. It uses this capability to set the current directory before executing the
Linux command.
- The SSH-Proxy tells the Linux box about the limitations of the Windows console.

Example:

- On the Windows machine the root of the Linux box is accessible via the drive
letter e:\
- e:\etc maps to /etc, e:\usr to /usr, etc.
- e:\exec is special. It does not map to /exec. Instead it is used in execution
of programs that are in the path, as shown below.
- On the Linux box, there is an equivalent of "/cygdrive", which I'll call
"/windows"

To grep my local harddrive I would:

c:\bar> e:\exec\grep -r foo *

On the Linux box, this would actually be executed as:

oharboe@lair /windows/c/bar
$ grep -r foo *


-- 
Øyvind Harboe
http://www.zylin.com