Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

ExpandVariables() in ShutdownPlugin() (v10 vs. v11)

May
12,845
164
If I put this code in ShutdownPlugin(), v10 crashes on exit and v11 does not (and the code works as intended).

Code:
    WCHAR szProfile[8192];
    Sprintf(szProfile, L"%%@REGQUERY[HKCU\\%s\\%s]", szTopKeyName, L"AutoSave");
    Printf(L"%s\r\n", szProfile);
    ExpandVariables(szProfile, 1);
    Printf(L"%s\r\n", szProfile);
v10: I see the first string, then "TCC has encountered a problem".

v11: I see both strings and it exits without a problem.

What's up?
 
Here's an easier one which, when put into ShutdownPlugin(), has the same effects:

Code:
WCHAR szFoo[8192] = L"%@REGQUERY[HKCU\\Console\\CodePage]";
ExpandVariables(szFoo, 1);
If I put this code in ShutdownPlugin(), v10 crashes on exit and v11 does not (and the code works as intended).

Code:
    WCHAR szProfile[8192];
    Sprintf(szProfile, L"%%@REGQUERY[HKCU\\%s\\%s]", szTopKeyName, L"AutoSave");
    Printf(L"%s\r\n", szProfile);
    ExpandVariables(szProfile, 1);
    Printf(L"%s\r\n", szProfile);
v10: I see the first string, then "TCC has encountered a problem".

v11: I see both strings and it exits without a problem.

What's up?
 
> Here's an easier one which, when put into ShutdownPlugin(), has the
> same effects:

ShutdownPlugin() is intended for the plugin to do any internal cleanup it
needs when TCC is exiting. It's highly unsafe to call back into TCC during
ShutdownPlugin(), as there's no guarantee that what you're looking for is
still going to exist.

(Also, the internal argument buffer sizes in ExpandVariables() changed
between v10 and v11).

Rex Conn
JP Software
 
ShutdownPlugin() is intended for the plugin to do any internal cleanup it
needs when TCC is exiting. It's highly unsafe to call back into TCC during
ShutdownPlugin(), as there's no guarantee that what you're looking for is
still going to exist.

Does that hold for any TakeCmd.dll export? When I tried AllocMem/FreeMem on plugininfo.pszFunctions in GetPluginInfo/ShutdownPlugin, instead of new/delete, I got crashes when I "X"d the console (but not if I just EXIT). FreeMem seems a likely candidate for use during cleanup.
 
----- Original Message -----
From: "vefatica" <>

> Does that hold for any TakeCmd.dll export? When I tried AllocMem/FreeMem
> on plugininfo.pszFunctions in GetPluginInfo/ShutdownPlugin, instead of
> new/delete, I got crashes when I "X"d the console (but not if I just
> EXIT). FreeMem seems a likely candidate for use during cleanup.

Isn't that unnecessary? Isn't the OS performing that cleanup automatically?
OTOH, if the plugin is shared between multiple TCC instances, and only one
of them is terminating, there may be such cleanup needed. I think that the
SDK should enumerate the features available during TCC termination...
--
Steve
 
On Sat, 29 May 2010 10:35:10 -0400, Steve Fábián <> wrote:

|---Quote---
|> Does that hold for any TakeCmd.dll export? When I tried AllocMem/FreeMem
|> on plugininfo.pszFunctions in GetPluginInfo/ShutdownPlugin, instead of
|> new/delete, I got crashes when I "X"d the console (but not if I just
|> EXIT). FreeMem seems a likely candidate for use during cleanup.
|---End Quote---
|Isn't that unnecessary? Isn't the OS performing that cleanup automatically?
|OTOH, if the plugin is shared between multiple TCC instances, and only one
|of them is terminating, there may be such cleanup needed.

ShutdownPlugin() is also called upon "PLUGIN /U". It seemed preferable (to
new/delete) to use TCCs allocate/free routines.

All my plugins that share data either share the data in a shared segment (which
doesn't have to be cleaned up) or only clean up if when there are no other
instances.
--
- Vince
 
> Does that hold for any TakeCmd.dll export? When I tried AllocMem/FreeMem
> on plugininfo.pszFunctions in GetPluginInfo/ShutdownPlugin, instead of
> new/delete, I got crashes when I "X"d the console (but not if I just
> EXIT). FreeMem seems a likely candidate for use during cleanup.

FreeMem is pointless, as Windows is going to clean that up anyway.

It holds for any TakeCmd.dll export, unless you can somehow guarantee that
TakeCmd.dll hasn't already been unloaded when your plugin is being unloaded.

Rex Conn
JP Software
 
On Sat, 29 May 2010 13:41:15 -0400, rconn <> wrote:

|It holds for any TakeCmd.dll export, unless you can somehow guarantee that
|TakeCmd.dll hasn't already been unloaded when your plugin is being unloaded.

How is it possible that TakeCmd.dll in not loaded when you call ShutdownPlugin?

Is it also possible that TakeCmd.dll is unloaded when you process TCEXIT?

Does TCC handle WM_SYSCOMMAND/SC_CLOSE differently from the way it handles
Exit_Cmd()?
--
- Vince
 
On Sat, 29 May 2010 13:41:14 -0400, rconn <> wrote:

|Features available during TCC termination = None.

Then I suppose a plugin, sensing a TCC shutdown, cannot put the CWD into the
dirhistory. I can do that in TCEXIT.

Are you planning to implement the oft-requested updating the dirhistory upon
entering a dir?
--
- Vince
 
> How is it possible that TakeCmd.dll in not loaded when you call
> ShutdownPlugin?

It's happening in TCC.EXE.


> Is it also possible that TakeCmd.dll is unloaded when you process TCEXIT?

No.


> Does TCC handle WM_SYSCOMMAND/SC_CLOSE differently from the way it handles
> Exit_Cmd()?

Yes.

Rex Conn
JP Software
 
>> Are you planning to implement the oft-requested updating the dirhistory
>> upon entering a dir?


> As I've mentioned before, it would mean a parser rewrite (and breaking a
> LOT
> of existing code) -- so, no.

By "breaking existing code", do you mean aliases and batch files, or
TCMD source code? If you mean the former, a very simple solution for
backward compatibility would be a new option or .INI directive, which
defults to the current operation, and would require each user to make the
option change manually before it would take effect. However, I cannot see
the circumstances when the change would break code.

BTW, another totally unrelated (but possibly repeat) suggestion for a
new feature is to provide a new option for the FUNCTION command to specify a
batch file to be executed that would return the function value.
--
Steve
 
On Sun, 30 May 2010 13:55:13 -0400, Steve Fábián <> wrote:

| BTW, another totally unrelated (but possibly repeat) suggestion for a
|new feature is to provide a new option for the FUNCTION command to specify a
|batch file to be executed that would return the function value.

Huh? Do you mean

FUNCTION myfunction `%@execstr[somefile.bat]`

or maybe

FUNCTION myfunction `%@exec[somefile.bat]`

That seems easy enough. Or am I missing the point?
--
- Vince
 
----- Original Message -----
From: "vefatica" <>
To: <[email protected]>
Sent: 2010. May 30., Sunday 14.11
Subject: RE: [Plugins-t-1996] Re: ExpandVariables() in ShutdownPlugin() (v10
vs. v11)



> On Sun, 30 May 2010 13:55:13 -0400, Steve Fábián <> wrote:
>
> | BTW, another totally unrelated (but possibly repeat) suggestion for a
> |new feature is to provide a new option for the FUNCTION command to
> specify a
> |batch file to be executed that would return the function value.
>
> Huh? Do you mean
>
> FUNCTION myfunction `%@execstr[somefile.bat]`
>
> or maybe
>
> FUNCTION myfunction `%@exec[somefile.bat]`
>
> That seems easy enough. Or am I missing the point?

Your assumption is valid, it is the manner in which I define such functions
currently (though I explicitly include the function parameters in the
definition). However, remember the warning below found in help topic
"f_execstr.htm": "@EXECSTR involves several extensive internal processing
stages". The purpose of the new feature is to eliminate as much as possible
of that additional processing. Ii's like @INC[...] - you don't need it, you
could use @EVAL[1+...].
--
Steve
 
On Sun, 30 May 2010 14:52:35 -0400, Steve Fábián <> wrote:

|---Quote---
|> Do you mean
|>
|> FUNCTION myfunction `%@execstr[somefile.bat]`
|>
|> or maybe
|>
|> FUNCTION myfunction `%@exec[somefile.bat]`
|>
|> That seems easy enough. Or am I missing the point?
|---End Quote---
|Your assumption is valid, it is the manner in which I define such functions
|currently (though I explicitly include the function parameters in the
|definition). However, remember the warning below found in help topic
|"f_execstr.htm": "@EXECSTR involves several extensive internal processing
|stages". The purpose of the new feature is to eliminate as much as possible
|of that additional processing. Ii's like @INC[...] - you don't need it, you
|could use @EVAL[1+...].

It seems it wouldn't eliminate much. The same things would have to be done ...
run the batch file and grab its output or return value (you'd have to somehow
specify which you wanted). If that could be done any better than @EXECSTR/@EXEC
already do it, I suppose we'd have a better @EXECSTR/@EXEC.
--
- Vince
 
Back
Top