Xash3D no longer works on Windows XP

[Srandista]

Since end of August, provided binaries for x86 no longer works on Windows XP. The app refuse to start with following error message:

Access denied on file D:\Games\Xash3D\xash3d.exe!

"xash3d.exe is not a valid Win32 application."

The last working build is this one, the next one and all after that won't work. The braking point is this commit.

[a1batross]

Wow, thanks for finding the breaking commit!

[Srandista]

So the issue seems to be, that PE header is now set to 6.0 (Vista+) instead of 5.1 (XP+). Is it possible to set this in the new toolchain?

[a1batross]

I made a fix but didn't had time to push it today.

Why XP though? It's dead. Using Linux might be better for old hardware if you have it. For retrocomputing purposes, there is original Half-Life...

[SNMetamorph]

I made a fix but didn't had time to push it today. Why XP though? It's dead. Using Linux might be better for old hardware if you have it. For retrocomputing purposes, there is original Half-Life...

Yeah, if such minor fixes will not work, I think there is no any sense to trying to support WinXP anymore.

[mittorn]

Many old systems that capable to run hl normally and have only windows drivers, only can run windows up to xp normally, so anyway supporting winxp makes sence For example, almost all systems with SiS graphics, some old amd/ati and even most of nvidia because nouveau never worked correctly and old blob is gone. Half-life is something retro and supporting retro PCs makes sence. But this must be done with testing at least on XP VM (but better is to test on real hw). I do not see any issues with keeping c90 compatibility at least for minimal engine subset or mingw support, which both only require keping some macro workarounds, but @a1batross won't agree with me, and i do not have much time to maintain mingw or even old msvc support And... Before saying using linux on old hardware, show me where old hardware support in linux now? I do not see. I see wayland, i see FATpak, i see dropping all non-gallium mesa drivers, i see using opengl with shaders anywhere and dropping 2d acceleration, so no, there is no linux on most of legacy hardware except of some intel igpus. It does not matter how someone may hate winXP/win2000, but there is no linux or other OS distribution which can replace it completely

[a1batross]

XP is literally the worst Windows version, what are you talking about.

[a1batross]

I don't think XP support goes away (until we still can use VS2019 on GitHub Actions...).

Even SDL3 kinda supports XP. And I'm definitely looking forward to make an SDL3 port, and eventually making it the default (alongside with sdl2-compat for mods that call SDL2.dll functions).

[mittorn]

Why? What about win9x/me/vista? Or even win8? All this versions are worse. Of course if we talk about legacy hardware, winxp might be not best, but not worst. It's really heavy comparing to 2k, but 2k was buggy enough and missing some crt functions, so supporting it my add more headache. But all hardware being able to run HL on 2k will run HL on XP, maybe after some tweaking. So even if XP not best version for old hardware (some works better with 2k or even 98), it is most painless version to support such hardware. Yes, it does not mean you and only you must support XP. But this means this question should not be closed so any interested developer may help to maintain that support. I understand that not many developers wants to support XP, but you see mastodon post with XP on UEFI today. XP keeps some interest today. It's kinda like interest with 1998 year game in 2024 or NT4 on power macs. For me it's even more much interesting that supporting recent windows. Anyway almost all hardware running recent windows may run linux or even run xash with WSL2. Why you even supporting it, let's drop it lol

[mittorn]

Maybe just patch exe for XP or pre-build compatible launcher? But i think, trying to keep XP using recent MSVC toolchain is dead end, microsoft dropped it and it not supposed to work. If we want maintaining msvc runtime XP build, need keep it compatible with some older toolchain (2015? 2017? Or even 2013) or try clang with win7 SDK that allows targeting XP. Anyway, we can use older clang, xash3d does not use very new language features Or restore mingw support which looks more reliable for me (yes, this will require some macro work on exported APIs). But it we was able to do it in old engine, so it's possible for new too. At least it use same compiler options syntax like usual gcc and supports newer c standarts.

[mittorn]

I think, easiest solution if they drop this target, and of course, if someone find time to setup and test it is deploying win7sdk to CI and using clang. It even should be possible on linux host as clang supports targeting windows from linux without some wine wrappers

[a1batross]

Why? What about win9x/me/vista? Or even win8? All this versions are worse.

Who even cares about them? Their existence can be safely ignored.

There is only small percentage of people still jerking their meat on Windows XP. 7, 10 and 11 are more stable than this piece of crap. Not to mention, the last two are still getting bugfixes.

But all hardware being able to run HL on 2k will run HL on XP, maybe after some tweaking

Then why it should be our problem? As I said, for ALL your retrocomputing needs, there is an original Half-Life which was made for these legacy systems, and it runs much better on them than Xash which isn't your 1997 engine.

Legacy hardware gets legacy software (if there is no other option) and legacy software gets legacy treatment.

mastodon post with XP on UEFI today. XP keeps some interest today. It's kinda like interest with 1998 year game in 2024 or NT4 on power macs. For me it's even more much interesting that supporting recent windows

That's what being called retrocomputing these days. And my stance on it remains the same. Those old operating systems would better run old Half-Life (and you even get some goodies like A3D support which is awesome) than modern Xash which isn't built by legacy toolchain and mostly doesn't use paleolithic age dependencies.

To make myself clear, I'm not against supporting XP in 2024. For us, it's not that hard, again as long as there is VS2019 on CI (and yet we could run VS2019 on Wine, I use it, and it works) and SDL still supports it. The fix for this issue is literally a single-line patch that I already pushed.

What I'm against is, is the sacred cow status of XP. It's just an old software that had a longer lifespan than it deserved. It came out in early 00s, it was dropped by Microsoft in mid-2010s, and right now is mid-2020s. Build a museum for it, I don't know, but stop telling me how good it WAS and how good it is TODAY.

[a1batross]

Fixed in https://github.com/FWGS/xash3d-fwgs/commit/47a04df189fd81e6ca1328d117b40a6a597d7deb

[Srandista]

I made a fix but didn't had time to push it today. Why XP though?

Thanks for the fix. I only wanted it fixed, if it's not some major work required and for retro computing purposes only. I really don't use XP on daily basis, for that, as you said that OS is truly dead...