[Mono-devel-list] [PATCH] Bug Fix for GetTickCount in WAPI IO Layer

[Jesse Towner]

Ben Maurer wrote:

>>Yes, sure. I can do that. However, I'm a little unsure if I should
>>bother with all of these changes if they're not going to be committed
>>anyway. I know of at least a few people who have mistakenly used
>>System.Environment.TickCount and complained it didn't work the
>>way they expected it to on Mono. That's why I set out to see if I
>>could fix it in the first place.
>>
>>
>
>What applications are doing this? They should be aware that their program
>*does not work* on the msft platform or on mono. It will start giving
>bogus results after 23-24 days or something (the .net version has half the
>resolution of the native one, because it is signed and we do not use the
>negative bits).
>
>We should document this in monodoc. Also, if this method is in the ECMA
>spec, it would be nice to get a warning measured there.
>
>-- Ben
>
>
>
I don't believe these applications are of a critical nature (I hope).
It's documented in the CLI
and MSDN references that System.Environment.TickCount wraps over to
Int32.MinValue
after 24.8 days, and then starts increasing in value for the next 24.8
days. Even so, some
people insist on using it. Just do a google search for "C# TickCount
system uptime" to see
what I mean (note this returns both correct and incorrect examples).

The correct way to determine the system uptime with the MSFT .NET FX
libraries is to use
System.Diagnostics.PerformanceCounter:

<code>
PerformanceCounter pc = new PerformanceCounter("System", "System Up Time");

*pc.NextValue(); *

*TimeSpan uptime = TimeSpan.FromSeconds(pc.NextValue());*

</code>

However, this is not a CLI library feature, and I'm not sure if it's
supported in Mono.

Anyway, as to the philosophy of implementing something so that it works
in a particular
scenario, even though it shouldn't be used there, I offer the following.

I used to work on hardware simulation software (and known sometimes as
emulators, although
the correct terminology is simulator). Sometimes, we'd come across a
program that used
an undocumented feature of the hardware we were simulating. Or sometimes
it would use
a feature in such a way that was dangerous. If our implementation of the
simulator deviated
only slightly from the real system's behavior, it would break these
programs.

Now, not to say Mono "simulates" the MSFT .NET FX, it's a CLI
implementation. And the
CLI class library documentation does say that
System.Environment.TickCount returns the
number of milliseconds since the system booted.

It's possible to envision a windows service or daemon that uses
System.Environment.TickCount
when it is first activated a boot-time, and then subsequently polls it
to determine the system
uptime, detecting any 32-bit integer wrap-arounds and accounting for
them. In fact, such code
exists out there:  http://www.thecodeproject.com/useritems/UpTime.asp

------------------------------------------------------------------------
Jesse Towner, Lead Programmer, Hybrid Mobile Technologies, LLC
Email Addresses: <jtowner at hybrid-mobile.com>, <townerj at gmail.com>
PGP Public Key: http://www.virtuallyonline.net/personal/jesse/pgp.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050228/8717d99d/attachment.bin