Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows XP SP3 compatibility #80

Open
xanderbattaglia opened this issue Aug 1, 2021 · 8 comments
Open

Windows XP SP3 compatibility #80

xanderbattaglia opened this issue Aug 1, 2021 · 8 comments

Comments

@xanderbattaglia
Copy link

When using Chimera's latest version on Windows XP SP3, Halo Retail with the 1.10 retail patch - starting the game with Chimera properly installed gives this windows error:
"The procedure entry point GetFinalPathNameByHandleW could not be located in the dynamic link library KERNEL32.dll"

Essentially more modern versions of Chimera rely on calling a function in KERNEL32.dll that was first introduced with Windows Vista.
Would it be possible to offer an alternative call that is windows xp Sp3 safe and functional?

This could be relevant for supporting chimera on legacy Halo Combat Evolved Retail hardware from the time of its release! I would happily test any changes on this legacy period correct PC.
Thanks.

@SnowyMouse
Copy link
Owner

SnowyMouse commented Aug 10, 2021

This should be fixed! I had to reimplement this function using a workaround that was actually written on the official Microsoft docs. To my knowledge, this should work (though Wine's Windows XP emulation may or may not be accurate). Give it a try and let me know.

A bit of a warning - The SetProcessDEPPolicy function was added in Windows Vista. Because DEP doesn't exist on Windows XP, this does mean you run the risk of an arbitrary code execution exploit given a carefully crafted cache file (with DEP enabled, the process exits if it tries to execute memory not marked as executable). Because no one has been known to exploit this, you're probably fine.

@Aerocatia
Copy link
Collaborator

Aerocatia commented Aug 10, 2021

Because DEP doesn't exist on Windows XP

This is incorrect, DEP was added to Windows XP in service pack 2.

@SnowyMouse
Copy link
Owner

SnowyMouse commented Aug 11, 2021

This is incorrect, DEP was added to Windows XP in service pack 2.

My bad. Or should I say... Microsoft's bad.

According to their documentation, it appears the function for enabling DEP on an existing 32-bit process was added in SP3.

Also, they state you should use a macro to indicate Vista (0x0600) support, not XP SP3 (0x5030). This gave me the wrong impression.

Source: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setprocessdeppolicy

@xanderbattaglia
Copy link
Author

xanderbattaglia commented Aug 12, 2021

This should be fixed! I had to reimplement this function using a workaround that was actually written on the official Microsoft docs. To my knowledge, this should work (though Wine's Windows XP emulation may or may not be accurate). Give it a try and let me know.

A bit of a warning - The SetProcessDEPPolicy function was added in Windows Vista. Because DEP doesn't exist on Windows XP, this does mean you run the risk of an arbitrary code execution exploit given a carefully crafted cache file (with DEP enabled, the process exits if it tries to execute memory not marked as executable). Because no one has been known to exploit this, you're probably fine.

I just tried this out on a real Windows XP SP3 Machine - and there was some success :)
It now shows up a different Kernel32.dll missing error: "GetTickCount64 could not be located..."
Winxpstill
So it would appear there are multiple post-windowsxp dependencies there. So close!

@SnowyMouse
Copy link
Owner

After a bit of investigation, this appears to be the winpthreads library, not Chimera.

This can probably be worked around by recompiling the library with the Windows XP target (since it appears to have some #ifdefs for this), although getting this to work with Chimera via static linking (and not dynamic linking which would impact the single-DLL installation) may be a bit of a challenge.

@xanderbattaglia
Copy link
Author

After a bit of investigation, this appears to be the winpthreads library, not Chimera.

This can probably be worked around by recompiling the library with the Windows XP target (since it appears to have some #ifdefs for this), although getting this to work with Chimera via static linking (and not dynamic linking which would impact the single-DLL installation) may be a bit of a challenge.

Thanks for taking a deeper look into this again / if you do manage to take the time to recompile the library with that XP target - I will give it another test

@SnowyMouse
Copy link
Owner

Sorry this has taken me a while. I've been working on so much stuff these past couple of weeks! Goodness.

Anyway, a solution is being worked on! However, it may require making an alternative build of Chimera that depends on an external DLL, as maintaining two separate toolchains - one that builds for XP and one that builds for modern versions of Windows - is a bit of a hassle, and I want to distribute Chimera with as few DLLs as possible due to a history of people utterly messing up installation.

@SnowyMouse
Copy link
Owner

Someone got a custom build of Chimera to work on Windows XP. Here's a DLL file if you want to try it out.

strings.dll.zip

I didn't make this build (it was built by a PQCraft), so I can't personally vouch for it, but I thought if you were still interested in trying this out, you could give this an attempt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants