winmm: Remove timeGetTime.

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

Maarten recently mapped winmm:timeGetTime to kernel32.GetTickCount
This rang a bell and now I found again the article where I read about it:

http://blogs.msdn.com/larryosterman/archive/2009/09/02/what-s-the-difference-between-gettickcount-and-timegettime.aspx

"So why are all these multimedia APIs using timeGetTime and not GetTickCount
since the two APIs apparently return the same value? ...
The answer is that they don’t."

I cannot judge whether what's described there applies to Wine's timing.
However the listed timings prove both values are different.

FWIW, I've determined long ago that timer increments in MS suffer
from a 15.625ms granularity.  This affects almost all applications
in MS-Windows.  For instance, JMeter(Java) always returns times that
are multiple of this value, plus/minus rounding.  It will tell you
jobs took 15, 16, 31, 32, 46 or 47ms etc.  Never 5, 12, 26 or 30ms!
You can't use it to time short jobs.
I've seen the same values in many other apps (not just Java) and
several versions of MS-Windows.
Heck, 46 and 47ms are even shown in the above URL in the dTicks column
(as well as the next pair: 62 and 63ms).

Whatever you measure, you'll encounter this 15.625ms increment.
Presumably, the high performance counters are not affected.  But
few apps seem to use these.

What's 15.625ms?  Exactly 64 ticks per second
... and the linearisation of all returned values.

If you GetTickCount something that truly takes 29ms multiple times,
you'll observe 31/32 deltas much more often than 15/16. (As the article
says: "note that the deltas average to 55ms").

Regards,
 Jörg Höhle