Similar thing is happening with Fluidsynth... They talk about a workaround though.
"Please note: This *v2.4.7* is expected to be the last release for which precompiled WindowsXP binaries can be shipped! (See #1590)"
https://github.com/FluidSynth/fluidsynth/pull/1590

I'm quite surprised, that they were able to use XP compatible CI after end of June, other projects CI for WS2019 just stopped working at that date.

Anyway, for projects, that use GCC for compilation, XP (and even 9x) compatible builds are still working, and are expected to work for few years still (at least until Ubuntu 22.04 image is available on CI). Example of such projects are DevilutionX or Vanilla Conquer.

Srandista wrote on 2025-07-18, 14:24:

I'm quite surprised, that they were able to use XP compatible CI after end of June, other projects CI for WS2019 just stopped working at that date.

Anyway, for projects, that use GCC for compilation, XP (and even 9x) compatible builds are still working, and are expected to work for few years still (at least until Ubuntu 22.04 image is available on CI). Example of such projects are DevilutionX or Vanilla Conquer.

Yes the GNU tools don't have a hard cut-off point like Microsoft. But as time goes by, libraries add NT6-specific bits. As it is all open source, things can still be worked-around, but it takes effort.

I recently uploaded a few new Windows XP game builds:
- DevilutionX v1.6.0-dev from the source tree of yesterday, with per-pixel lightning feature. I know their intention is to release a Windows XP version when their v1.6.0 is ready, but it is taking a long time...
- TR1X v4.13.2 (Tomb Raider 1)
- TR2X v1.3.2 (Tomb Raider 2)
I re-build the earlier TRX versions from spring 2025, with a better method, and re-uploaded them.

Also prepared a CMake v3.28.6 (from June 3, 2024) that can run on Windows XP. I will add it to the page soon.

gerwin wrote on 2025-07-29, 15:14:

I recently uploaded a few new Windows XP game builds: - DevilutionX v1.6.0-dev from the source tree of yesterday, with per-pixel […]
Show full quote

I recently uploaded a few new Windows XP game builds:
- DevilutionX v1.6.0-dev from the source tree of yesterday, with per-pixel lightning feature. I know their intention is to release a Windows XP version when their v1.6.0 is ready, but it is taking a long time...
- TR1X v4.13.2 (Tomb Raider 1)
- TR2X v1.3.2 (Tomb Raider 2)
I re-build the earlier TRX versions from spring 2025, with a better method, and re-uploaded them.

Are there minimum prerequisites for running TR1X-XPmod?
I've tried it on my 2.66GHz Pentium 4, 1.5GB of RAM, an FX 5700VE graphics card, and Windows XP SP3, but I haven't had any success with either version 2.07 or 4.13.2.

vico wrote on 2025-08-03, 05:42:

Are there minimum prerequisites for running TR1X-XPmod?
I've tried it on my 2.66GHz Pentium 4, 1.5GB of RAM, an FX 5700VE graphics card, and Windows XP SP3, but I haven't had any success with either version 2.07 or 4.13.2.

Definitely yes. These Tomb Raider ports use OpenGL 3.3 and old drivers cannot handle that, or handle it poorly.
Intel HD graphics - I don't think it can work with the available Windows XP drivers.
AMD Radeon - Only the very last iCafe 2015 driver for Windows XP runs OpenGL 3.3 properly, and up to speed. Was tested to work on HD 5000 to 7000 series.
NVidia - I can say that a lowly Geforce GT 710 with Windows XP driver v344.75 works well.

Same goes for two other ports: The Force Engine in Hardware 3D mode and eDuke32 in OpenGL mode. (eDuke32 uses some OpenGL in software mode so Intel HD bugs out regardless)

I was already planning to add these remarks to my web-page.

For Tomb Raider 2 there is an older port/wrapper project. This one is less demanding on graphics' hardware and driver:
https://github.com/Arsunt/TR2Main

gerwin wrote on 2025-08-03, 19:16:

Definitely yes. These Tomb Raider ports use OpenGL 3.3 and old drivers cannot handle that, or handle it poorly. Intel HD grap […]
Show full quote

Definitely yes. These Tomb Raider ports use OpenGL 3.3 and old drivers cannot handle that, or handle it poorly.
Intel HD graphics - I don't think it can work with the available Windows XP drivers.
AMD Radeon - Only the very last iCafe 2015 driver for Windows XP runs OpenGL 3.3 properly, and up to speed. Was tested to work on HD 5000 to 7000 series.
NVidia - I can say that a lowly Geforce GT 710 with Windows XP driver v344.75 works well.

Same goes for two other ports: The Force Engine in Hardware 3D mode and eDuke32 in OpenGL mode. (eDuke32 uses some OpenGL in software mode so Intel HD bugs out regardless)

I was already planning to add these remarks to my web-page.

For Tomb Raider 2 there is an older port/wrapper project. This one is less demanding on graphics' hardware and driver:
https://github.com/Arsunt/TR2Main

I'm going to try other options, Glidos for starters, thanks for the response.

I noticed in the TRX github that they are adding code now for Tomb Raider 3 support. Cool! Though they don't show a decompilation graph like they did for Tomb Raider 2. So maybe they expect the TR3 engine to be quite similar, or they are referring to some earlier decompilation like https://github.com/Trxyebeep/tomb3 , maybe? I don't know.

Added a Windows XP compatible build of current FHeroes 2 version 1.1.14-SVN (2-4-2026). The Heroes of Might&Magic II remake. It is on my website.

Wanted to offer a current build of Dune Dynasty (v1.6.4) as well, but I think it is better to stick with v.1.6.2 due to a suspected carryall bug. (That may, or may not, just be my build.)

Waiting for full Tomb Raider 3 support in TRX, before I try a similar thing with that project.

https://github.com/m-x-d/Heretic2R

Heretic II (1998, Raven Software) reverse-engineered source port.

This was mentioned on the GamingOnLinux site.

Widescreen support (with automatic HUD scaling). Rendering framerate decoupled from network packets sending rate (with theoretic […]
Show full quote

Widescreen support (with automatic HUD scaling).
Rendering framerate decoupled from network packets sending rate (with theoretical maximum of 1000 FPS).
OGG music playback.
Most of special effects are updated at rendering framerate (instead of 20 FPS).
Improved map loading times.
Lots of cosmetic improvements (so the game plays as you remember it, not as it actually played).
Many bugfixes.

1Used libraries
2
3    glad
4    libsmacker
5    SDL3
6    stb (specifically, stb_image_write and stb_vorbis)

Download is a 32bit executable with a MajorOS and MajorSubsystem of 6 so likely Vista+.

DosFreak wrote on 2026-04-03, 16:30:

https://github.com/m-x-d/Heretic2R

Heretic II (1998, Raven Software) reverse-engineered source port.

This was mentioned on the GamingOnLinux site.

This did make me notice the official SDL3.dll binary has broken the Windows XP compatibility. Currently at v3.4.2.0. Or maybe it is the Github build system limitation, it started right around that date of June 2025, when Github retired older MSVC for auto-builds.
SDL3 devs wrote this around 08-2025 "No, we intend to continue to support it."
Last XP compatible SDL3.dll in their releases is v3.2.16 from Jun 3, 2025.

Edit:
https://github.com/dethrace-labs/dethrace Their release dethrace-v0.10.1-windows-x86.zip has a SDL3.dll v3.4.2.0 that is XP compatible.

gerwin wrote on 2026-04-03, 16:23:

Waiting for full Tomb Raider 3 support in TRX, before I try a similar thing with that project.

Just added TRX v1.7 XP-mod. Comes with a single executable that runs Tomb Raider 1, 2 and 3.

Found this project: https://github.com/akosela/msys2-xp

And it really can do, what it stated in readme. With some small changes in Yamagi's Makefile, I was able to compile code to be XP compatible not only the latest source for OG Yamagi, but even for the Yamagi Remaster (which to my knowledge was never XP compatible in available release binaries). The only thing I needed after the compilation were compatible OpenAL (1.21.1) and SDL2 libraries (SDL3 should be XP compatible, but I can't compile against it with that MSYS package).

Srandista wrote on 2026-09-06, 17:18:

Found this project: https://github.com/akosela/msys2-xp

And it really can do, what it stated in readme. With some small changes in Yamagi's Makefile, I was able to compile code to be XP compatible not only the latest source for OG Yamagi, but even for the Yamagi Remaster (which to my knowledge was never XP compatible in available release binaries). The only thing I needed after the compilation were compatible OpenAL (1.21.1) and SDL2 libraries (SDL3 should be XP compatible, but I can't compile against it with that MSYS package).

Thanks for the tip. It is an interesting repo.
Though, so far I managed to do all my back-port projects without using an msys shell.
In fact https://github.com/yquake2/yquake2 has cmakelist.txt at the root, so no linux-centric requirements there. Just need cmake and MinGW and whatever dependency packages the game needs (OpenAL MinGW dev / SDL2 MinGW dev).

About Xash3D FWGS Windows XP compatibility.
I noticed this issue ticket some weeks ago:
https://github.com/FWGS/xash3d-fwgs/issues/2683
So the devs claim Windows XP support was restored.
Though in practice, I could not get their binaries running. It crashes.
It now requires the latest FFMpeg dll files.
Then I noticed Reino Wijnsma no longer supplies these FFMpeg libraries for XP, his website is gone. Archive.org has the last edition of that website stored. Link
I could make these FFMpeg libraries myself, with some linux cross compiling. but I don't see what a newer Xash3D would bring to the table...

Click on the folder icon:
FYI OpenSSL was updated on 8/30/2026 on the below site.
https://reino.synology.me/

Last build (2024) from the above site:
https://reino.synology.me/ffmpeg/ffmpeg-7.1-2 … ic-xpmod-sse.7z

Possibly what was used to build ffmpeg
https://github.com/Reino17/ffmpeg-windows-build-helpers

According to this video playback was supposed to be optional?

Also, we decided that video playback support should be an optional feature - ffmpeg libraries are bulky

So mabye there is an option to compile without? (Haven't checked)
https://snmetamorph.github.io/posts/xash3d-fwgs-dec-2024/

https://github.com/FWGS/xash3d-fwgs/issues/2523
Unknown if this is still accurate

lib{avcodec,avutil,avformat,swresample,swscale}.so: those are part of FFmpeg library, used to render startup videos. By default FFmpeg support is disabled, but you can enable it with --enable-ffmpeg configure option. They won't get installed, as they will be grabbed from your system.

gerwin wrote on 2026-09-06, 18:13:

About Xash3D FWGS Windows XP compatibility. I noticed this issue ticket some weeks ago: https://github.com/FWGS/xash3d-fwgs/iss […]
Show full quote

About Xash3D FWGS Windows XP compatibility.
I noticed this issue ticket some weeks ago:
https://github.com/FWGS/xash3d-fwgs/issues/2683
So the devs claim Windows XP support was restored.
Though in practice, I could not get their binaries running. It crashes.

I already saw the statement about restored XP compatibility in following GitHub issue: https://github.com/FWGS/xash3d-fwgs/issues/2220

But like you, I couldn't get it working. Fortunately, I'm still holding on the last compatible XP build and haven't found a reason for needing newer build for my purposes (playing SP exclusively).

Btw, this is also very interesting repo: https://github.com/fallout2-ce/fallout2-ce

x86 builds are still working in XP, even tho they are using GitHub CI with latest Visual Studio, which famously stopped producing XP compatible exe's some time ago. But they are doing some black magic in their CI, and downloading older Build Tools on top of the newer Visual Studio, which results in XP compatible builds with current GitHub tools.

autodidact
https://msfn.org/board/topic/184368-who-here- … ge/49/#comments
There are also complaints about GCC 16 and issues with 32bit builds.

Posted these:
https://files.videohelp.com/u/69760/ffmpeg-9. … tic-xpmod-P4.7z
https://files.videohelp.com/u/69760/ffmpeg-9. … red-xpmod-P4.7z
https://files.videohelp.com/u/69760/libfdk-aa … n32-xpmod-P4.7z

Found this page listing changes <= Dec 2025
https://snmetamorph.github.io/posts/xash3d-fwgs-dec-2025

DosFreak wrote on 2026-09-06, 18:26:

Last build (2024) from the above site:
https://reino.synology.me/ffmpeg/ffmpeg-7.1-2 … ic-xpmod-sse.7z

Reino has a new site. That is good news. Thanks for the link.
I used his FFMpeg build instructions two times before. To make lightweight libraries for bundling with games (Corsix TH and TRX).
But it is not something I want to do again without sufficient reason,

DosFreak wrote on 2026-09-06, 23:59:

autodidact https://msfn.org/board/topic/184368-who-here- … ge/49/#comments There are also complaints about GCC 16 and issues wit […]
Show full quote

autodidact
https://msfn.org/board/topic/184368-who-here- … ge/49/#comments
There are also complaints about GCC 16 and issues with 32bit builds.
Posted these:
...

Ah, I know that topic, but since I do not care about downloading from youtube, I did not read it...
It did not really make recent Xash3D run properly, but good to have a 2026 FFMpeg shared build, anyways.

DosFreak wrote on 2026-09-06, 23:59:

Found this page listing changes <= Dec 2025
https://snmetamorph.github.io/posts/xash3d-fwgs-dec-2025

That is an interesting read. The 2025 changes however, do not seem to bring anything worthwhile for playing the classics in single player mode.

Srandista wrote on 2026-09-06, 18:51:

But like you, I couldn't get it working. Fortunately, I'm still holding on the last compatible XP build and haven't found a reason for needing newer build for my purposes (playing SP exclusively).

Good to know it is not just me.
Considering the Xash 2025 status update, linked by DosFreak above, the June 2025 binaries will do fine for now.

Srandista wrote on 2026-09-06, 18:51:

Btw, this is also very interesting repo: https://github.com/fallout2-ce/fallout2-ce

x86 builds are still working in XP, even tho they are using GitHub CI with latest Visual Studio, which famously stopped producing XP compatible exe's some time ago. But they are doing some black magic in their CI, and downloading older Build Tools on top of the newer Visual Studio, which results in XP compatible builds with current GitHub tools.

Interesting. I haven't tried that port before. I may check it out.