A question for Rex

[vefatica]

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

global.TCCGlobals = (LPBYTE) GetProcAddress(hTCDLL, "?aGlobals@@3UGLOBAL_VARIABLES@@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.

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]

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.

 

[vefatica]

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:

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]

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.

 

[vefatica]

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.

 

[rconn]

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:

I'm absolutely certain about offset 48 with v14. Other versions will vary.