Family Historian User Group

FH stores preferences in two different Registry keys. One of these keys has two alternative locations, depending on whether it is 32 or 64-bit Windows.

FHUG prototypes of the Backup and Restore plugin called the 64-bit values explicitly, so did not work in 32-bit Windows. The store version calls the 32-bit values, which returns a value in both 32-bit and 64-bit Windows, giving full interoperability between the two versions.

This works perfectly when run within the plugin, but I have discovered that the 32-bit version is only accessible from within the 32-bit application that it relates to (such as FH), not directly from 64-bit Windows.

This only affects advanced users who create their own backup scripts that they run directly, as one of the two FH Registry keys is not saved. I’ll fix it in the next release, but in the meantime, advanced users may want to correct the scripts themselves.

Simply change (and the corresponding command in the Restore batch file)

Reg export "HKEY_LOCAL_MACHINE\SOFTWARE\Calico Pie\Family Historian\2.0\Preferences ..."

to

Reg export "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Calico Pie\Family Historian\2.0\Preferences ..."

My 'Backup and Restore FH Settings' plugin has a similar issue.
If you are interested, I believe the choice can be automated using the registry key:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\PROCESSOR_ARCHITECTURE

If its value is x86 then it is a 32-bit PC and WOW6432Node is not required.

Any other value indicates a 64-bit PC and WOW6432Node is necessary.

Thanks Mike, that does the trick nicely.

FH6 and FH7 on two different i5/Win 10 systems both identify as AMD architecture (don't Intel love it when their rival develops an architecture first and has it named after them... ).

FH6 and FH7 in two different 32-bit Wine prefixes on my 64-bit Linux box both identify as x86 architecture. That's more reliable than trying to call a WOW6432Node key, as WINE gets upset if you do that in a 32-bit prefix.

What I hadn't realised until recently though is that reading and writing to the Registry by plugin doesn't seem to need WOW6432Node at all. Just use the equivalent 32-bit value, and that works in both 32-bit and 64-bit environments. It's one of those things that's blindingly obvious in hindsight. FH is a 32-bit app, so all its own Registry read/writes will be to 32-bit keys, not the WOW6432Node versions, even though they are the ones that the Windows Registry editor displays.

(don't Intel love it when their rival develops an architecture first and has it named after them...

Don't forget that AMD largely got where it is today by creating a reverse engineered clone of Intel chips

Anyway, thanks for creating this new backup pluging. It's nice to have a choice of backup plugins) though I'm still annoyed that CP don't supply a complete and full backup process).

Yes, the Windows on Windows 64 to 32 node WOW6432Node is a potentially mysterious beast.

When the registry is viewed from a 32-bit application it sees the same keys whether on a 64-bit or 32-bit PC.
The WOW6432Node is skipped automatically.
Similarly, if a 32-bit application like FH invokes say CMD.exe then the 32-bit version of CMD.exe is run.
When my plugin invoked a batch script then that automatically invoked CMD.exe 32-bit.
That is how my plugin worked for years and never needed to bother about WOW6432Node.

But then PowerShell became the default to run batch scripts and by default PowerShell 64-bit is always used on a 64-bit PC.
So the plugin now needs to know whether WOW6432Node must be used or not.