Again thanks for testing compatibility, and sharing your findings.

DosFreak wrote on 2022-05-08, 20:55:

So was checking out Vista 64 and decided to see if Ion Fury would run.
The build with 11-17-2021 grp does run but it has the same issue as later builds of eduke32, ran it through dependency walker and saw this: https://docs.microsoft.com/is-is/windows/win3 … readdescription
So guess later builds of eduke32 are for Windows 10/2016+ 🙄

Noted. Glad there are more portable and functional packages from earlier dates (as below).

DosFreak wrote on 2022-05-08, 20:55:

Use this build for XP with builds of Ion Fury older than 11-17-2021 eduke32_win32_20211006-9651-a891732fd

I think you are mistaken there. In the other thread we talked about the nastiness starting right after eduke32_win32_20210927, 2021-09-27. I tested it again and that 20211006-9651-a891732fd is no good.

DosFreak wrote on 2022-05-01, 02:36:

It's been awhile since I've had to use it but there is always EDITBIN which could be tried with the v141 target
EDITBIN from VS2005 C++ Command prompt "editbin /subsystem:windows,4.00 /osversion:4.0 filename"

Yes that would be a more proper way, compared to the PE-header hex-edit that I do manually. Though I am confident that both methods give exactly the same result.

DosFreak wrote on 2022-05-01, 02:36:

Something else to keep in mind is that newer builds of the VS2019 redist broke XP support awhile back so you have to use an older version.

I heard something like that before. Do you happen to know more about that, maybe? Like how to identify which packages/updates broke it, and how this bug shows itself in the build process and/or in the resulting build.

DosFreak wrote on 2022-05-08, 12:03:

For less than 2000 need to see what the latest build of eduke32 that compiles with SDL 1.2 and work from there.

Did anyone ever try to build an SDL2.dll for Windows 98? I checked it the other day, and some of the older SDL2 versions have only a few calls that are unrecognized there. (I made some depends.exe listings, but they are at home...) It would open up a lot of projects to run on Windows 98, I am just not motivated to bother with it myself. Since XP compatibility is already breaking in many projects these days, and it is taking enough effort already to "un-regress" some of those.

Visual C++ redist
I have the below vers along with this note

"I’ve investigated a bit further - The 2015 to 2019 Visual C++ redistributable ( version 14.29.29917) that shipped with VS 2019 Update 10 Preview 1 does work correctly with a VS 2017 XP app (v141_xp) - so the breakage occured somewhere between VS 2019 Update 10 Preview 1 and Preview 2"

I have these files saved:
VisualCppRedist_AIO_x86_XP_35 (tested) 14.28.29213.0
VisualCppRedist_AIO_x86_x64_44 (untested) 14.28.29910.0

I believe the issue exhibits when you install the later unsupported versions of the redist (which still install when they shouldn't) and they reference an API that doesn't exist in XP.

SDL
The only previous Windows OS less than Windows XP I am aware of that was worked for SDL2 were the rawinput changes to make SDL2 work on Windows 2000 without using the BWC kernel. I have that uploaded to the SDL2 repo on vogonsorg. It was made for SDL 2.0.5 but I doubt much has changed with that code in the latest ver of SDL2 so shouldn't be too much of an issue to get it working in the latest ver.
https://github.com/vogonsorg/SDL/issues/1

I believe for 98-ME there was talk of unicode, the rawinput change for 2000 would need to be looked at to see if it would work or could be adapted to 9x, any kernel32 specific XP apis would need to be dealt with.
For 95-NT4 support the issue there would be 95 tops out at DX8 and I think SDL2 only supports DX9 but considering SDL2 works on OS/2.....

For 98 and ME SDL2 can be run with kernelex so possibly may be a better route since kernelex is open source and does receive updates at msfn so it's somewhat still in development.

gerwin wrote on 2022-05-09, 13:08:

DosFreak wrote on 2022-05-08, 13:10:

It looks like DevilutionX 1.4.0 requires Windows 7 now.

You are right, it appears the newly required discord integration dll adds most of the NT6 calls.
I build a DevilutionX v1.4.0 Windows XP compatible package yesterday. It is on my website. No discord integration in that one, I disabled the multiplayer/internet option as well.

Awesome!

gerwin wrote on 2022-05-09, 13:38:

DosFreak wrote on 2022-05-08, 20:55:

Use this build for XP with builds of Ion Fury older than 11-17-2021 eduke32_win32_20211006-9651-a891732fd

I think you are mistaken there. In the other thread we talked about the nastiness starting right after eduke32_win32_20210927, 2021-09-27. I tested it again and that 20211006-9651-a891732fd is no good.

Yup, Sorry meant Vista. Corrected it and added OpenGL info.

NT4 testing

devilution - works
Chocolate Doom,Heretic,Hexen,strife 2.3.0 works
Crispy Doom 3.2 works
Doom Legacy 1.48.8 works
Rude 2.5.0c works
Zdoom32 2.8.6 works
ZdoomLE 2.8.1f works
Hexen II Hammer of Thyrion 1.5.9 and
darkplacesengine20110328beta2 works
Engoo 277w works
ProQuake 4 4.93 works
qbism super8 v288 works
Quakeworld for DOS works (didn't test multiplayer)
Quakespasm 0.94.3 works
Tyrquake 0.70 works
Kmquake2 020 update 6 works
AprQ2 v1.211 works
ioquake3 1.35 SVN1286-2.1 works

The ID software games got lots of love, none so much for Build games. Eduke32 for win95 fails with a dinput error, Jonof and proasm no go.

Things to look into
https://www.doomworld.com/forum/topic/64091-d … -on-windows-95/

Pretty much done with 95,98,NT4 testing except for some oddballs to finish up.
Here's a sample of Quake port compatibility (I do have old tests for kernelex, BWC, OneCoreAPI but didn't test this go around)

Looking at the below candidates for fixing compatibilty are:
Quakespasm and TyrQuake for <NT4 assuming memory error isn't about not enough memory.
Vkquake for <Vista? Doubt there is a mesa equivalent for vulkan so nixing the vulkan requirement may be it. vkquake2 can be played on XP without vulkan.
Quakespasm spiked for <XP
Quakeworld for 95
FTEQW for 95 and NT4
qbism for 95
Dark Places for <XP
DirectQ for <2000
UQE for <XP. This probably isn't even worth bothering with....

95-98-ME-NT4
darkplacesengine20110328beta2
ProQuake4 4.93

95-98-ME
Quakespasm 0.90.1
TyrQuake 0.66
The latest version of both of these give a memory error even when the system has 512mb. The latest vers of these work on NT4 with 1gb but I didn't try NT4 with 512mb or 9x with 1gb

98-ME-2000-XP 32-64
FTEQW 6202

98-ME-NT4
Engoo 277w
Qbism Super8 v288
Quakeworld for DOS

2000
DirectQ 1.8.666b

DOS
qbism super8 DOS-9
QuakeWorld for DOS
Engoo 2.05d

NT4-2000-XP32-64
Quakespasm 0.94.3
TyrQuake 0.70

Vista 32
vkquake 1.04.1 (need to verify this one)

XP 32bit
Ultimate Quake Engine 1.13
Mark V 1099

XP 32-64
Quakespasm spiked
DarkPlaces 12-22-2018

Engoo was made in VC6 so it should work for Win95. On the other hand Engqsb.exe uses a 32bpp DirectX surface (for NT in mind because NT and Geforces are bad with handling palettes)

I should probably mention OpenArena's compatibility situation:

- The current about-a-decade-old, rotting, ugly, over-burdened with technical debt, nightmarish v0.8.8 release out there DOESN'T support Win98 unless with KernelEx. It does support 2000 and XP. (I didn't make this build. )
- The current OpenArena github engine DOES work for Windows 95/98/NT4 when compiled with MinGW32/GCC 4.7.2, enabled SDL1, and with ReactOS's wspiapi.h. (Win95 requires installation of Winsock2, which is definitely a pain on its own). I fixed a bunch of regressions there and I intend to maintain support (in the face of armchair devs who tell me to drop it). This engine has new features intended for a future release, but is compatible with the current OA 0.8.8 release.
- True Win95 compatibility (RTM) would mean ditching Winsock2 and probably some other thing IE3 comes with it depends on... however it's a "2000 spec" game, and some games in that time did do Winsock2, so this probably won't be dropped.
- The OA github engine can sort of run baseq3 (Quake3), but crashes with some maps and isn't recommended/supported. My last attempt to debug the crashes led to irrelevant parts of the code.

Thanks, great work! I'll see about giving it a try.

For anyone participating in that Quake 3 benchmark thread

7 64bit
ioquake3

95-98-ME-NT4
ioquake3-1.35_SVN1286-2.1.x86.exe

98-ME-2000-XP32-64
FTEQW 6202

2000
Quake3e quake3-1.32e-20201031

XP 32
Spearmint 1.0.3
Q3bers Q3Bers_GT-pack_20100926

XP 32-64
ioquake 3 6-12-2019
Quake3e latest ver

DosFreak wrote on 2022-05-09, 19:58:

"I’ve investigated a bit further - The 2015 to 2019 Visual C++ redistributable ( version 14.29.29917) that shipped with VS 2019 Update 10 Preview 1 does work correctly with a VS 2017 XP app (v141_xp) - so the breakage occured somewhere between VS 2019 Update 10 Preview 1 and Preview 2"

MS:

The last version of the Visual C++ Redistributable that works on Windows XP shipped in Visual Studio 2019 version 16.7 (file versions starting with 14.27).

Here's Doom (obviously not all Doom ports in existence are listed here). Haven't gotten yet to updating the repos with the packages and issues:

7 32-74
Doomsday 2.3.1

95
Doom 3D 1.16
Vavoom 1.27.1
zdoom-old (ZDoom CL 2.1.4a)

95-98SE-ME-NT4
Chocolate Doom 2.3.0
Crispy Doom 3.2
Rude 2.5.0c
ZDoom-LE 2.8.1f
Eternity 3.40.37

98SE-ME
DelphiDoom 2.0.7.734
DoomsDay 1.8.6
PrBoom 2.5.0
PrBoom+ 2.5.1.4
DoomXS 1.0.4.137 (need to verify)
zdaemon zdaemon11019_win32_bin
Zdoom-old / ZDoom CL 2.1.8

98SE-ME-NT4
Doom Legacy 1.48.8
ZDoom32 2.8.6

NT4
prboom+ 2.5.1.4 test win95

2000
Doomsday 1.9.0 beta 6.2
DoomXS 1.0.4.137
FPCDoom 1.14.18.134
Vavoom 1.33
zdaemon zdaemon11019_win32_bin

Vista 32
Edge Classic 1.1
From Doom with Love 2021-10-12 hotfix
k8vavoom 3-6-2022
Nugget Doom 1.8.0
PrBoom+ 2.6.2
Woof! 9.0

Vista 64
Eternity Eternity-x64-4.03.00-pre-739-gdc3035ac

Vista 32-64
Doomsday 2.0.3
gzdoom 4.7.1
Odamex 10.1
Zandronum 3.1

XP 32
chocolate-doom-20220428-win32
crispy-doom-20220428-win32
Doomsday 1.15.8
dsda-doom 0.24.3
Edge 2.1.0 RC1
Eternity Eternity-x86-4.03.00-pre-739-gdc3035ac
gzdoom 4.1.3
Nugget Doom 1.7.0
PrBoom+ 2.5.1.7um
QZDoom 2.1.0
Risen3D 2.2.35
Rude 3.1.0 pre11
Woof! 8.1.0
Zandronum zandronum3.0.1-win32-base
zdaemon zdaemon11020_win32_bin

XP 64
Eternity Eternity-x64-4.03.00-pre-297-g859b58d8
Reboom 2.08um

XP 32-64
Doom Retro 4.4.10
gldoom 0.96c
odamex 0.7.0
International Doom 5.2.1
zzdoom 2.9.0
LZDoom 3.88b

UNTESTED
DOS ports

DosFreak wrote on 2022-05-09, 19:58:

Visual C++ redist I have the below vers along with this note […]
Show full quote

Visual C++ redist
I have the below vers along with this note

"I’ve investigated a bit further - The 2015 to 2019 Visual C++ redistributable ( version 14.29.29917) that shipped with VS 2019 Update 10 Preview 1 does work correctly with a VS 2017 XP app (v141_xp) - so the breakage occured somewhere between VS 2019 Update 10 Preview 1 and Preview 2"

I have these files saved:
VisualCppRedist_AIO_x86_XP_35 (tested) 14.28.29213.0
VisualCppRedist_AIO_x86_x64_44 (untested) 14.28.29910.0

I believe the issue exhibits when you install the later unsupported versions of the redist (which still install when they shouldn't) and they reference an API that doesn't exist in XP.

I just downloaded the _35 one from https://github.com/abbodi1406/vcredist/releases
It contains only .dll files, no .libs for the linker. So this package does not affect an executable in itself.
For example: when newly compiled code would be linked to a msvcrt.lib with NT6 calls, by the MSVC linker, then it will be embedded in the executable, which is much worse. Or is that what you actually mean?

I tried the current SVN version of PCem this evening.
By downloading the Win32 "artifacts" from here https://github.com/sarah-walker-pcem/pcem
The executable is XP compatible, but four of the included DLL files are not. Some of those DLL files are a bit obscure. I had to build a new libzstd.dll myself.
Here is a package to make it work:
https://www.mediafire.com/file/ym8hcaheznhp57 … P-DLLs.zip/file

I had always assumed pcem was XP compatible since it ran on 2000 with BWC kernel but I tend to forget that BWC allows Vista or higher programs to run. Of course the last ver I've tried is v17 so mabye something changed. Good work!

Yeah pcem is definetly one of the projects I want to test on 2000 when I get rawinput patched in SDL2, looks like this was posix compiled so looks like I'll have to see if mingw-w64 win32 can compile pcem.

gerwin wrote on 2022-05-12, 00:23:

I just downloaded the _35 one from https://github.com/abbodi1406/vcredist/releases It contains only .dll files, no .libs for the […]
Show full quote

DosFreak wrote on 2022-05-09, 19:58:

Visual C++ redist I have the below vers along with this note […]
Show full quote

Visual C++ redist
I have the below vers along with this note

"I’ve investigated a bit further - The 2015 to 2019 Visual C++ redistributable ( version 14.29.29917) that shipped with VS 2019 Update 10 Preview 1 does work correctly with a VS 2017 XP app (v141_xp) - so the breakage occured somewhere between VS 2019 Update 10 Preview 1 and Preview 2"

I have these files saved:
VisualCppRedist_AIO_x86_XP_35 (tested) 14.28.29213.0
VisualCppRedist_AIO_x86_x64_44 (untested) 14.28.29910.0

I believe the issue exhibits when you install the later unsupported versions of the redist (which still install when they shouldn't) and they reference an API that doesn't exist in XP.

I just downloaded the _35 one from https://github.com/abbodi1406/vcredist/releases
It contains only .dll files, no .libs for the linker. So this package does not affect an executable in itself.
For example: when newly compiled code would be linked to a msvcrt.lib with NT6 calls, by the MSVC linker, then it will be embedded in the executable, which is much worse. Or is that what you actually mean?

It's been a long time since I bothered testing with the non-compatible versions of the redist on XP. For VS they don't use msvcrt.dll but .dlls that come with the redist. Those .dlls that are what are referenced by programs compiled by VS and those .dlls are what are incompatible with XP. I do know that blackwingcat has modified those files for BWC kernel for 2000 so you can use the 2019 redist on 2000 but I haven't bothered to see what exactly was broken in those newer versions.
As for what MS states when something broke I wouldn't trust that since they didn't give a shit when they broke it heh.

DosFreak wrote on 2022-05-11, 21:24:

Here's Doom (obviously not all Doom ports in existence are listed here). Haven't gotten yet to updating the repos with the packages and issues:

Thanks again. very useful!

For GzDoom the OpenGL requirements are also quite severe.
The mentioned GzDoom 4.1.3 version does not even allow me to start in software-rendering mode.
Windows XP + Radeon HD 6670 + Catalyst 11.10 --> GzDoom v2.1.0 from 06-02-2016 is the last one with functional OpenGL + working zCajun bots.

Yeah zzdoom 2.9.0 or lzdoom 3.88b may be best for older hardware.
For lzdoom you'll need the attached .exe which change major and minor os to 4.0. (I always use 4.0 just in case heh)

For gzdoom when it requires OpenGL your hardware doesn't support you can try Mesa3D.
The attached should work on XP. Haven't tried on <XP. Rename the .dll to opengl32.dll since originally this was compiled for usage with QT.

But yeah something else to track would be software vs hardware for ports and OGL versions. I think gzdoom is one of the worst doom ports as far as the video requirements.