Quote:
Originally Posted by sneaker_ger
So, what exactly caused the XP incompatibility? Some library update or just a simple compiler switch? Esp. if it's the latter it could be useful for people looking into building their own XP-compatible binaries.
(Disclaimer: I don't use anything older than Win 7)
|
Quote:
Originally Posted by Mosu
I don't know. Figuring that out is part of the cost of that »support for Windows XP« thingy.
|
Since it's what the error message complains about, it's more than likely the use of
RegGetValueA in src/common/fs_sys_helpers/windows.cpp @ line 146. That function is Vista+ (or seemingly 2k3+).
Supporting XP in that instance would mean using a different registry querying function. RegQueryValueEx, as the answers on SO point to, but I doubt the actual parameters taken by RegQueryValueEx vs. RegGetValue are the same, so it'd require special-casing to support both (or simply an option to disable registry support at configure time so it doesn't build that part at all - which might make some degree of sense for portable builds, regardless of any OS version squabbling).
I haven't tried doing this in several years, but
Wine could be used to patch over XP itself to avert this. Wine can run 7.9.0 seemingly without problems*, since it implements support for higher versions of the Windows program APIs (if the OS itself was stable enough, it'd probably work swimmingly in ReactOS as it has a symbiotic relationship with Wine for program support while currently targeting NT kernel version 5.2). You just have to cross-compile Wine's DLLs under MinGW-w64 so that it routes the calls into win32. It could probably also be done under MSys2 or Cygwin.
*obviously, I'd normally just use the native build instead if I'm logged in under Ubuntu, but not everyone wants to switch their XP machines to Linux.
I had to resort to doing this in 2011 for a game that kept crashing using the Microsoft DirectX runtime. After I got Wine's d3dx9_43.dll built I dropped it into the game's directory, and everything was peachy. Since Windows prioritizes DLLs in a program's home directory, it'll use those before it tries the ones from the system. So if a cross-compiled copy of Wine's ADVAPI32.dll were in there, it'd more than likely work as-is without specific XP support. Provided that ADVAPI32.dll itself doesn't require more of the Wine DLL ecosystem.
EDIT: after testing a cross-compiled Wine (1.7.42-137-g6d323d8), that trick won't work atm. Windows is either smart enough to not load *those* particular .dlls from the application directory, or we're going to need a much more complete WineOnWindows environment (read: wine.exe itself, which the limited cross-compiling support in Wine can't do yet) to be able to do anything regarding that. But really, going to that much trouble generally isn't worth it when you can run an up-to-date version of [insert Linux distro name here] on the same machine and use the native build of MKVToolNix just fine. For ancient setups like mine, that's pretty much the only thing you can do short of just staying back at 7.8.0. The jury's still out on ReactOS since right now I don't have access to the VM I normally use, but ROS is still not anywhere close to stable for daily use.