ah good to know, so far I've only tested Duke3D. Haven't gotten to Ion Fury or Shadow Warrior yet.

Are you able to play the latest build of Ion Fury with 9607? (It does look like 9631 works with Ion Fury)
I always have to use the fury.grp 90,416 from 9/14/2020 even on Windows 11.

Anytime I try the build with fury.grp 90,473 11/17/2021, then get the error compiling con files with eduke32.

Nice to see Ion Fury working with eduke32 on XP without having to hunt down unofficial builds though, mabye we can do a benchmark thread to show the devs how wrong they are as far as performance on old machines heh.

DosFreak wrote on 2022-04-26, 00:24:

Are you able to play the latest build of Ion Fury with 9607?

Oh, I was not aware there was any benefit of newer grp files. Back then, I read about plans for removal of some politically sensitive things, which would make me prefer the original release. I never looked into it since.
This is what I use: fury.grp = 24-08-2019, 90997289 bytes

Yup, I've got that one too.
It's just very confusing, you'd hope eduke32 would give you a decent error message when an unsupported .grp is used. As it stands a user wouldn't know that Ion Fury was supported, it is it's just older builds of eduke32 don't support newer builds of Ion Fury.

So something to look into would be reversing the broken commit and setting up automatic builds. Obviously it was broken on purpose as we can see from the above commit.

https://github.com/vogonsorg/EDuke32

gerwin wrote on 2022-04-24, 13:05:

I tested some recent eDuke Win32 builds in Windows XP x86. Last one to be compiled for NT5 and working properly is: eduke32_win […]
Show full quote

I tested some recent eDuke Win32 builds in Windows XP x86.
Last one to be compiled for NT5 and working properly is:
eduke32_win32_20210927
https://dukeworld.com/eduke32/synthesis/20210 … 9607-9741acb51/

This one also runs Ion Fury quite well. Better then the earlier special Ion Fury builds.
This one has texture filtering enabled for Duke 3D, though no filtering for VoidSW (=Shadow Warrior).
(The current latest does not have filtering for VoidSW either)

I read somewhere it is just a matter of enabling texture filtering with three console command, and indeed it is:
autoexec.cfg:

1r_useindexedcolortextures 0
2r_texfilter 5
3r_anisotropy 4 

This will enable filtering in both VoidSW and Ion Fury. eDuke32 for Duke Nukem 3D had it enabled by default already. Ion Fury console key is Shift-tilde, without shift it won't open. Note that some palette effects may not work with these settings. I suppose the eDuke32 developers had their reasons for disabling filtering by default.

Another thing I noticed recently; The same eDuke32+Ion Fury game install and executable v28-09-2021, on the same system, gives a big frame-rate difference depending on the OS.
Same open-area scene as loaded from a savegame. OpenGL Polymost renderer:
- Windows 7 x64: 91,8 fps
- Windows XP x86: 23,4 fps, regardless of settings.

I ran 3DMark 2005 where both OS score exactly the same. But that is DirectX. So I did OpenGL FurMark v1.20.2.0 and that one only slightly differs: WinXP=8 fps/448pt, Win7=9fps/521pt.

Edit: on a Windows XP x86 system with an NVidia GT 710 the frame-rate is fine, around 100 fps. Though there it shows an occasional glitched frame. So the frame-rate issue is specific to the AMD Radeon (HD7750 with Catalyst 13.1). No indication of a problem in "eduke32.log".

I was curious, and give it a shot to adapt and build the latest eDuke32 for XP. r10161 that is.
Download available here:
http://www.gb-homepage.nl/index.htm
in the "Downloads" section.

eDuke32 r10161 2022-09-14 back-ported to Windows NT 5 compatibility, GB 27-9-2022. […]
Show full quote

eDuke32 r10161 2022-09-14 back-ported to Windows NT 5 compatibility, GB 27-9-2022.

Updated 28-9-2022:
Will no longer crash when something is unexpected in joystick/game-pad preparation.
Will write a warning in the log-file instead. (menus.cpp)

This is an adaptation of the source code kindly provided here:
https://dukeworld.com/eduke32/synthesis/20220 … 0161-1585e73fc/

This is unofficial.
Do not complain to eDuke32 developers about the source-code and binaries provided here.
Also, use at your own risk.

Notes:
- The binaries were compiled and build with GCC 8.4.0 on Windows XP.
The binaries were tested to run on these systems:
Windows XP SP3 x86, Graphics: Radeon HD 7750 PCIe
Windows XP SP3 x86, Graphics: Radeon HD 6310 integrated in E-350
Windows XP SP3 x86, Graphics: NVidia GT 710 PCIe
Windows 7 SP1 x64, Graphics: Radeon HD 7750 PCIe
Windows 7 SP1 x64, Graphics: NVidia Geforce 210 PCIe
Windows 7 SP1 x64, Graphics: Intel HD Graphics 3000 integrated in i3-2310M
Windows 10 x64, Graphics: Intel HD620 integrated

- eDuke32 20210927 r9607 is the last one that can build for NT5 as-is.
The builds hereafter include the mimalloc library, this one:
https://github.com/microsoft/mimalloc/issues/138
The adaptation here removed this library.

- eDuke32 20211112 r9778 also uses includes the minicoro library, this one:
https://github.com/edubart/minicoro
AFAIK This puts the procedure that draws the buffer for polymost OpenGL
in a separate thread. It will build for NT5 but will fail to create the
thread at runtime: "Create context error", after the launcher.
The adaptation here uses the old methods.

- Two other small adjustments were NT6 strings functions in loguru.cpp
and a mutex/pthreads library workaround For MinGW32 (mutex-fix folders).

- The original source files were put in a zip file before making changes.
The changes were marked with comment "GB 2022".
I did not dive into the background of every change that I made.
Care was taken to check the diffs for mimalloc/minicoro at github here:
https://github.com/tomkidd/eduke32/
still, it is possible that something is not right.

- The Polymost OpenGL engine can give poor frame-rates. It depends a lot
on the system and the OS. Ion Fury is much more taxing as well.
For older systems, maybe consider this last build with the old style
OpenGL 1.1 Polymost rendering:
https://dukeworld.com/eduke32/synthesis/20180212-6650/
Or use the classic software rendering option.

Nice!
Latest Ion Fury build works with it as well.

Looks like there are still some calls caused by mingw to Vista specific APIs but at least it's working.

1GetProcAddress(0x77C10000 [MSVCRT.DLL], "_localtime32_s") called from "FURY.EXE" at address 0x0075E3D1 and returned NULL. Error: The specified procedure could not be found (127).
2GetProcAddress(0x7C800000 [KERNEL32.DLL], "ReleaseSRWLockExclusive") called from "FURY.EXE" at address 0x0069BA99 and returned NULL. Error: The specified procedure could not be found (127).
3GetProcAddress(0x7C800000 [KERNEL32.DLL], "AcquireSRWLockExclusive") called from "FURY.EXE" at address 0x0069BAAE and returned NULL. Error: The specified procedure could not be found (127).
4GetProcAddress(0x7C800000 [KERNEL32.DLL], "TryAcquireSRWLockExclusive") called from "FURY.EXE" at address 0x0069BAC3 and returned NULL. Error: The specified procedure could not be found (127)

I need to see what happens if I compile your source with the mingw-w64 provided via Linux distros since unlike the Windows builds they aren't compiled with posix and also don't pull down posix compiled binaries from pacman, pthread is usually what causes issues like the above for XP and below. Without it I can compile for 95+,NT3.51 to XP with Mingw-w64 without any hacking. Last time I verified this was with MINGW-W64 w/ GCC 8.1.0. Think I might have both windows (MSYS2) and Linux compilation environments saved.

Did a quick test with Xompie w/ kernel32 (for those who want to use Vanilla XP) option on fury.exe and seemed to resolve the SRW errors above.

DosFreak wrote on 2022-10-05, 00:11:

Looks like there are still some calls caused by mingw to Vista specific APIs but at least it's working.

Good find. One lead I was following ends at libSDL2.a of all things.
libSDL2.a / SDL2.dll v2.0.15 or later has NT6 "AcquireSRWLockExclusive" etc. mentioned internally.
I have a few games running with these newer SDL2 version without issues. Dependency Walker has no issues it either.
On a related note:
SDL2 v2.24 actually broke Windows XP compatibility unintentionally, and v2.24.1, released 30 minutes ago, fixed it again. 😀

As for the MSVC Redist XP compatibility, I have this link stored:
https://github.com/abbodi1406/vcredist/issues/13
v14.28.29213.0 is the last compatible one. Newer ones will install fine, but may crap out at some point.

Below is also a compatibility list of MinGW libraries, that I made this week. I figured might be practical to gather the compatible ones while they are still easily available. The list is bit of a work in progress, and many are the current versions.

Windows XP x86 compatible, or sufficiently compatible mingw-w64-i686-allegro-5.2.4-2-any - Last XP mingw-w64-i686-brotli-1.0.9-5 […]
Show full quote

Windows XP x86 compatible, or sufficiently compatible
mingw-w64-i686-allegro-5.2.4-2-any - Last XP
mingw-w64-i686-brotli-1.0.9-5-any - Exe is NT6
mingw-w64-i686-bzip2-1.0.8-2-any
mingw-w64-i686-cairo-1.17.4-4-any - Last non-memdup2
mingw-w64-i686-flac-1.3.4-2-any
mingw-w64-i686-fmt-9.1.0-1-any
mingw-w64-i686-freetype-2.12.1-1-any - Problematic
mingw-w64-i686-glib2-2.44.1-2-any
mingw-w64-i686-glib2-2.54.2-1-any - Problematic
mingw-w64-i686-graphite2-1.3.14-2-any
mingw-w64-i686-harfbuzz-5.2.0-1-any - 1 Exe is NT6
mingw-w64-i686-libdeflate-1.8-2-any
mingw-w64-i686-libjpeg-turbo-2.1.4-1-any - Turbo is NT6
mingw-w64-i686-libogg-1.3.5-1-any
mingw-w64-i686-libpng-1.6.38-1-any
mingw-w64-i686-libsamplerate-0.1.9-1-any
mingw-w64-i686-libsndfile-1.1.0-1-any
mingw-w64-i686-libtheora-1.1.1-7-any
mingw-w64-i686-libtiff-4.2.0-1-any - Problematic
mingw-w64-i686-libtiff-4.4.0-6-any - Problematic
mingw-w64-i686-libvorbis-1.3.7-1-any
mingw-w64-i686-libvpx-1.12.0-1-any
mingw-w64-i686-libwebp-1.0.0-1-any - Last XP
mingw-w64-i686-luajit-2.1.0_beta3-2-any
mingw-w64-i686-openal-1.22.2-1-any - Exe is NT6
mingw-w64-i686-opus-1.3.1-4-any
mingw-w64-i686-pixman-0.40.0-2-any
mingw-w64-i686-pkgconf-1.8.0-2-any
mingw-w64-i686-readline-8.1.002-2-any
mingw-w64-i686-SDL-1.2.15-9-any
mingw-w64-i686-SDL2_image-2.6.2-1-any
mingw-w64-i686-SDL2_mixer-2.6.2-1-any
mingw-w64-i686-SDL2_net-2.2.0-1-any
mingw-w64-i686-SDL2_ttf-2.20.1-1-any
mingw-w64-i686-SDL2-2.0.22-2-any
mingw-w64-i686-tinyxml-2.6.2-5-any
mingw-w64-i686-tinyxml2-9.0.0-1-any
mingw-w64-i686-unrar-6.1.7-1-any - is exe only
mingw-w64-i686-wined3d-1.9.2-1-any.pkg
mingw-w64-i686-wxwidgets3.2-common-libs-3.2.1-1-any
mingw-w64-i686-xz-5.2.6-1-any - Liblzma-5
mingw-w64-i686-zlib-1.2.12-1-any

Not quite XP Compatible, NT6 calls
mingw-w64-i686-cairo-1.17.6-1-any - glib2 memdup2 call
mingw-w64-i686-fluidsynth-2.1.6-1-any - Problematic
mingw-w64-i686-fluidsynth-2.2.0-2-any - Last-NT5 - Problematic
mingw-w64-i686-fluidsynth-2.2.9-1-any
mingw-w64-i686-glib2-2.66.4-1-any
mingw-w64-i686-libwebp-1.0.1-1-any
mingw-w64-i686-mimalloc-2.0.3-1-any
mingw-w64-i686-SDL2-2.24.0-1-any - Unintentional - fixed in v2.24.1
mingw-w64-i686-wined3d-3.8-1-any
mingw-w64-i686-zstd-1.5.2-2-any

DosFreak wrote on 2022-10-05, 00:11:

Did a quick test with Xompie w/ kernel32 (for those who want to use Vanilla XP) option on fury.exe and seemed to resolve the SRW errors above.

Are you saying the Fury.exe I provided does not run as-is on Windows XP SP3 (+ POSready updates)?
If I was using kernel-ex tricks for it, I would have written that.

As an addendum to my MinGW list. it may be annoying that the WIN32 zstd unpacker for MinGW packages is NT6 only, unless you build your own. But this 7-zip plugin seems to work very well: https://www.tc4shell.com/en/7zip/modern7z/

Ion Fury (software mode) first level and then quitting I received an error which is what caused me to check with dependency walker. This was tested with regular XP SP3 with POS updates and Visual C++ v14.28.29213.0 not that the redist matters in this case.

I feel your pain. Yeah awhile back when working on DOSBox SVN for 95,NT3.51,NT4 I had alot of issues with original Mingw and MSYS with outdated binaries and had to track down updated versions. Eventually I realized I could just use regular MinGW (not Mingw-W64) with MSYS2 by just copying the binaries over. That made things much easier but there were still quirks since MSYS2 and pacman are still out of date and flaky, eventually I moved to cross compiling for Windows using Linux or WSL since MSYS is just a pale imitation anyway. When I verified MinGW-W64 WIN32 thread would work for Pentium Pro+ for 95+ then I was much happier, haven't yet bothered to compile MinGW-W64 for < Pentium Pro support to eliminate the need for MinGW but it is possible.
I was never concerned with actually compiling on Windows XP, all of my compiling for older operating systems has always been with the latest Linux or Windows OS to make things easier especially with browsing, security and certificate issues.

DosFreak wrote on 2022-10-05, 02:56:

Ion Fury (software mode) first level and then quitting I received an error which is what caused me to check with dependency walker. This was tested with regular XP SP3 with POS updates and Visual C++ v14.28.29213.0 not that the redist matters in this case.

I am puzzled by this. To investigate it better I uploaded new builds, which are dynamically linked to SDL2.dll. I supplied the official SDL2.dll v2.0.22 there too. As I already mentioned, NT6 calls like "AcquireSRWLockExclusive" are not found inside any of these new executables, but are found in SDL2.dll v2.0.15+. So you could even run them with SDL2.dll v2.0.14 and there would no way to get a call to "AcquireSRWLockExclusive". On my XP systems there are no errors with any of it.

DosFreak wrote on 2022-10-05, 02:56:

I was never concerned with actually compiling on Windows XP, all of my compiling for older operating systems has always been with the latest Linux or Windows OS to make things easier especially with browsing, security and certificate issues.

Yes you told me before. It is good to have different build environment options. For now my Windows XP build environment is chugging along nicely, it is just a hobby in itself too see how it can manage. So far, whenever MSVC10 failed to build, then MinGW8 managed it, or the other way around.

I'll look into this and see if I can see where they are coming from.

On the topic of Duke Nukem 3D, but without anything Ion Fury:
I also uploaded a rebuild and slightly adjusted version of the Duke3Dw port by proasm. Called it v4.4.0.1.

This one is a nice alternative for slower systems. But the latest official v4.4.0 has a small bug that makes it crash on Windows XP. That was fixed.

(I would have liked to just email the fix upstream, but it seems like it project there is finished and I cannot find contact information.)

Nice the last version I have listed as working for XP is v4.32.

For Shadow Warrior it's v4.33b3 but I think that's the last version anyway, nice thing about that ver is it works on 98-ME and XP whereas for 95 and 2000 you have to use v4.32 (which may have a save corruption bug)

Loaded up eDuke32 r10161 back-port on a bare install of Windows XP with no updates, same issue. May have time this weekend to compile.

DosFreak wrote on 2022-10-14, 00:51:

Loaded up eDuke32 r10161 back-port on a bare install of Windows XP with no updates, same issue. May have time this weekend to compile.

I just did the same. A fresh stock Windows XP SP3 install on real hardware, with a Nvidia GT 710 that can satisfy the OpenGL requirement. No updates or runtimes of any kind. I cannot reproduce the problem. The r10161 back-port games start and run fine.

What I have seen before, is that eDuke32 v2021-09 official and this 2022 do not run on XP with intel HD2500 graphics. It just exits after the launcher. IIRC it shows " Runtime terminated in an unusual way". For that I tried a build with the "USE_OPENGL := 0" option, and then it does run. Though the classic/software renderer then has a lower framerate compared to a normal build. I suppose classic normally also uses some OpenGL functions.
I see no point in sharing that build. Better use the faster eDuke32 early-2018 on a system like that. Or fix the issue in a proper way.

DosFreak wrote on 2022-10-14, 00:51:

For Shadow Warrior it's v4.33b3 but I think that's the last version anyway, nice thing about that ver is it works on 98-ME and XP whereas for 95 and 2000 you have to use v4.32 (which may have a save corruption bug)

From my tests back then, SWP 4.3.2 for sure has the savegame corruption. I noticed some random crashes as well.
SWP 4.2.7 and 4.2.8 crash when trying to control the mini racing cars in Seppuku Station.
I noted that among the genuine proasm releases SWP 4.2.6 is preferable. Even if it is lacking the nicer mini-HUD.

Fortunately there is SWP 4.3.3 beta 4, from 22-04-2019. It have no complaints about that one. As you may know, SWP 4.3.3 builds are a fix-up attempt by Hendricks266 here, not proasm. But I see that the the last release there is Beta 3. So I must have found Beta 4 on the 4duke forums. Edit: Here

Okay figured it out. If you set a resolution that exceeds your desktop resolution then you will receive the below error. This would probably come into play more with CRT monitors I'm thinking. Haven't tested with multiple LCD with different resolutions but as long as the max res in-game isn't higher than the desktop res then should be good.

First tested with default desktop res of 800x600 and any res above that crashed with the below.
Then set 1600x1200 and any res above that crashed.

Tested with: Software mode, Polymer Unchecked

"Microsoft Visual C++ Runtume Library"
"This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information".

Well that was fun.

DosFreak wrote on 2022-10-15, 18:34:

"Microsoft Visual C++ Runtume Library"
"This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information".

That is most likely an "assert" coded in somewhere, in eDuke32. Giving you that very unhelpful message Reference.
I already guarded another assert before, because eDuke32 did not like something while detecting a gamepad. Before it just asserted the same way, which looks like a crash. Same thing when trying to run it on intel Graphics on WinXP.

I have no reason to believe my back-port has issues on itself. They are inherited.
So I can try to find these two asserts that are still being annoying, then at least log a useful message, or fix it. Or instead, tinker with another project entirely, one that is more to my liking, less demanding.

heh, I'm just happy my Wndows builds are good and I can play the game(s). Thanks!