X-Spam-Check-By: sourceware.org
Message-ID: <444BE7F2.6060209@cwilson.fastmail.fm>
Date: Sun, 23 Apr 2006 16:47:46 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Support for older OS's
References: <1145646573 DOT 7213 DOT 259631146 AT webmail DOT messagingengine DOT com> <20060421204231 DOT GB27541 AT calimero DOT vinschen DOT 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 AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT 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/