xsharp.eu

Hi Wolfgang

on my laptop runs win8.1(64-Bit) and in vmware machines win7(32 Bit) and win10(64-Bit).

GetTickcountlow() works correctly under win7, but already Win8.1 returns the same value as win10 does: 4294967295 ( MAX_DWORD == 0xFFFFFFFF ). What i don´t understand: what is the VO runtime func GetTickCountLow() good for, when it works (at least) in Win < 8 the same way as the WinApi GetTickCount() does ? BTW. To overcome the GettickcOunt() limit, GetTickCount64() can be used:

_DLL FUNCTION GetTickCount64() AS _winULARGE_INTEGER PASCAL:Kernel32.GetTickCount64

regards
Karl-Heinz

Or you use

GetQueryPerformanceCounter(@start_high,@start_low)


see the attachment

Hi Dick,

Dick wrote: Considerable faster startup & shut down times and a few small improvements

I am very surprised you bought into that
If you don't completely shut down but instead sort of hibernate, like W10 does, every windows version is as fast or faster on opening/closing than what W10 is

Chris

Hi Karl-Heinz,

I'm preferring VO runtime functions to Windows API functions, and even when I need a Windows API function in one of my applications, I try to encapsulate it in a VO function or class method to be able to change it in the case it becomes outdated or a better implementation is available. And now, when migrating to X#, it makes it easier to migrate.

Wolfgang

Hello Chris,

I have 2 reasons not to hibernate:

1 I'm extremely energy conscious. I try to switch everything off which isn't needed, including the many stand-by functions, Pc hibernation and also internet access.
2 For customers we really have to restart servers once every few weeks because they have become very slow, or erratic. I believe not restarting a Pc gives the same problem.

So when I start my Pc, Windows 10 is there well within 30- seconds, internet access within a minute. The W10 startup time is considerably faster than that of W7 so for me it's one of the (few) W10 advantages.

Dick

Hi Dick,
in many parts you are right. But we have to admit that the times of the desktop computers as the main IT instrument have finished. And we are tight to the Microsoft Windows X86 world. So we can be glad if Microsoft modernizes that world and that most of our program code is still working. So I don't want always to complain about changes in Windows versions. Instead using Windows 10 and installing the latest patches we get impressions what future versions will bring us.
Arne

Wolfgang Riedmann wrote:Hi Karl-Heinz,

I'm preferring VO runtime functions to Windows API functions, and even when I need a Windows API function in one of my applications, I try to encapsulate it in a VO function
Wolfgang

Hi Wolfgang,

so, why not override the VO-Func ?

FUNCTION GetTickCountLow() AS DWORD PASCAL
RETURN GetTickCount()

BTW. i´m still wondering what GetTickcountLow() does internally. Take a look at the nummbers shown in the attached counter.jpg ... It shows - after a restart - the GetTicketCount64(),GetTicketCountLow() and GetTickcount() values.

Can anybody confirm this with the attached Counter.aef ?

regards
Karl-Heinz

Karl-Heinz,
imported in 2838, shows similiar numbers like your jpg. -Low seems to add at every call simply digit 0-9 to the result...

HAND
Karl

Hi Karl-Heinz, hi Karl,

I can confirm both of your findings.

Of course the use of the GetTickCount64() function solves any problems, but I don't plan to enhance my VO code very much - I hope to move it over to X# in the next few years.

Wolfgang

Karl Faller wrote:Karl-Heinz,
imported in 2838, shows similiar numbers like your jpg. -Low seems to add at every call simply digit 0-9 to the result...

HAND
Karl

Hi Karl,

and making a number larger ensures that the MAXDWORD limit is reached earlier . Interesting also: The GetTickCOuntLow() doc mentions to divide the Result with 10000, while the winapi GetTickCOunt() result must be divided by 1000 to receive the elapsed seconds.

67227651 / 10000 -> 6722
6722765 / 1000 -> 6722

From that point of view GetTickCOuntLow() even makes sense, somehow . Ok, i give up. If Wolfgang wouldn´t have mentioned it, i would never have noticed that this strange func exists at all in the VO runtime.

regards
Karl-Heinz