Message-Id: <1145646573.7213.259631146@webmail.messagingengine.com>
From: "Charles Wilson" <cygwin AT cwilson DOT fastmail DOT fm>
To: cygwin AT cygwin DOT com
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
Subject: Support for older OS's
Date: Fri, 21 Apr 2006 15:09:33 -0400
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Corinna said [in thread entitled "Windows 95 support ?"]
> Just the setup tool has some problem, apparently. Cygwin still runs on 95, which will probably change at one point, since it's getting incredibly awkward to support it.

I've a related question: how "pleasant" must the user experience be on
older operating systems? Specifically, my [still in ITP state] port of
rxvt-unicode-X has the nifty feature that it "knows" how to hide its own
console window without the use of run.  While this leads to a briefly
flashing cmd window (and run.exe does not) I consider that an acceptable
tradeoff given that rxvt-unicode-X will suck 100% CPU if both (a)
launched by run.exe and (b) starts the shell as a loginshell.  So,
avoiding the need for run.exe -- at least until the reasons behind the
odd behavior are found/fixed -- is a good idea.

Downside: this console-hiding code, taken from inetd/cygrunsrv
http://sources.redhat.com/cgi-bin/cvsweb.cgi/cygrunsrv/cygrunsrv.cc.diff?cvsroot=cygwin-apps&r1=1.22&r2=1.23
uses an API only available in W2K and newer.  On other systems (NT,
95/98/Me) it falls back to code from KB Q124103 which involves
Sleep(40)!!

For long-running services like inetd etc, that's okay.  For interactive
processes, not so much.  I tried putting the alternative code in a
separate thread, so at least the W98 user could go on with the rxvt-X
session while the background thread *eventually* would hide the extra
console -- but I couldn't figure out how to do Sleep(40) in a thread
without hanging. (And sigalrm won't work, either -- as signals are only
delivered to the main thread AFAIK).  So at present, on old OS's,
rxvt-unicode-X has a 40 second startup delay.  Ick.

Now, even if rxvt-unicode-X has this misfeature on old OS, those users
could always just use the existing rxvt in X-mode with run.exe, right? 
Sure...but

IF you want to have a batch script which uses checkX to figure out if X
is running (and DISPLAY is set) and launch either [ rxvt (in non-X mode)
| (ITP) rxvt-W11 | (Future) rxvt-unicode-W11 ] or [rxvt (in X mode) |
(ITP) rxvt-unicode-X ] as appropriate, then you WILL get a console.  It
can't be hidden by later using run.exe to lauch the ultimate target. 
Instead, the ultimate target needs to after-the-fact forcibly hide the
console.

So, I've a version of the existing rxvt (dual mode WinGUI / XGUI) which
does the hide_console magic.  I even have shell scripts and batch files
which switch intelligently between this new version of rxvt (when you
want WinGUI) and rxvt-unicode-X (for X mode).  A few flashes, but it's a
workable replacement for the current,
use-old-rxvt-plus-run.exe-for-both-modes system.  On WinXP.

It would also work on older OS's -- but every invocation would incur a
40 second delay.  Which is really *mean*.  I'm not sure I'm ready for
that level of meanness, which is why I haven't proposed taking over the
existing rxvt maintainership and uploading my version.

----
Perhaps the "correct" response is to use a custom launcher EXE that is
very simple and less flexible than run.exe -- one that only knows how to
launch one of two targets, based on the result of a third external
target...but then I'd still see the 100% CPU problem described above. 
Double Ick.

Any suggestions?  (Heck, I even considered using a WSH script -- which
doesn't create a console -- to launch the targets with no need to
hide_console.  But wscript.exe itself is only available on newer OS, so
no joy there)

--
Chuck
--
  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/