Feature Request: Displaying 32 and 64 bit plugins together

[evren]

Design industry nearly all sticked on 64bit because of resource and performance needs. But in plugins 32bit is still dominant. And really really need to see all together.

First idea will be something like 32bit plugin wrapper but it can have side effects. In case of wrapper, a performance issue and delayed opening time can occur. Reaction speed is (for me) most important value of PhotoLine. My humble solution is, a plugin list... When PL32 or PL64 starts, they can write a list of plugins in the config file and display them together in PL64 but display only 32bit plugins under PL32.

In case of clicking on a 32bit plugin under PL64, it can check the config, if it is 32bit it can directly pass the image or layer to the 32bit version of photoline. After passing to PL32, sending to plugin even can be handled manually. No matter, but seeing plugins together to decide is really needed.
It can be something really revolutionary.

I hope I'm not alone in this idea.

[photoken]

... but seeing plugins together to decide is really needed.

If you don't know which plugins are 32-bit and which are 64-bit, then you have way too many plugins installed.

I hope I'm not alone in this idea.

I think you are. You can set up the 32-bit PhotoLine as an "External Program" in the 64-bit version of PhotoLine, and easily switch to the 32-bit PL to edit the image using a 32-bit plugin. When you're done, save the edit and it will be updated in the 64-bit PL.

[evren]

1. I know all those and external program support. Already discussed many times.
2. Yes I have many intresting stuff. Here you can check also. http://grafnet.com.pl/Filters hope to be useful.

But before all those, a few months ago we discussed about "RESPECT" after your aggressive and smug answers to me.
I told you clearly "Please do not write anything to me and sure I will not write to you" I hold my promise, wish you to hold also. I dont want to discuss anything with people who doesn't know to be kind and respectful. That's why take my answer as a reminder to our previous and un-tasty discussion. Don't know you but for me nothing to discuss.

Thanks for your understanding in advance.

[photoken]

I dont want to discuss anything with people who doesn't know to be kind and respectful.

??? I see nothing in my previous reply to make you feel that way; but to each his own, and you're welcome to your attitude.

[evren]

Maybe just the way of expressing of each other do not match in style. Anyway not a big deal. And thanks for your understanding.

[Hoogo]

I wonder why there seems to be no other wrapper or bridge for 32Bit plugins? The plugin interface might be more tricky than I imagine.

[photoken]

I wonder why there seems to be no other wrapper or bridge for 32Bit plugins? The plugin interface might be more tricky than I imagine.

I don't think it's the plugin interface, it's the fundamental differences between 32-bit and 64-bit addressing, etc., that prevent it.

Just look at all the hoops MS has to jump through with WOW64 (Windows On Windows) and the associated special DLL's needed to emulate a 32-bit system under 64-bit Windows so that 32-bit programs can run. Even with all that, there are some limitations, and one of them is that 32-bit into 64-bit code injection will not work; and I think that code injection is basically how a plugin's code gets loaded into the running process.

[Hoogo]

I wasn't thinking about really running 32Bit Plugins in 64Bit. More of starting a small 32Bit host, copying the active layer to it and let that one host the plugin.

[photoken]

I wasn't thinking about really running 32Bit Plugins in 64Bit.

I thought I read about something like that, but I can't find it by searching now. Someone will probably post a link....

More of starting a small 32Bit host, copying the active layer to it and let that one host the plugin.

I imagine it would entail the same fundamental set of problems I mentioned earlier about emulating a 32-bit system. But, by setting up the 32-bit version of PL as an external program in the 64-bit PL, that accomplishes the same thing -- you leverage all the work MS did establishing SYSWOW64.

[Hoogo]

..I imagine it would entail the same fundamental set of problems I mentioned earlier about emulating a 32-bit system...

Sure, but it would not be my problem, and it is even solved already

[evren]

I wasn't thinking about really running 32Bit Plugins in 64Bit. More of starting a small 32Bit host, copying the active layer to it and let that one host the plugin.

This will be a wrapper. I just think about possible startup delays or performance problems. Performance is something you can not sacrifice ;)

The plugin interface might be more tricky than I imagine.

Actually, after I thinked on it. It's something extremely easy to fetch the names etc info from plugins. So the plugin manager can simply read all. But when it comes to executing, as photoken mentioned, there it needs something like injection. So needs passing to PL32 or a wrapper...

As mentioned above (me also agree) people simply can run them over PL32 in case of need. Other point is to not offer things will make developer team to get busy too much. It will delay some other features. The external software stuff is working like a charm. Me, just need to "see plugins together" to decide about effects. Sure dont know what others think and need over it.

But under any case a solution will appear in industry. Since the x64 Photoshop getting more and more popular, about in one year somebody will find a solution somehow. I don't know what adobe will do since they do not care about performance. For me, the last way to follow is their way. I'm sure Huber brothers can handle it in better way.

Cheers