Zombiedeth wrote:well if it just relies on windows api's so much of it is already in WINE. think it's just NT 6.x kernel api's that could be a problem if any software relies on that. Version spoofing should be easy on ReactOS though.
That is all pretty much what I said.
There is some NT 6.x code in there now, but only to help with Wine syncs. That is still not their version goal. Z98 can explain it better when it comes to halfway implementing APIs for a higher version of WIndows. He says more or less that if you include newer Windows APIs and report an older version, that some applications can get confused. They may look at the exports or crawl the DLLs or whatever and ignore the version, and if certain things are found, other things are assumed to be there. Then the program crashes when the OS cannot deliver.
Hey, I might have a workaround in mind. Okay, so you use the shim database and the appcompat thing and report whatever version. Then when the listed program is active, why not find a way to dynamically expose the required APIs of the ones we have or can emulate to just it or just during that time? Traditionally, that is only done in reverse, where Windows limits itself and reports an older version. But in limited cases, I don't see why forward won't work. But again, in the case of a game loader, what if the APIs and version you expose is good for the loader, but not for what it loads? Like if Origin will run, but TheSims4 or whatever gets confused (it might not, just using a name)? Oh, and if we are doing it by file names and credentials, then each newer program ran by the loader would need to be in the database. If the new loader is running old games, then no problem. But if modern, they might need the same treatment to trick them into running.