Cxbx-reloaded: Registry corruption (impacting EmuShared settings and runtime)

[JackaJacka123]

Running on the August 2nd commit from the app veyor release folder. When I click to configure any key (keyboard or Xbox One Controller connect via usb) Cxbx hangs, then crashes.

[BenNottelling]

You really should be posting issues with the latest build... Now try deleting the Cxbx-Reloaded registry folder and then test again (pretty much a go-to with anything involving settings) and I feel like when I tried to config controls it hung for me as well, but when I was patient and waited the issue resolved itself :)

[JackaJacka123]

I am running the latest automated build: it just came out yesterday. After I enabled Xinput it worked perfectly. I'll keep this open but my Xbox One Controller is working

[BenNottelling]

Oh yeah, if you exclude PRs it's been a day since the last commit to master, sorry my bad :)

[gandalfthewhite19890404]

Maybe keep setting in config file, not in registry? So if you download new version you will get clean emulator. If you need old settings - just copy from old version.

[BenNottelling]

The settings do carry over from version to version

[LukeUsher]

The issue is that at run-time, settings are stored in shared memory between the GUI and the Emulator process, so both can read them. Occasionally, when the emulator crashes, this shared memory becomes corrupted, and still gets written to the registry. The result is broken settings.

A solution could be to page-protect the shared memory as read only, except when we specifically wish to write to it. This will greatly reduce the chance of corruption.

[PatrickvL]

Or split it up in a few parts:

1. writeable-in-GUI, readonly-in-emulator (for passing input signals and config-changes to the emulator)
2. readonly-in-GUI, writable-in-emulator (for feedback from emulator to the GUI)
3. read-only in both (for static shared data required for both processes - no use-case for now)
4. writeable-to-both (for volatile shared data altered by both processes - no use-case for now)

[CakeLancelot]

907 partially fixes this issue (users can reset their settings and it will no longer crash), but there is still the underlying problem of the settings in the registry being corrupted. Perhaps rename this issue or create a separate one? This might also be relevant to #224 as for where to store the settings in the future.

[LukeUsher]

Closing this issue as #1312 will solve the problem