* Testing plugin compatibility with Mac/Linux

[Mark1834]

As far as I know, there are no Mac/Linux users who contribute plugins, and I think I am the only current author who tests in Linux before publishing.

For most plugins, compatibility is not a problem. The UI may look a little odd, but it still runs. However, I have come across several scenarios in my recent plugins where I have had to modify the code to prevent FH from crashing without warning.

There’s usually a way around the problem, but only if the authors are aware of the potential issues. I have started drafting a “Writing plugins compatible with emulators” page in the KB to summarise the main problems that I (and other authors) have come across. These generally fall into two broad buckets, namely presentation bugs caused by different user fonts, and issues arising from the fundamental differences between Windows and Unix-derived file systems.

Before I go too far, I would like to enlist the help of our Mac/Linux users to check my assumptions please by downloading and running the simple diagnostic plugin linked here. It reports the system status, as in the attached screenshots for the three systems that I have easy access to, FH7/Windows 10, FH7/Linux, and FH6/Windows 11, and does not make any changes whatsoever to your system or files.

IUP Diagnostic.png (130.76 KiB) Viewed 1142 times

The various parameters are determined as follows:

FH Version – Read directly from the FH API.

Windows Version – Registry. Note that W11 reports as W10. MS were forced into this to avoid breaking software that was written based on their earlier claim that W10 would be the last version of Windows, so checks specifically for 10, not 10+.

Emulator Compatibility Mode – As set in FH options and recorded in the Registry. Exactly what this does is undocumented, but I suspect that it is something similar to what I am trying to achieve here – using alternative code to avoid libraries and functions not well supported in emulators.

WINE detected – checks for the presence of a Z:\ folder, which I think is an emulator standard way of denoting the /home directory on the host system.

Underlying OS – the value stored against the PRETTY_NAME key in the Z:\etc\os-release (/etc/os-release) file.

Default IUP font – the default font used by plugins in FH5/6, and in FH7 where user font preferences are not respected.

Default FH font – only for FH7, and is the font specified in Preferences > Property Box. Plugins that read this value have a similar visual appearance to the main FH application.

Dialog size – the report window is rendered in the default FH font if available, or the default IUP font otherwise.

Thanks in anticipation – if we can get a number of users running the plugin on different systems and posting a screenshot of the output, that would give me more confidence that my basic assumptions are valid (or we can correct them if they are not!).

[tatewise]

FYI:
My plugins use fhGetContextInfo("CI_APP_DATA_FOLDER") or fhGetPluginDataFileName("LOCAL_MACHINE") to obtain the ProgramData folder path, which after conversion to lowercase is tested for ":\\users\\public\\" to identify a non-Windows Crossover/Wine machine. However, this may not be foolproof.

[mjashby]

Mark,

Two to be going on with both from my old MacBook Pro Workhorse (2013). Should be able to re-run on a more up to date Intel Mac and also on a M2 ARM Mac later today, or Sunday at the latest.

Mervyn

[Mark1834]

Thanks Mike - you are testing for something that should be on a native Windows system only, and I'm testing for something that should be in WINE! I agree that neither is probably 100% bullet proof, but they are good enough for our purposes. There doesn't appear to be an official supported method within WINE for detecting its presence and obtaining the version number, so we have to rely on these surrogates.

Can I ask the obvious follow-up question please? What do you do with that information? If you already have a standard set of actions that you take (or avoid) when it sees an emulator, that would probably be useful for me to incorporate into the KB as well.

Mervyn's VM report is interesting. It can still see the hosting file system with my check (the presence of Z:\home). Does the VM also create a Public user as well (Mike's test for a \users\public folder)? If so, the two tests will give different results. My guess is that FH in a VM is much closer to FH in native Windows than FH under WINE, so may be able to cope with actions that bring WINE down.

[tatewise]

I'm testing to differentiate a Windows system from a Crossover/Wine system by using:

Code: Select all

StrFile = fhGetContextInfo("CI_APP_DATA_FOLDER")
Is_Windows = true
if StrFile:lower():match(":\\users\\public\\") then Is_Windows = false end

In Windows, the plugin uses REG IMPORT/EXPORT/QUERY batch commands that are not supported in WINE.
Otherwise, the plugin uses CSCRIPT to run VBS command file or individual RegRead commands.

I don't remember running into font or file system issues.

Theoretically, if we could rely on users setting Emulator Compatibility Mode no other test is needed.
One possible snag is where a user has both Windows and WINE systems and uses Backup & Restore FH Settings to migrate settings to and fro that might 'corrupt' the Emulator Compatibility Mode setting.

[Mark1834]

Thanks Mike. I tested your method, and it doesn't appear to work, as WINE maintains exactly the same folder paths as Windows.

Screenshot from 2024-06-09 09-34-14.png (50.3 KiB) Viewed 1024 times

I assumed you were using this to get the system disk (usually but not always C:\), then testing for the presence of a C:\users\public folder, which is ubiquitous in current versions of Windows. However, WINE creates this as well, so that doesn't work either! We're probably better sticking with checking for Z:\home. It could exist in Windows as well, but I won't worry about that very small possibility.

REG IMPORT/EXPORT/QUERY commands are supported under WINE - it's what the Backup and Restore Family Historian Settings via Windows plugin uses, and that is fully functional in emulators (including the point you made about not restoring the Emulator Compatibility setting, so it is ideal for transferring settings between Windows and emulators).

I tried installing your original Backup and Restore Family Historian Settings plugin on Linux to see how it behaves, but it generates an error and does not run, even if I modify the code to set Is_Windows to false manually.

That probably demonstrates why we need the KB page. WINE is a moving target. The current stable version is 9, so that will be available direct from the WINE repository, via Crossover, or in Linux distributions such as Fedora that prioritise latest developments. The Debian/Ubuntu/Mint family deliberately stay a couple of releases back, as they prioritise stability and consistency over having the latest and greatest.

I've deliberately not upgraded my WINE, as it will be a worst possible case for testing. Later developments may well support more, but they won't support less.

[tatewise]

It may well be that my plugin techniques have been overtaken by WINE developments. I rely entirely on feedback from users of emulators to get the plugins to work. Most feedback came from Crossover users some years ago.

Please post the Backup and Restore Family Historian Settings plugin Linux error in another thread.
It would be interesting to test a version of that plugin without the emulator variants to see what happens.

[mjashby]

Mark,

Here are the 'Test' outputs from my 2019/20 Intel MacBook Pro (from end-of-line Intel models). They are very similar to the output from the old 2013 previously sent. A slight variance in Font size, but that's probably down to the difference in screen resolutions between the two Intel MacBook Pro Models tested.

I was also curious about why "WINE detected: TRUE" is reported for the Windows Virtual Machines, as there is no dependence on a WINE installation, but having checked the VirtualBox User Manual it is clearly stated that some (unspecified) code from the WINE Project is used in the VirtualBox application, which may be something to do with supporting its cross-platform capabilities. I'm not in to wading through the many thousands of lines of source code so can only guess.

Mac ARM64 output to follow in a few minutes.

Mervyn

[mjashby]

Mark,

Here's the output from a, M2 (ARM) MacBookPro laptop

The Windows for ARM Virtual Machine was created on VMware Fusion Pro (now available free for personal use), as the VirtualBox macOSARM release is still at the Preview stage and is not yet able to virtualise Windows 11 for ARM. In contrast to the VirtualBox Intel VMs this test does not detect any form of WINE presence.

If there's anything else you need just let me know. Unfortunately, I don't have any WINE installs on Linux at present as I need to manage my licensed FH7 installations carefully.

Mervyn

[Mark1834]

That’s great, Mervyn. Thanks very much, there’s plenty of detail there to feed into the KB draft.

I agree with you on licensing, as I have the same issue. CP recognise the absurdity of expecting users to purchase additional licences simply for compatibility and robustness testing of their product in different non-standard configurations and have talked in the past about investigating some sort of developer licence to support this type of work.

Nothing has appeared, and I suspect their activation process couldn’t handle it. How do you activate the product for testing but not actual research? If it is trust-based, how do you decide who qualifies and who doesn’t?

Their problem, not ours. All it means is volunteers do less testing for them.

[Mark1834]

The draft KB page is now available at Writing Plugins Compatible With Apple Mac and Linux.

[mjashby]

@Mark1834,

I know you'll appreciate this seemingly new complication with CrossOver compatibility. I've retried your 'Backup/Restore Settings" plugin with CrossOver 24.0.4.

- The Settings Backup process completes successfully

- But the Restore process produces the following 'error/warning':

Crossover error 20024-07-17

Screenshot 2024-07-17 at 09.44.12.jpg (28.05 KiB) Viewed 616 times

As there was only one instance of Family Historian in use, the only possible explanation i can think of is that CrossOver now appears to use a 'pre-loader' to prepare all registered 'Bottles' for use when it is first started. Not sure when this practice started, but possibly with the redesigned interface for Crossover 23/24, but it is evidenced by the fact that when the Crossover application is terminated it reports the shut-down of each 'bottle' even if none have been used. Is it possible that the plugin is recognising the 'pre-loader' as a second running copy of Family Historian?

I don't remember any such issue with a native Wine installation on Linux and it definitely used to be O.K. on Crossover when the plugin was first released, so I presume the issue is linked to some change in CrossOver design.

Mervyn

Added crossover Shut-down image - No Apps were actually running prior to shutdown:

[Mark1834]

Thanks Mervyn - I actually noticed that a few days ago when I thought I ought to retest the Windows backup plugin following the discovery that the original backup plugin has probably not worked in WINE/Crossover for two years without being reported!

It wasn’t clear to me whether it was a WINE change or something else, but it was an easy fix - inhibit the restore if it sees more than one instance of FH, rather than requiring exactly one (which it wasn’t seeing in my testing). I’ve also taken the opportunity for a few other minor refinements to the plugin, so I’m testing it at the moment and will probably post a draft version over the weekend.