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]
Other format: [Raw text]

RE: Multiple XWin.exe programs loading and no xterm


On Thursday, April 07, 2005 8:58 PM, Alexander Gottwald wrote:

>On Thu, 7 Apr 2005, Phil Betts wrote:
>> Is it possible that xinit similarly thinks all is well?
>
> I don't think so. 
 
Good.

> Nothing forks except bash (or cmd or whatever) The xserver on unix
does not 
> put itself to background. It starts, accepts connections and exits
sometime.
> Putting it in the background is exactly done by bash on "Xorg &" or by
cmd.exe
> on "start XWin".

Which is exactly what I said it did, but then in the interests of
brevity, I appear to have cut it out ;-)  My point about forking was
not specific to X, but to daemon startup (which is effectively what is
happening with XWin)

> I start XWin with a single shortcut. And clients later as I need them.

Me too.

> Putting
> the xterm in the startup script is just for convenience and for
preventing 
> silly postings "I started startxwin.bat and there is nothing
happening". Now
> people at least see a window. But then they complained "Calling
startxwin.bat 
> twice pops up an error message stating I started the xserver twice".
This is
> just the third problem with a feature I consider completly useless.
Maybe I 
> should remove it and point the poeple to the users guide instead. 

That would be my choice.  It would help reinforce the difference
between client and server and help to educate newcomers to X.
It seems that a lot of the queries demonstrate a failure to grasp the
fundamentals of how X works.  Starting a client at the same time as
the server only adds to the confusion.

Perhaps the following could be added to startxwin.bat:

IF NOT EXIST %HOME%\.X_run_before START
http://x.cygwin.com/docs/ug/cygwin-x-ug.html
ECHO 1 > %HOME%\.X_run_before

Although I suspect the people who raise the questions are the very
same people who would close the browser without reading it :(

There would still be a problem with startx (unless cygwin's differs
from Unix's) since it stops X once we fall off the end of the xinitrc
script.  If running an external window manager, that's not a problem,
because that be the last client started.  If using the internal
multiwindow WM, there is no need to start a client, so the script
would exit after starting X and immediately shut it down again.

IIRC, there was talk a while back of making the multiwindow manager an
external client.  I don't know if anythng has been done in this
direction, but if this were done, there would at least be a consistent
startup for all WMs.

An alternative that I've not seen raised before: I was wondering if it
would be possible to run XWin as a Windows service (presumably via
cygserver).  The upside is that it would probably make more sense to
those coming to X from a Windows background.  The downside is that
there are so many different ways to start X (i.e. local/remote,
multiwindow/external WM etc.) that you'd still need to support the
traditional startup methods.  I know zip about the issues involved in
running as a Windows service, but if it's simple, it may be something
to consider, perhaps as a default installation.

As a sidenote, historically (IMHO), X startup has been a bit of a
mess.  A lot of old X servers were started by running X and a WM in
the background, then running xterm as a foreground task, just to
enable switching (or more likely restarting) window managers.  If they
inadvertently closed the initial xterm, the poor user was stuffed!  I
know - I was that user!

> Sorry. I won't make any move towards adding a hack into the startup
scripts.
> First thing people should do is fix their systems and remove the
crappy zone
> alarm and symantec antivirus programs. They cause the problems (at
least they
> did in all other cases which were reported over the last months). If
someone
> does not want to remove them, they should start debugging cygwin.dll
and find
> a solution to let the process startup work properly even with zone
alarm in
> place. Something I don't have time for.

No need to apologise - like I said, it WFM so I'm happy :-)

Finally, I've said it before, but it bears repeating: your efforts ARE
appreciated.  I've been getting the feeling lately from the jaded tone
of some of your replies to the list that perhaps you feel taken for
granted.  Not by me.  So thank you (and Kensuke et al too) for all
your good work.


Phil

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************


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