Message-ID: <444BE7F2.6060209@cwilson.fastmail.fm>
Date: Sun, 23 Apr 2006 16:47:46 -0400
From: Charles Wilson <cygwin@cwilson.fastmail.fm>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: Support for older OS's
References: <1145646573.7213.259631146@webmail.messagingengine.com> <20060421204231.GB27541@calimero.vinschen.de>
In-Reply-To: <20060421204231.GB27541@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Corinna Vinschen wrote:
> On Apr 21 15:09, Charles Wilson wrote:
>> 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
> 
> Think along the lines of "it's the OSes fault, not mine", and you'll
> feel better immediately.
> 
>> Sleep(40)!!
>   ^^^^^^^^^
> 
>> 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
> 
> Wouldn't that be a 40 *milli*second delay?

Yes, you are correct.  You know, I had actually tested this (by 
inverting the test on whether LoadLibary/GetProcAddress found the 
GetConsoleWindow() function) on my winXP box.

And it hung -- not for 40 milliseconds or 40 seconds but forever.  I 
assumed it was because I was on winXP and really OUGHT to be using 
GetConsoleWindow(), and that the code, which obviously worked in 
cygserver, would also work fine on win98. And that those users would 
have to live with a 40 second delay.

But that was before I had fixed another problem -- which was the real 
cause of the lockup on my box.

So, I (a) looked at the msdn docs, and (b) performed my test again -- 
and sure enough, 40 milliseconds.  Don't I feel silly.

Again.  This is getting to be a habit.

So...it looks like hide_console() is a winner.  You still get a brief 
flashing cmd window -- but 'regular' rxvt even with the hide_console 
addition works okay with run.exe (and no flash), so there's no 
operational change for current users who are using rxvt in the currently 
expected ways.  This just adds a new capability useful with external 
scripting.

I'll petition to take over rxvt maintainership soon -- but work is 
kicking my tail right this instant, so expect a short delay.

--
Chuck

P.S. thanks also to cgf for pointing out my misinterpretation of 
Sleep().  I'm quite happy to be wrong...

--
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/