32 and 64-bit TC in same directory and OpenSSL dlls

[Sob]

So it seems both 32 and 64-bit versions in same directory is supported scenario. Unfortunately OpenSSL authors didn't go with libeay64.dll and ssleay64.dll, but instead left the same filenames for both 32 and 64-bit dlls. That wouldn't be a problem, because the same is true for many other dlls in system. One could e.g. create C:\some\path\lib32 and C:\some\path\lib64, put the proper files there, then add both paths to PATH and voila, it would work. But it doesn't, because TC doesn't load OpenSSL dlls from PATH.

The only option seems to be to move at least one set of dlls to Windows, (real) System32 or SysWOW64 directory, but not everyone likes to mess with those directories. Or do not install both TCs in same directory. So some solution does exist and it's probably not really a bug. I'm just bringing it up to be known, because I'm sure it could confuse someone.

[Samuel]

What about the tcmatch.dll? Is it called tcmatch64.dll?

[Sob]

No, 64-bit TC still looks for tcmatch.dll. But I don't think it's intentional.

[ghisler(Author)]

The problem is that these dlls seem to call each other, so I canot simply change the name. What would you suggest? One solution would be to look in Windows\system32, and another to look in %commander_path%\64 or so. What do you think?

[Sob]

If it was just about me, I'd say to drop that security measure, allow loading dlls from PATH as is the Windows standard and I'd be set. :) But regular users won't be playing with custom library directories for sure, so it's not universal solution. And it's unusable for portable TC too.

Using System32 directory is possible, TC already looks there. If user puts 32-bit dlls to SysWOW64 and 64-bit ones to real System32, then it will work. But my experience suggests that putting dlls to system32 directory brings only trouble for users. They forget about it and later it conflicts with something else, or they just miss those files when moving TC to another computer, ... Plus they might not even be allowed to write there. And again there's that problem with portable TC.

The subdirectory in TC's dir seems as the easiest solution that should work for everyone.

But then again, there's similar problem with plugins, e.g. your sftplug. It needs OpenSSL dlls too and finding them in %commander_path%\64 will hardly work without some help.

Seems to me that common directory for both TCs is not as easy as it might look at the first sight...

[Samuel]

What about the tcmatch.dll? Is it called tcmatch64.dll?

Could you please take a stand on this, Christian?

[karlchen]

Hello, Christian.

The problem is that these dlls seem to call each other, so I canot simply change the name. What would you suggest? One solution would be to look in Windows\system32, and another to look in %commander_path%\64 or so. What do you think?

I am pretty sure that we will run into trouble if we really try to install 32-bit and 64-bit versions of any plugin in the same folder.
Christian tried to solve the name conflict by adding the "64" to the affected filenames.
Not all plugin authors will do so. Moreover there are plugins like e.g. SFTP which depend on third party DLLs (libssh2 in this case). The authors of these DLLs may assign different names to the 32-bit DLLs and to the 64-bit DLLs or they may not. Some of them will not be bothered to do so.

Therefore I would like to suggest that T.C. follows the same approach that Process Hacker follows:

• Process Hacker uses a base folder which the user can choose, e.g. D:\Utils\ProcessHacker.
• The 32-bit main program will be in the subfolder "x86", i.e. D:\Utils\ProcessHacker\x86
• The 64-bit main program will be in the subfolder "x64", i.e. D:\Utils\ProcessHacker\x64
• The base folder holds a "plugins" subfolder, too.
• Again there are the subfolders "x86" and "x64" inside the "plugins" subfolder.
• I.e. the 32-but plugins will be located in the folder D:\Utils\ProcessHacker\plugins\x86
• I.e. the 64-but plugins will be located in the folder D:\Utils\ProcessHacker\plugins\x64
• This way there is no need to name the 32-bit and 64-bit files differently. They are simply put in the appropriate "x86" or "x64" subfolders.
  Task accomplished.
  Case closed.

From my perspective the Process Hacker approach is a very simple and very efficient approach of making sure that 32-bit and 64-bit files can be installed simultaneously without running into name conflicts.
So why not adopt this approach for T.C. as well?!

Cheers,
Karl

[Samuel]

Support++

[MVV]

I think it is not a good idea to completely change folder structure. Is is much easier to add a pair of INI keys with paths to common folders where TC can search DLLs to load, one for 32-bit DLLs and other for 64-bit DLLs.

[tbeu]

I would prefer two different installation directories for TC32 and TC64 like %ProgramFiles(x86)% and %ProgramFiles% even if there are common files (like TOTALCMD.HLP etc.). Plugins go to different subdirectories of the appropriate TC installation directory. The INI files of TC and the plugins are shared.
There is no mess with 32bit and 64bit files in one directory. All name clashes are avoided.

[Sob]

Christian tried to solve the name conflict by adding the "64" to the affected filenames. Not all plugin authors will do so.

They can be easily forced to add "64" if TC x64 refuses to to load plugins without it. ;) But it's pointless, because it does not solve the problem with other dlls.

Your suggestion with separate subdirectories does, but...

1) I see having both 32 and 64-bit TCs as temporary thing, at least for non-portable use. Once the most used plugins have 64-bit versions available, there's no reason for regular users to keep 32-bit TC around. No need to agressively get rid of it, but no one will install it on new systems. But with your directory structure they'll have all those (for them) unnecessary "x64" subdirs. It's nothing tragic of course, it will just look kind of stupid.

2) More importantly, I don't see how moving 32-bit TC into x86 subdirectory could go through authors extreme dedication to backward compatibility. ;) I mean, it's not there now and users are used to upgrading simply by running installer and overwriting previous version. And they may have shortcuts set to old location. Or various other settings, e.g. plugins, already point to some location that would have to be changed. And while the installer could do that for current ini, user can always restore some old backup and get everything messed up. I don't think this can pass.

The INI files of TC and the plugins are shared.

Unless you use ini in program dir... (is it still supported, right?)

[MVV]

BTW you may solve problem temporary right now. Just edit your module/tool that requires 64-bit OpenSSL using HEX editor, find DLL name in it and change it. Don't change name length, just replace last name letters. E.g. change libeay.dll to libe64.dll or libeaX.dll or even libeay.d64. That's all! Your module/tool will now load renamed module so you can place it near 32-bit one.

The only requirement for this - module/tool must not be packed because packers may pack import table too.

[tbeu]

The MAT-file plugin depends on 20 third-party DLLs which have the same name for x86 and x64 platform. I certainly cannot and will not rename and hex-edit them. If the user has already installed these DLLs the plugin will find them and load. If the user has not installed them he/she can put them in the plugin directory. But with same DLL name for x86 and x64 it is impossible to put both DLL versions in one common plugin directory. Currently I have no idea how to solve this. It is the same problem like the OpenSSL DLLs except that it is a plugin and not TC itself which has the external lib dependency.

[Samuel]

What about the tcmatch.dll? Is it called tcmatch64.dll

FYI: With beta 2 the file is named: tcmatch64.dll.

So Christian seems to stay with the "one folder for everything" solution.
Not a bad decision IMO. (there will be some problems with naming but no problems with different configuration files.)

[ghisler(Author)]

Could someone try whether OpenSSL works with the 64-bit files in subdir "64" under the Totalcmd directory, please? This should work now with beta 2.