Mail Archives: cygwin/2006/04/21/15:10:25
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/
- Raw text -