How to make 32 bit plugins to work in TC 8 64 bit?

[rilley]

Hi

Like the subject says:
How to make 32 bit plugins to work in TC 8 64 bit?


PS: Sorry if I posted wrong!
Thank you

[Gral]

No way.

[karlchen]

Hello, rilley.

Please, check out the thread about the 32-bit plugins which have been migrated to 64-bit by now. And more importantly, do not miss the corresponding T.C. WIKI article.

As Gral extremely briefly stated: Total Commander 32-bit uses 32-bit plugins. Total Commander 64-bit uses 64-bit plugins. You cannot use them in mixed mode.

Kind regards,
Karl

[rilley]

But to be a way to work 32 bit plugin in tc 8 64 bit

[karlchen]

Hello, rilley.

I will repeat it one more time. The verdict is final:

1. Total Commander 32-bit uses 32-bit plugins. It cannot use 64-bit plugins. Nobody ever requested it to be able to do so.
2. Total Commander 64-bit uses 64-bit plugins. It cannot use 32-bit plugins.
3. You can find the available 64-bit Total Commander plugins by going through the WIKI article List of 64-bit plugins and addons.
4. Either you install the 64-bit plugins which you need for Total Commander 8.0 64-bit or you don't. There is no other choice.
5. Discussing whether a 64-bit programme (Total Commander) should be able to load and use 32-bit DLLs (and plugins are just DLLs) is not much more than a waste of time.

Kind regards,
Karl

[Balderstrom]

It's interesting though, that Opera has been able to make 32-bit plugins work from it's 64-bit version.

64-bit Opera, and out-of-process plug-ins

64-bit builds

Bringing the out-of-process plug-in architecture across to Windows and Mac also brings another advantage: the ability to run plug-ins compiled for Intel 32-bit architecture from within a 64-bit Opera process.

[karlchen]

Hello, Balderstrom.

Total Commander plugins are DLL files in disguise, i.e. they are DLL files having filename extensions .wcx, .wdx, .wfx, .wlx instead of .dll.
A 64-bit executable cannot use 32-bit DLLs.
You need some kind of wrapper programme, because a 64-bit programme can launch a 32-bit programme and the 32-bit programme can use the 32-bit plugin.
Using a wrapper programme will make communication between the main programme, totalcmd64.exe, and the plugin more complex.

As you point to Opera as an example that a 64-bit programme can use 32-bit plugins: on Linux the main executable file opera spawns two children: the executable files operapluginwrapper and operaplugincleaner. This seems to confirm: it can be done, you need a wrapper process.

Yet, currently no such wrapper programme for Total Commander exists. No idea whether Christian will consider creating such a wrapper executable.

Cheers,
Karl

[paraglider]

And why would you want such a mechanism - communication between two processes will be many times slower than direct calls to functions in a local dll.

[karlchen]

Hello, paraglider.

Firefox and Opera introduced the wrapper in order to increase programme stability. Plugins can no longer crash the main programme. The Opera article which Balderstrom points to says so explicitly. Being able to run 32-bit plugins from a 64-bit main programme is only a nice side effect.

Whether the user will notice that communication between plugin and main programme through the wrapper programme is slower depends on what the plugin is used for.

Kind regards,
Karl

[ghisler(Author)]

I have considered to do this too - I'm already doing that for "copy as admin" and for the 64-bit context menu in TC 32 bit. However, it would be
1. quite slow
2. attracting bugs like flies, because there are so many functions
3. prevent plugin writers from porting their plugins to 64-bit.

I could add it as a reduced functionality workaround for the following plugin types:
1. Lister plugins: Just the ListLoad function
2. Packer plugins: Just browsing and unpacking

However, I'm not sure that this would be really helpful. The content plugins are out of the question because they need to be called for each file individually. And file system plugins are too complex to call (too many functions).

[HolgerK]

1. Lister plugins:

At least for <F3> theres is already the possibility to install the 32Bit TC version in the same directory and configure the Viewer to use external viewer with <F3>

Code: Select all

%COMMANDER_PATH%\totalcmd.exe  /S=L

Okay, this doesn't work for quick view panel, but may be helpful in some cases.

Regards
Holger

[theosdikaios]

2. Packer plugins: Just browsing and unpacking

That would be fine. I'm afraid that not all packer plugins will be migrated to 64 bit e.g. for SQX archives there is no 64 bit packer plugin at this time.

[MVV]

I think such wrapper plugins for all kinds of plugin types may be written by third-party plugin writers. The only problem that user will need to have many copies of that wrapper plugin (one copy per every plugin) and configuration will be different for 32-bit and 64-bit TC.

[ghisler(Author)]

A wrapper plugin sounds like a nice idea! The only downside is that it needs a separate background process for each plugin instead of just one for all plugins.

[Merix]

Hi Ghisler et al,

What would the reward be for a generic wrapper for 32-bit packer plugins for TotalCmd64, that fulfills these requirements:

The plugin will support all features of the packer plugin interface (both packing and unpacking).
Performance will be almost as good as when the same 32-bit plugin runs natively with TotalCmd32 (in fact, in most cases no performance degradation will be measurable).
All wrapped plugin will share just one 32-bit host process, and the overhead will be minimal.

What would the rewards be for similar wrappers for File-system, Lister, and Content plugins?

Kind regards,
Rico Elm