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

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

Discussion in 'Plugins' started by vefatica, May 24, 2010.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,782
    Likes Received:
    29
    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?
     
  2. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,782
    Likes Received:
    29
    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);
     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    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
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,782
    Likes Received:
    29
    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.
     
  5. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    ----- Original Message -----
    From: "vefatica" <>

    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
     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,782
    Likes Received:
    29
    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
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    OK.

    Features available during TCC termination = None.

    Rex Conn
    JP Software
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    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
     
  9. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,782
    Likes Received:
    29
    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
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,782
    Likes Received:
    29
    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
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    As I've mentioned before, it would mean a parser rewrite (and breaking a LOT
    of existing code) -- so, no.

    Rex Conn
    JP Software
     
  12. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    It's happening in TCC.EXE.


    No.


    Yes.

    Rex Conn
    JP Software
     
  13. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4

    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
     
  14. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    Would elaborate, please!
    --
    Steve
     
  15. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,782
    Likes Received:
    29
    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
     
  16. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    ----- Original Message -----
    From: "vefatica" <>
    To: <ESFabian@comcast.net>
    Sent: 2010. May 30., Sunday 14.11
    Subject: RE: [Plugins-t-1996] Re: ExpandVariables() in ShutdownPlugin() (v10
    vs. v11)



    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
     
  17. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,782
    Likes Received:
    29
    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
     
  18. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    No. That's code that is internal to TCC and of no interest or concern to
    users. (And subject to radical change from version to version.)

    Rex Conn
    JP Software
     

Share This Page