X-Spam-Check-By: sourceware.org Message-ID: <444BEA07.5090704@gmail.com> Date: Mon, 24 Apr 2006 03:56:39 +0700 From: "Alexander J. Herrmann" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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> <444BE7F2 DOT 6060209 AT cwilson DOT fastmail DOT fm> In-Reply-To: <444BE7F2.6060209@cwilson.fastmail.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Charles Wilson wrote: > 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. Sleep(n) big 'S' makes n second delays (Windoze) while sleep(n) make n millisecond delays and beside this you got usleep on some systems. > > 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/ > > -- And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer. Alexander J. Herrmann Analyst/Programmer http://www.aiengine.org Email: Ping2Weltall AT Gmail DOT com -- 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/