Win7 32bit incompatibilities with VS6 and VB6

My VB6/Vc++ application uses the built in timer object. The VB app communicates back and forth with the C++ app at specific times. This was not an issue with previous versions of Windows, with migration to Win7 now it seems that the timing is no longer synchronized and the C++ process hangs up.
On previous versions of Windows I found that on multi-core or multi-processor computers I had to disable processors and cores until it looked like a single core, single processor computer. I think I got that accomplished on this Win7 machine, in task manager/Performance there is only one graph displayed for CPU usage. Previously there were 4. Is there a compatibility issue with the timer? and is there a fix???

Thank You.

The timer has never been all that accurate. If the timing is important to your program then the issue may be more in the way it uses the timer rather than the timer itself.

Having to disable the cores on a multicore processor seems like a very bad thing to do.

Perhaps you should consider using a VM with XP loaded into it. Windows 7 pro allows you to download and use what they call XPMode which is a Windows VM preloaded with XP SP3

Quote:

---

Originally Posted by DataMiser

The timer has never been all that accurate. If the timing is important to your program then the issue may be more in the way it uses the timer rather than the timer itself.

Having to disable the cores on a multicore processor seems like a very bad thing to do.

Perhaps you should consider using a VM with XP loaded into it. Windows 7 pro allows you to download and use what they call XPMode which is a Windows VM preloaded with XP SP3

---

My issue with the multiple cores is that each one uses a different time reference. So as the OS bounces processes around from core to core the process is being told that it is a different time then it saw 5msec ago. Its a problem for critical functions that need to fire off at a specific time. At 4am a process starts, then is bounced to another core where it is not yet 4am (albeit a tiny bit less) so the process starts again and the two compete for resources. Or worse yet, immediately prior to the 4am start, the process is bounced to a core where the time is after 4am, thus the needed action at 4am never occurs. This is the only thing running on this stand alone machine, except for all the junk that windows does in the background.

Microsoft recommends using QueryPerformanceCounter for consistent timing across cores. Or if you're timing somthing like 4am, you can use GetSystemTimePreciseAsFileTime

If I were you I would use GetTickCount().

It's execution is fast, and it reads a single memory location, and it's consistent.
Especially since it doesn't seem like you need accuracy, just consistency.
Being that it reads a memory location - it will be the same across cores.

Timer controls are not for "timing" anything. There are designed to let you get off the UI thread and then run some code on it again after an interval has elapsed.

From the original question it sounds like this was being used as some sort of loose synchronization scheme involving periodic polling.

Quote:

---

Originally Posted by DEXWERX

If I were you I would use GetTickCount().

It's execution is fast, and it reads a single memory location, and it's consistent.
Especially since it doesn't seem like you need accuracy, just consistency.
Being that it reads a memory location - it will be the same across cores.

---

And since the OP has left XP behind as it seems - there's even the GetTickCount64() API
(which doesn't "overflow" after 49 days anymore)...
https://msdn.microsoft.com/de-de/lib...=vs.85%29.aspx

Here's the needed Declare (along with some Wrapper-Functions and Test-Code):

Code:

---

Option Explicit

Private Declare Function GetTickCount64 Lib "kernel32" () As Currency 'available since Vista...
 
Private WithEvents tmrOneSecondInterval As VB.Timer 'just to check the two wrapper-functions...

Private Sub Form_Load()
Set tmrOneSecondInterval = Controls.Add("VB.Timer", "tmrOneSecondInterval")
    tmrOneSecondInterval.Interval = 1000
End Sub
Private Sub tmrOneSecondInterval_Timer()
  Debug.Print GetTicks64, GetTicks64Seconds
End Sub

Public Function GetTicks64Seconds() As Double
  GetTicks64Seconds = CDbl(GetTickCount64 * 10)
End Function
Public Function GetTicks64() As Currency
  GetTicks64 = GetTickCount64 * 10000
End Function

---

Olaf

Quote:

---

Originally Posted by Schmidt

And since the OP has left XP behind as it seems - there's even the GetTickCount64() API
(which doesn't "overflow" after 49 days anymore)...

---

I am running 32bit Win7 Is there a 32 bit version of GetTickCount64()

Quote:

---

Originally Posted by roxydogg

I am running 32bit Win7 Is there a 32 bit version of GetTickCount64()

---

Ermm... did you try out the Demo-Code in a new Form on your Win7-machine?
(no Controls needed, just Copy&Paste ... and then run it, looking at the output in the Immediate-Window).

The point being... the naming of that specific API-call has nothing to do with the "BitNess" of the OS,
but everything to do with the length of the returned Integer... ;)

So, as long as you are using a Win-System from Vista onwards, you are fine...

Olaf

Quote:

---

Originally Posted by Schmidt

Ermm... did you try out the Demo-Code in a new Form on your Win7-machine?
(no Controls needed, just Copy&Paste ... and then run it, looking at the output in the Immediate-Window).

The point being... the naming of that specific API-call has nothing to do with the "BitNess" of the OS,
but everything to do with the length of the returned Integer... ;)

So, as long as you are using a Win-System from Vista onwards, you are fine...

Olaf

---

So if I base my timing on this returned tick count, what happens as the frequency agile processor adjusts processor speeds up and down, the number of tick counts per specific time period will vary based on whatever the processor has adjusted its speed to at that moment in time.
Do I need to turn off this frequency self adjustment feature?

I didn't have the Immediate window visible duh....... ok I get two columns of numbers. I am not sure what each column represents. The screen appears to update every second, is that correct? the left column GetTicks64 the right colum GetTicks64Seconds

Quote:

---

Originally Posted by roxydogg

So if I base my timing on this returned tick count, what happens as the frequency agile processor adjusts processor speeds up and down, the number of tick counts per specific time period will vary based on whatever the processor has adjusted its speed to at that moment in time.
Do I need to turn off this frequency self adjustment feature?

---

No, the GetTickCount64-API is safe in this regard (whereas QueryPerformanceCounter-based stuff
had problems with what you just mentioned... at least in the past)

Although working with a much higher resolution, the QPC-API was quite unreliable at least in the XP-era...
I've experienced that myself... on some MotherBoards - with certain CPUs (at the time when dynamic Over-
and Underclocking was introduced) there were quite some surprises lurking...

This time around the QPC-API is more reliable again (due to special timer-chips on the MBs,
which don't rely on the CPU-Clock(s)) - so, when the lower (typically 12-15msec) resolution of GetTickCount
or GetTickCount64 is not a K.O.-criterion - I'd prefer and choose these APIs, just to be on the safe side...

Olaf

Quote:

---

Originally Posted by roxydogg

I didn't have the Immediate window visible duh....... ok I get two columns of numbers. I am not sure what each column represents. The screen appears to update every second, is that correct? the left column GetTicks64 the right colum GetTicks64Seconds

---

Yes, that's how it should be - the TickCount64-Values are read every second (triggered by a normal,
dynamically added VB.Timer-Control) - so the "right Column" of your immediate-window-output
should increase "by 1" roughly any second (at every TimerControl-tick).

The left-hand value is in milliseconds - and thus compatible to the old GetTickCount()-function...
It just will not overflow anymore (in your lifetime).

Olaf

The values in the two columns are increasing. Is this tick count the number of ticks from when I started the vb app? Or is this the number of ticks in the desired interval set in form_load to 1000 which I assume is 1000 msec?

Quote:

---

Originally Posted by roxydogg

The values in the two columns are increasing. Is this tick count the number of ticks from when I started the vb app?

---

In my first post in this thread, I've included a Link to the MSDN-Docu for GetTickCount64.

And the first sentence is:

GetTickCount64 function


Retrieves the number of milliseconds that have elapsed since the system was started. ;)


Olaf

It produces a very consistent number of ticks from interval to interval. Thank you for the help. Did you say that it uses a discrete clock chip on the motherboard?

Yes, the GetTickCount/GetTickCount64-APIs are using the Clock-Chip (lower resolution, but very reliable and with great "long-term accuracy").

It's also explained (in more detail) in the first answer here on stack-overflow:
http://stackoverflow.com/questions/2...t-keep-in-pace
(he's also mentioning the problems with QPC-APIs, which depend in their reliability very much on hardware-implementations).

As said - GetTickCount is safe to use - and you can measure especially long intervals (up to weeks)
with good accuracy (they use the Real-Time-ClockChips on the motherboards).

Olaf

No, they do not use "the clock chip."

These are ticks counted based on interrupts raised by a programmable interval timer controlled by Windows.

https://blogs.msdn.microsoft.com/old...13-00/?p=43623

Quote:

---

If your goal is to measure operating system boot time from the application of power to the computer, then Get*Tick*Count is not going to be useful. After all, Windows isn't even running at the moment you apply power to the computer. The BIOS does its work without any operating system all, so Windows has no idea how long the BIOS took to POST. The text in MSDN could be a bit more explicit and say "elapsed since Windows started", or it could be pointlessly nitpicky and say "elapsed since the Windows HAL initialized the programmable interval timer."

---

That in turn is driven by the system logic clock, which may or not be accurate, but the frequency is high enough it doesn't matter that much most of the time.

Also see Raymond's Precision is not the same as accuracy.

Quote:

---

Originally Posted by dilettante

No, they do not use "the clock chip."

---

Why are you trying to confuse the OP?

That there's "a layer of hardware-abstraction" involved (to deliver
these values in a good performance) should be obvious.

The GetTickCount-APIs are definitely synchronous with the RealTime-Clock-Chip
of the System.

And when Raymond Chen talks about "boot time from the application of power to the computer",
then this is of course different from the "System-Startup-Time" (which for me is the
point of initialization of the *Operating System* - not that of "The Machine"...

Olaf

Quote:

---

Originally Posted by Schmidt

Why are you trying to confuse the OP?

---

Me? I was just correcting the erroneous information you gave him. GetTickCount() has nothing to do with the RTC.

Quote:

---

Originally Posted by dilettante

GetTickCount() has nothing to do with the RTC.

---

You are wrong, I've posted correct information!

GetTickCount is absolutely bound to the Clock-*Chip* (its Interval-Interrupts), which
you can easily test yourself, when you forbid a certain machine to Update its Clock-*Value*.

If you disable NTP-Online-Updates, DayLight-Saving-Updates or manual
Updates of the Clock-*Value*, then GetTickCount will happily display the
absolute same Difference (no matter how long this machine is up) as:
? VBA.Now()-SytemStartupTimeStamp
(the right part of the above expression can be read out e.g. per WMI)

Olaf

Quote:

---

Originally Posted by dilettante

Me? I was just correcting the erroneous information you gave him. GetTickCount() has nothing to do with the RTC.

---

C'mon dil... you're not even being pedantic, you're just being erroneous.