Made tests for clock frequency more permissive to cope with Win98SE being

observed to return 1.19318 in place of 1.193182 MHz as the performance
counter frequency.

2 files changed, 23 insertions, 5 deletions

diff --git a/ChangeLog b/ChangeLog
index ae2d307..b413b57 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2002-04-01  Kevin Kenny  <kennykb@acm.org>
+
+	* win/tclWinTime.c (Tcl_GetTime): made the checks of clock
+	frequency more permissive to cope with the fact that Win98SE
+	is observed to return 1.19318 in place of 1.193182 for the
+	performance counter frequency.
+	
 2002-03-29  Jeff Hobbs  <jeffh@ActiveState.com>
 
 	* generic/tclCmdMZ.c (Tcl_TraceObjCmd, TraceVarProc)
diff --git a/win/tclWinTime.c b/win/tclWinTime.c
index d90e8ba..d0aa9ec 100644
--- a/win/tclWinTime.c
+++ b/win/tclWinTime.c
@@ -9,7 +9,7 @@
  * See the file "license.terms" for information on usage and redistribution
  * of this file, and for a DISCLAIMER OF ALL WARRANTIES.
  *
- * RCS: @(#) $Id: tclWinTime.c,v 1.9 2001/11/21 02:36:21 hobbs Exp $
+ * RCS: @(#) $Id: tclWinTime.c,v 1.10 2002/04/01 20:44:36 kennykb Exp $
  */
 
 #include "tclWinInt.h"
@@ -254,17 +254,28 @@ Tcl_GetTime(timePtr)
 	     *    - unpredictable changes in performance counter frequency
 	     *      on "gearshift" processors such as Transmeta and
 	     *      SpeedStep.
+	     *
 	     * There seems to be no way to test whether the performance
 	     * counter is reliable, but a useful heuristic is that
 	     * if its frequency is 1.193182 MHz or 3.579545 MHz, it's
 	     * derived from a colorburst crystal and is therefore
-	     * the RTC rather than the TSC.  If it's anything else, we
-	     * presume that the performance counter is unreliable.
+	     * the RTC rather than the TSC.
+	     *
+	     * A sloppier but serviceable heuristic is that the RTC crystal
+	     * is normally less than 15 MHz while the TSC crystal is
+	     * virtually assured to be greater than 100 MHz.  Since Win98SE
+	     * appears to fiddle with the definition of the perf counter
+	     * frequency (perhaps in an attempt to calibrate the clock?)
+	     * we use the latter rule rather than an exact match.
 	     */
 
 	    if ( timeInfo.perfCounterAvailable
-		 && timeInfo.curCounterFreq.QuadPart != (LONGLONG) 1193182
-		 && timeInfo.curCounterFreq.QuadPart != (LONGLONG) 3579545 ) {
+		 /* The following lines would do an exact match on
+		  * crystal frequency:
+		  * && timeInfo.curCounterFreq.QuadPart != (LONGLONG) 1193182
+		  * && timeInfo.curCounterFreq.QuadPart != (LONGLONG) 3579545
+		  */
+		 && timeInfo.curCounterFreq.QuadPart > (LONGLONG) 15000000 ) {
 		timeInfo.perfCounterAvailable = FALSE;
 	    }