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/
