[fpc-pascal] The unfortunate deprecation of GetTickCount

[Alexander Grotewohl]

Just to be clear, the 64 in GetTickCount64 has nothing to do with 
whether a machine is 32bit or 64bit.

Alex


On 04/11/2018 01:23 PM, Karoly Balogh (Charlie/SGR) wrote:
> Hi,
>
> On Wed, 11 Apr 2018, Michael Van Canneyt wrote:
>
>>>> personally I use this 64 bit emulation:
>>> For my purpose I'm perfectly happy with GetTickCount. I'd understand the
>>> deprecation if GetTickCount64 would be a reliable substitute. It isn't.
>> Only on XP. On all other platforms, it is the better solution.
> Actually... I kinda disklike this depreciation too. Better is just such a
> bad word for software engineering. (Almost) everything has its purpose.
>
> GetTickCount is clearly a Windows API function, does not directly exist in
> Delphi itself, so this is an FPC addition to the Sysutils unit for
> Delphi-compatible platform idependence - and to my knowledge, Microsoft
> did not deprecate the 32bit variant, instead it documented that it rolls
> over after 49.7 days, which we could also do just fine.
>
> Especially because extending the result to 64bit is *NOT* the only way to
> get around the 32bit overflow problem of a timer, and for a lot of
> purposes it's perfectly fine, especially on 32bit systems, which are still
> numerous.
>
> Which means, the workaround for the deprecation message on Windows is
> actually using the GetTickCount from Windows unit directly, which is
> supported everywhere and even Delphi compatible (no GetTickCount/64 in
> sysutils there, according to the docs I can find, but fix me?).
>
> BTW, for additional fun, the Windows RTL system unit itself still uses
> the 32bit Windows API GetTickCount to initialize its RandSeed...
>
> Charlie
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal