* Detecting emulator/Wine by plugin

[Mark1834]

Quick question - is there a simple way for a plugin to tell whether it is running in an emulator or under Wine rather than native Windows (e.g. by testing for the presence or absence of a characteristic file or Registry setting)?

If the plugin can't work in this environment, it is more user-friendly to say so when it is first loaded.

[tatewise]

My Backup & Restore FH Settings plugin uses the Family Historian Program Data Folder pathname, which has got even simpler now that Windows XP is not likely.
i.e.
If it is C:\ProgramData\Calico Pie\Family Historian\ then that is native Windows or a Windows VM.
Otherwise, it is an emulator such as Crossover or Wine.

[Mark1834]

Thanks Mike, sounds simple. I'll reinstall FH6 onto my Linux Mint box and give it a try later. My plugin requires Win 7 SP1 or later, so variable name is not an issue. I know that is a slightly tighter requirement than for FH6 (but not FH7), but unlikely to be a problem in real world use.

[Mark1834]

Now tested, and unfortunately that is not a reliable method. Under PlayOnLinux (which is essentially just a friendly front end for Wine), the directory is reported as C:\ProgramData\Calico Pie\Family Historian, even though it is really at /home/mark/PlayOnLinux's virtual drives/Family_Historian/drive_c/ProgramData/Calico Pie/Family Historian.

That makes sense, as the whole point of Wine is that it fools the Windows app into believing it is running natively.

I think we need to test for a "signature" file that is in every supported version of Windows (7+), but won't be in the FH wine bottle. I'm arbitrarily using the Windows Mail executable file (C:\\Program Files (x86)\\Windows Mail\\wab.exe), but any better suggestions from our emulator experts...?

[tatewise]

Mark, that rings a bell regarding PlayOnLinux(Mac) using the same ProgramData path as Windows.
I will update Family Historian Program Data Folder to reflect that.

Like you, I struggled to find some distinguishing feature, especially as you say Wine is trying to emulate Windows, and like you, I asked emulator experts at the time.

It is strongly recommended that users invoke the Tools > Preferences > General tab, and Advanced... button to set the Emulator Compatibility Mode. That option exists in FH V6 & V7. So perhaps that Registry key could be used and documented with plugins that rely on differentiating emulators from native Windows systems.

[Valkrider]

@Mark and @Mike

See this post on a couple of ways to check for Wine.

https://forum.winehq.org/viewtopic.php?t=4988

[mjashby]

Don't know if this offers any detection options but at the top level of each Wine Application Prefix (the application's root folder). there is a number of a text files including one named "system.reg". The first line of text in that file currently states:

"WINE REGISTRY Version 2"

Exactly the same applies in Crossover created apps; and presumably also to all other front end GUIs for Wine as it's an essential 'Wine system' file.

Edit: As there is normally no similarly named file in a Windows System at C:\ it might be sufficient to simply test for the existence of the "system.reg" file.

Mervyn

[mjashby]

Further info.

Having checked further, there are several files created that only exist in a Wine.app and which clearly identify that an installed Windows application is running (or attempting to run) in a Wine environment. These files are only created during/after installation of the Windows software so don't allow the software to detect a Wine environment at initial installation.

The WineHQ discussion thread that 'Valkrider' pointed out seems about whether Windows application installers could identify whether or not an attempt is being made to install under Wine rather than on a 'real' Windows system. There are, of course both positives and negative negative sides to that argument; and 'negative' seems to have been more vocal.

Positive side - If Wine installation could be made clearly identifiable, Windows Software developers could potentially ensure their applications are 'Wine friendly' by, for example, introducing automatic 'helpers' or options for users. Calico Pie did, of course, introduced the 'Emulator Compatibility Mode' setting in FH6, but that setting requires user intervention rather than using any form of automatic environment recognition.

Negative side - Providing a clear indication that a Wine.app was being created would enable Windows developers to introduce 'blockers' to prevent installation; and/or or possibly lead to employing 'lazy' work-arounds in preference to resolving any programming shortcomings either in the base Windows software or in Wine itself.

My view is that the negative side's argument completely ignores the fact that a Wine installations can be readily detected post installation by any competently programmed Windows software and 'blocking' could be triggered relatively easily at that point.

In the FH Plugin scenario would it be possible to check for the existence of one (or more) of these files to detect the use of Wine? Alternatively, could a plugin query the 'Emulator Compatibility Mode' setting?

Mervyn

[Mark1834]

Thanks folks, very useful.

I know that the initial Store version of my backup and restore plugin will not work correctly in an emulator, so all I want to do at this stage is include a friendly warning when the plugin loads that it appears to be in an emulator, and give the user a chance to quit (but not enforce it in case of false positives).

I've had a quick look at accessing the files Mervyn mentioned, but I don't think they are accessible from within FH. All it sees in "C:\" is the basic Windows folders, and no files. If I look at the Linux root ("Z:\"), the FH files are not visible, even if I include "hidden files. I can access everything directly from the Linux file manager, but that doesn't help FH.

FH can see what might be a characteristic Registry Key that should not be in a native Windows environment (HKEY_LOCAL_MACHINE\SOFTWARE\Wine). Interrogating that and the Emulator Mode key might just do it. I think Colin's link mentioned the possibility of someone having a similarly named Windows app, but that's not a show-stopper here.

I'll do a short diagnostic plugin later today that will simply report emulator or native. I'll test it in Linux Wine, but if you guys could try it on the Mac as well please that would be great.

[mjashby]

Mark,

Good luck with your efforts. Happy to test whatever you come up with.

Just for info. I connected a working Crossover FH7 Wine.app to a Windows 10 Virtual Machine as a shared folder and was able to access the Root folder (image below) the files shown are those that are exclusive to Wine installations. The cx... are specific to the Crossover installation, but the 3 .reg files are also also created in a native Wine installation on Linux.

Mervyn

Screenshot 2022-04-29 at 12.36.51.jpg (100.88 KiB) Viewed 2437 times

[Mark1834]

Thanks Mervyn. This is the corresponding window in PlayOnLinux/Linux Mint, and it is encouraging that the structures are similar. I've looked at the .reg files, and they appear to be similar to the Microsoft versions, but formatted slightly differently.

Screenshot from 2022-04-29 16-20-57.png (50.18 KiB) Viewed 2388 times

A simple diagnostic plugin is attached. Detecting WINE worked ok, but getting the emulator compatibility mode setting appears slightly more complicated. In native Windows, it is saved in two different keys, but only one responds to changing the selection in FH. Under WINE, only one of these is present (the one that doesn't change in Windows), but it does reflect the state set by the user. I need to investigate further whether this is a Windows/WINE or FH6/FH7 difference, but it looks useable whichever it is.

Compatibility Mode.png (67.19 KiB) Viewed 2388 times

[tatewise]

Mark, in my backup plugin I have to keep track of Registry Keys to use RegRead/Write in emulators.
HKCU\Software\Calico Pie\Family Historian\2.0\Preferences\Emulator-Compat-Mode was the only key in FH V6.
HKLM\Software\WOW6432Node\Calico Pie\Family Historian\2.0\Preferences\Emulator-Compat-Mode was added in FH V7 and the HKCU key is now an unused redundant leftover.
So you will have to check whichever is appropriate for the FH Version.

[mjashby]

Mark,

Have just tested the Wine Detector on my Crossover for Mac installations of FH6 and 7. In FH6, it works as indicated in your screenshots, but (for me) FH7 'crashed' when the plugin was run, i.e. FH7 simply shut down, but no error message was generated.

No harm done to the FH7 installation, so it should be safe for any other willing Crossover users to see if they get a similar result. Will test with FH7 on 'Linux' and add my findings.

Edit: Tested on Linux Installation and FH7 crashed with the following error: "Unhandled exception: page fault on read access to 0x70e0d000 in 32-bit code (0x7bc3c834)." Full zipped error report attached - the references to Lua might hold the key info. but it's beyond my level of understanding.

backtrace.txt.zip

Mervyn

[Mark1834]

Sorry about that Mervyn. I don't have a spare FH7 license for WINE, so I'm testing with FH6.

My guess is that there might be an issue somewhere for FH7 and 64-bit Registry calls, so could you try the attached modification please? It does a simple check for WINE first, reports that, then checks for the Emulator Compatibility setting without any reference to 64-bit.

Does it complete, crash after the first message, or crash as soon as it is run?

[mjashby]

Mark,

No need to apologise for trying to break new ground.

The initial plugin produced an immediate application crash (not a system crash) with FH7 but fine with FH6, so it's presumably down to application change(s) between '6' and '7'.

No problem experienced with the 'simple' version:

Screenshot 2022-04-30 at 15.52.47.jpg (39.75 KiB) Viewed 2329 times

Mervyn

[Mark1834]

Excellent, thank you. It’s checking for a specific WINE key, rather than just the general presence of WINE, so the chance of a false positive in native Windows is low. Given that it crashes rather than just not working fully, I’ll force version 1 of the plugin to close if it detects an emulator.

When the time comes to test an emulator-compatible version in FH7, I’ll either download an FH7 trial or see if I can negotiate a temporary extra licence with CP. If they don’t want to put proper backup in FH, the least they can do is support volunteers who fill the gap...

[Valkrider]

@Mark

I can confirm that this version of the plugin runs perfectly and identifies Wine when V7 of FH is run on PlayOnMac. So I think that ticks the Mac box with Mervyn's reply unless you want me to check with Crossover.

[Mark1834]

Thanks Colin. I'm happy that basic WINE detection works as planned, so I've made the Backup and Restore Plugin message a bit stronger when run in an emulator. I think I now have a store-ready Windows-only version, so I'll update the help file, do some more tests, and submit it after the Bank Holiday. It just does the simple detection, rather than worry about Emulator Compatibility mode (thanks for the explanation Mike, that makes sense, but pity that CP didn't mirror the change in both keys to avoid getting a wrong result if you retrieve the wrong one ).

I think I know how to fix the FH7 issues, so hopefully an emulator-compatible version can follow before too long (ready for when early adopters find any remaining bugs in version 1...).

[tatewise]

That handling of the Compatibility Mode reg key is an example of the sometimes inexplicably odd workings of CP.
I can only assume they decided it was better to set the mode for the local machine rather than separately for each user.
I agree that FH V7 should set both, but that would mean a check every time FH was opened.

[Mark1834]

Presumably there are no technical issues with running FH7 and FH6 in separate Wine bottles on the same system? My understanding is that they will be completely independent installations.

[mjashby]

Mark,

It's OK to have multiple versions of FH installed in WINE, as long as you create them in separate PREFIXES (Bottles), but you do need to point them at different data folders because of the 'database' incompatibilities, e.g. I currently have a "Family Historian 6" Folder in Documents, plus the standard "Family Historian Projects" Folder for the current version. Both, of course, also have their own internal Backup Folders for storing compatible data/projects and Settings backups.

Edit: I've never tried it, but It might be possible to do this in Windows by using a 'Sandboxing' application to contain the 'alternative' installations.

Mervyn

[Mark1834]

Thanks Mervyn. It’s only for developing and testing the backup plugin, so I just have a basic one person project loaded. I’ll have a play over the next few days...