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

Fixed Plugins with TCMD 14

Discussion in 'Support' started by Jay Sage, Jun 17, 2012.

  1. Jay Sage

    Joined:
    Jun 2, 2008
    Messages:
    284
    Likes Received:
    1
    I'm running the 64-bit version of TCMD 14, and I get an error message when I try to load the plugins that run with my installation of TCMD 13. Here is the command and the error message (the file is present):

    TCMD14x64\plugins>*plugin /L sysutils64.dll
    TCC: (Sys) The specified module could not be found.
    "sysutils64.dll"

    Vince apparently does not have a problem loading his plugins with the 32-bit version. Has anyone else successfully loaded plugins with the 64-bit version?

    -- Jay
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    IIRC Vince successfully used 32b TCMD 14 with 32b plugins on 64b Win7, and also the 64b versions of TCMD and plugins, but you cannot mix 32b plugins with 64b TCMD. The interfaces are incompatible.

    However, your error message indicates that sysutils64.dll is not present in the plugins subdirectory, thus it is obviously impossible to load it. Check that the plugin is actually present! BTW, I keep several TCMD versions in adjacent directories, and I have a parallel PLUGINS directory. In each of the TCMD V12, V13 and V14 directories there is a junction to the common PLUGINS directory. This eliminates the need to update a plugin in more than one directory when a new version becomes available.
     
  3. Jay Sage

    Joined:
    Jun 2, 2008
    Messages:
    284
    Likes Received:
    1
    Steve, the file -- as I wrote in my original message -- absolutely is present in that directory. Indeed, the name was filled in by file completion! That's part of why the error message is so bizarre. I have even tried using the full path to the file (in case the PLUGIN command is searching somewhere other than the current directory, even though that is the default directory from which they should be loaded), and I get the same error message.

    Before I posted my message, I wrote directly to Vince. Again -- as I wrote -- he confirmed that the 32-bit plugins work in the 32-bit version of TCMD 14. He has apparently not tried installing the 64-bit version of TCMD 14 and urged me to post my message about the problem.

    I'm still waiting for someone who is running the 64-bit version of TCMD 14 to tell me if they are having a problem loading the 64-bit plugins from TCMD 13.

    -- Jay
     
  4. jwiede

    Joined:
    Jul 5, 2012
    Messages:
    21
    Likes Received:
    0
    Just a head's up that I encountered the same problem, and using a tool called "Dependency Checker" was able to determine the problem (and work around it). The problem is that the x64 plugins all have dependencies on takecmd.dll, but in v14 it was apparently renamed to takecmdx64.dll o_O . The plugins cannot resolve the dependency and thus refuse to load.

    The way I worked around it was to copy the takecmdx64.dll file as takecmd.dll in the same directory, and after doing so the problem loading plugins disappeared. Also, I received a brief note from Rex @ JPSoft telling me the issue was known, and a fix was coming shortly (perhaps as soon as today), so the workaround should only be needed short-term.

    Good luck!
     
  5. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    A symbolic link seems to work as well. If re-renaming the .DLL causes too many problems, perhaps the x64 installer could create a symlink automatically?
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Why symlink? Why not hard link? Resolivng a symlink requires at least two directory accesses, hard link is resolved on the first access. Of course, the access time difference is not significant if it occurs only when the plugin is loaded (assuming it is done automatically, and you do not start many TCC instances rapidly). OTOH when the issue is resolved (presumably by restoring the original name) a symlink can be removed even when the dll is in use, but not a hard link.
     
  7. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    Either way; I'm not advocating for one over the other. I'm just thinking that a link (either flavor) won't have to be manually fixed when updating TCC, as a copy would.

    XP apparently doesn't support symbolic links, so for that reason alone a hard link might be the better approach.
     

Share This Page