Hi Jeff,

Not doing so much editing these days, so never thought about the issue.

On a quick hack about, I reckon there may be a way round, but it brings some compromises (as always!) but to my mind only minor.

I believe you are correct in the interoperability problem. I think the key is in the file interop.ini which is held (on my system) in all the x64 sub-folders of C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\?.?\

On my desktop system the series ?.? run from 2.0 to 9.0, corresponding to the installations of PDR I have installed which are 12,14, 15,16 perpetual and then 365 subscription (=17,18,19 equivalents)

I have CDR 4,5,6 and then 365 (= 7, 8, 9 equivalents)

So, looking at the differing interop.ini held in each sub-folder (and ignoring anything to do with Action Director) they look like this:
C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\2.0\x64
[PowerDirector]
ver=11,12
[ColorDirector]
ver=1,2

C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\5.0\x64
[PowerDirector]
ver=11,12,13,14,15
[ColorDirector]
ver=1,2,3,4,5
[ActionDirector]
ver=1,1.1,2,2.1,3

C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\9.0\x64
[PowerDirector]
ver=11,12,13,14,15,16,17,18,19
[ColorDirector]
ver=1,2,3,4,5,6,7,8,9
[ActionDirector]
ver=1,1.1,2,2.1,3

It's a straight progression of content from 2.0 to 9.0, although I've only given 3 examples.

Given that these are plain text files they can, of course, be edited.

WARNING
For those folk who are not adept at doing this sort of thing, take backups of original files and only work on copies. Editing this sort of system file might screw your PDR/CDR functioning if you get it wrong. Be careful!!

So a couple of working examples editing the interop.ini file:
C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\9.0\x64
[PowerDirector]
ver=19
[ColorDirector]
ver=6
[ActionDirector]
ver=1,1.1,2,2.1,3

This seems to tie PDR19 (in my case PDR365) to CDR6 not CDR9 (or CDR365 in my case)


Another example:
C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\5.0\x64
[PowerDirector]
ver=15
[ColorDirector]
ver=5
[ActionDirector]
ver=1,1.1,2,2.1,3

Ties PDR15 to CDR5


C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\9.0\x64
[PowerDirector]
ver=19
[ColorDirector]
ver=4
[ActionDirector]
ver=1,1.1,2,2.1,3

Ties PDR19 to CDR4

Whilst I haven't tested all combos exhaustively, so PDR14 doesnt call up CDR at all for an unknown reason - probably needs a re-install, and my perpetual PDR17 is on the laptop, I suspect, with a small bit of file management, you could tie any version of PDR to any version of CDR by using edited interop.ini files in their respective and proper file locations.

Wonder if this is an easier way to get what you require, either by having a set of "alternate" interop.ini files to suit or by just a quick edit when necessary??

I haven't explored the Audiodirector side - I can't yet find a similar set of files that might control the functioning in the same way!

Adrian Life is really simple, but we insist on making it complicated. (see below)
Confucius
AMD Phenom IIX6 1055T, win10, 5 internal drives, 7 usb drives, struggling power supply.

Thanks Adrian,

Yes, I had played similar tricks with some success, hence the pointer to the location. What's strange is I think CL is trying to keep track since the interop.ini file in InteropPalette\9.0\x64 has the array of values with all in product release order. It to me looks like some aspect of this file is not being read and applied correctly.
I had not resolved as it appears InteropPalette\9.0\x64 settings also affect prior versions so it appears more than just a change in each release interop.ini file.

I would have liked a opinion from CL support, but my ticket started so low on the thought curve I can't see value going forward. Your attempt was several light years ahead of support, appreciate it.

It appears you have similar wrong interop experience as I discussed so I think something amiss with what CL is doing to keep each product properly coupled.

Jeff

Looks like another user with the same issue:

Quote My promise to test earlier versions ran into a snag. On one PC, I have PDR15-19 & CDR5-9 installed but the most recent version opens, whichever version of PDR is used. I've temporarily uninstalled CDR to test CDR8 but the results seem to be similar thus far.

https://forum.cyberlink.com/forum/posts/list/84139.page#post_box_347955

Obviously another PD bug, 3rd user test with anomaly, nothing logical would imply that's proper functionality. I pointed CL support to this thread after dismal initial response to ticket, I will wait for their follow up response now that they see a multi user issue.

Jeff

I don't see any reason to jump through all these hoops to manually define which version of CD (or AD) you want PD to use.

As far as I can tell PD, reads through the registry multiple times to determine which other CL programs and versions are installed, but when asked to invoke CD (or AD) it relies on the presence of the highest version number listed at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CyberLink

On my system, I have CD3, 4 and 9 installed, and I made a backup of (exported) the full CD9 and CD4 keys.

If I delete both registry keys with PD365 closed, it calls CD3 when requested because it's the highest remaining version of CD. If I close PD and restore the CD4 key, PD365 calls CD4.

No messing around with InteropPallette or any .ini files or system images; just make backups of the higher CDx (and ADx) keys and restore/delete them as needed.

I'd also make a copy of the full Cyberlink key so there's a reliable recovery of all the original keys.

Quote I don't see any reason to jump through all these hoops to manually define which version of CD (or AD) you want PD to use.

As far as I can tell PD, reads through the registry multiple times to determine which other CL programs and versions are installed, but when asked to invoke CD (or AD) it relies on the presence of the highest version number listed at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CyberLink

On my system, I have CD3, 4 and 9 installed, and I made a backup of (exported) the full CD9 and CD4 keys.

If I delete both registry keys with PD365 closed, it calls CD3 when requested because it's the highest remaining version of CD. If I close PD and restore the CD4 key, PD365 calls CD4.

No messing around with InteropPallette or any .ini files or system images; just make backups of the higher CDx (and ADx) keys and restore/delete them as needed.

I'd also make a copy of the full Cyberlink key so there's a reliable recovery of all the original keys.

I doubt reading through the registry for highest installed version is the approach or modifying the *.ini files would not have an effect, which multiple users clearly show it does.

Seems like the Interoperability should work without unloading/loading windows registry keys every time you want to run a compatible released product set. That's in essence what the *.ini files do is define proper product run configuration. I'd suspect CL support runs into this frequently supporting their diverse install user base and will hopefully have some easy compatible approach once the question was properly understood.

Jeff

Quote My question, have any multi PD install users identified how to fix the interoperability issues?

I am sure that someone will have the answer soon and post it. I find that all the previous versions of PD opens the latest installed CDR including PD12. Never pursued this interoperability issue since each of the earlier versions of CDR can be opened and used as a standalone app if desired.

Quote Seems like the Interoperability should work without unloading/loading windows registry keys every time you want to run a compatible released product set.

I totally agree, I'm simply sharing what I saw when using ProcMon and that manipulating the registry keys provides the desired result. without very much effort.

It's only a workaround and not a substitute for a proper version interoperability across CL apps.

Here's a video I just made showing how quick and easy it is to swap which CD version is invoked from any version of PD. I didn't even need to close PD to make the changes:



Note that I had previously exported the CD4 and CD9 keys, which is mandatory to restore full functionality before deleting them.

I've tested this on PD13, 14 and 365(19) with CD3, 4 and 365(9). All combinations are accessible and PD doesn't need to be closed when making registry changes.

This is ingenious. The CD4 and CD9.reg keys were first exported before making the screen recording. The keys were deleted, and restored later from the desktop in the video. Don’t know if PIX used this method or the uninstall to perform his tests as the time signature is too close.

I just wanted to close this thread out, after several dialogs back and forth with support, they had no solution to maintain proper interoperability to couple like released versions of their products together as was asked in the OP and the support ticket. They could only suggest continued uninstalling, reinstalling, patching products to get the proper combination of released products for that particular editing session.

So other than multiple different approaches to address deficiencies, no permanent solution identified for proper released version interoperability.

Supports final comment as typical was simply: "we've escalated the suggestion to the product team as a program improvement reference."

Jeff