By registering with us, you'll be able to discuss, share and private message with other members of our community.
SignUp Now!ULONGLONG TickCount64()
{
ULONGLONG ullPerfCount;
QueryPerformanceCounter((LARGE_INTEGER*) &ullPerfCount);
return ullPerfCount / (global.ullPerfFreq / 1000); // ms
}
This sort of routine works great in v11.
In v12.10, SysWait(0,2) never returns.Code:VOID WaitUntilTickCount64 ( ULONGLONG ullTickCountDue ) { while ( TickCount64() < ullTickCountDue ) { SysWait(0,2); } }
This sort of routine works great in v11.
Code:VOID WaitUntilTickCount64 ( ULONGLONG ullTickCountDue ) { while ( TickCount64() < ullTickCountDue ) { SysWait(0,2); } }
In v12.10, SysWait(0,2) never returns.
(or> vefatica <>
> 03/25/2011 02:52 PM
>
> I wasn't finished with that last post. In v12.10 SysWait(0,2)
it.> any number of milliseconds) never returns, regardless of how I use
>
> And if I change that to SysWait(1,0) in the WaitUntilTickCount64()
> function below, then, after 2 or 3 times through the loop, I get an
ms> access violation. FWIW, I get TickCount64() like this:
>
>
> Code:
> ---------
> ULONGLONG TickCount64()
> {
> ULONGLONG ullPerfCount;
> QueryPerformanceCounter((LARGE_INTEGER*) &ullPerfCount);
> return ullPerfCount / (global.ullPerfFreq / 1000); //
> }
> ---------
>
>
> ---Quote (Originally by vefatica)---
> This sort of routine works great in v11.
>
>
> Code:
> ---------
> VOID WaitUntilTickCount64 ( ULONGLONG ullTickCountDue )
> {
> while ( TickCount64() < ullTickCountDue )
> {
> SysWait(0,2);
> }
> }
> ---------
> In v12.10, SysWait(0,2) never returns.
> ---End Quote---
>
>
>
typedef VOID *(WINAPI *SYSWAITTYPE)(ULONGLONG, INT);
HMODULE hTC = GetModuleHandle(L"TakeCmd.DLL");
syswait = (SYSWAITTYPE) GetProcAddress(hTC, "SysWait");
On Fri, 25 Mar 2011 16:29:35 -0400, you wrote:
||(And SysWait for 1 or 2 milliseconds is never going to work, because it will sleep more than that before doing the check.)
Sleep() has the same granularity problems (~10ms or ~16ms) doesn't it?
In another recent post, samintz said he gets signal handling when he loops
arounf Sleep() and tty_yield(0). I don't. ... ???
VOID WaitUntilTickCount64 ( ULONGLONG ullTickCountDue )
{
while ( TickCount64() < ullTickCountDue )
{
Sleep(1);
tty_yield(0);
}
}
My point was that **I** must add a ConsoleCtrlHandler if I want to interrupt
this loop:
Code:VOID WaitUntilTickCount64 ( ULONGLONG ullTickCountDue ) { while ( TickCount64() < ullTickCountDue ) { Sleep(1); tty_yield(0); } }
while SysWait() (apparently) adds one for me. Isn't that correct?
> That's really odd since I get one with SysWait() and I don't with
> {Sleep(1);
> tty_yield(0);}.
VOID WaitUntilTickCount64 ( ULONGLONG ullDue )
{
while ( TickCount64() < ullDue && bContinue )
{
Sleep(1);
tty_yield(0);
}
bContinue = TRUE;
SetConsoleCtrlHandler(WaitCtrlHandler, FALSE);
}
How would you do it in a plugin?
I wouldn't do it that way (which will mangle the existing handler, fail to execute any ON BREAK statements, and fail to shut down hooks).
TCC already has a handler running, which sets aGlobals.fBreak to 1 whenever a ^C or ^Break is entered -- just check for that in your loop.
?aGlobals@@3UGLOBAL_VARIABLES@@A
there. What's> Is it correct that fBreak is at byte offset 44? Is it likely to stay
> its type? [Actually, just testing the byte works.]
The aGlobals structure changes in every new version, but (not 100% guaranteed!) new fields are added to the end.
The aGlobals structure changes in every new version, but (not 100% guaranteed!) new fields are added to the end.
Is this stuff documented somewhere, and I'm just to stupid to find/recognize it? Are there other useful variables in aGlobals? Or is this the kind of private internal stuff that it would be catastrophically dumb to rely upon?