• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

A question for Rex

#1
Rex, in several places I use TCCGlobals[44] as a test for whether there's a Ctrl-C or Ctrl-Break.

Code:
global.TCCGlobals = (LPBYTE) GetProcAddress(hTCDLL, "[email protected]@[email protected]@A");
It continues to work in all but one case, my WAIT plugin command. Here's the relevant code. Do you have any idea why it's not working here (that is, why I can't interrupt the while-loop below)? Is there something more I should be doing inside the loop so that TCC sees a Ctrl-C ot Ctrl-Break immediately? Thanks.

This code is called from the plugin command INT WINAPI WAIT ( WCHAR *psz ) which uses no signal handlers.
Code:
VOID WaitUntilPerfCountOrFileTime ( ULONGLONG ullDue, BOOL bWaitFileTime )
{
    typedef ULONGLONG ( *GETNOWTYPE ) (VOID);
 
    GETNOWTYPE GETNOW = bWaitFileTime ? CurrentFileTime : PerfCount;
 
    while ( GETNOW() < ullDue && global.TCCGlobals[44] == 0 )
    {
        Sleep(1);
        tty_yield(0);
    }
}
 

rconn

Administrator
Staff member
May 14, 2008
10,318
93
#2
Rex, in several places I use TCCGlobals[44] as a test for whether there's a Ctrl-C or Ctrl-Break.
Offset 44 is the "disable REXX output" flag, not the "^C detected" flag (48).

But that structure is subject to change with every version, and the offsets will vary depending on whether you're using the 32-bit or 64-bit version of takecmd.dll. I certainly wouldn't recommend (or support) trying to access it directly.
 
#3
Offset 44 is the "disable REXX output" flag, not the "^C detected" flag (48).

But that structure is subject to change with every version, and the offsets will vary depending on whether you're using the 32-bit or 64-bit version of takecmd.dll. I certainly wouldn't recommend (or support) trying to access it directly.
Yes, you warned me of that. Are you sure about that 48? It's odd that this works in both my GREPP and CRUNCH plugins:
Code:
while ( global.TCCGlobals[44] == 0 && ReadLine(...
That is, I can interrupt them.

Hmmm! The 48 does work in WAIT, where 44 wasn't working.

It's very convenient to rely on TCC's detecting ^C; The alternative is to install my own CtrlHandler everywhere I might want to interrupt something. Is there any change you'd document it? What is the offset in the 64-bit version?
 

rconn

Administrator
Staff member
May 14, 2008
10,318
93
#4
It's very convenient to rely on TCC's detecting ^C; The alternative is to install my own CtrlHandler everywhere I might want to interrupt something. Is there any change you'd document it? What is the offset in the 64-bit version?
No, there is no chance I'm going to document it -- then you'll be upset when it changes (as it will!) in 14.10, 14.50, 15.0, etc.

And IMO Plugins should not have the ability to demolish private TCC settings & crash TCC and Take Command. If you want to monitor ^C / ^Break, the only way to do it is to install your own CtrlHandler.
 
#5
No, there is no chance I'm going to document it -- then you'll be upset when it changes (as it will!) in 14.10, 14.50, 15.0, etc.

And IMO Plugins should not have the ability to demolish private TCC settings & crash TCC and Take Command. If you want to monitor ^C / ^Break, the only way to do it is to install your own CtrlHandler.
OK, so I'll stop relying on it. But there's one thing I have long wondered. If I set my own CtrlHandler, and it sets a (file scope) BOOL to tell a loop to terminate and then returns FALSE, is it possible that TCC, on getting the signal, will somehow kill my plugin function before it has a chance to remove the CtrlHandler? I have also wondered if a CtrlHandler can remove itself.
 
Top Bottom