[RichardStorm]

Recently someone on my KADuke Moddb page made me aware that eduke32 no more runs on windows XP, as it tells that some system file are missing and it doesn't start at all. I also tried on an XP machine of mine and the same error(s) occurs.
I can only tell for now that the users noticed Eduke32 won't start on XP from circa r7358 (Feb 2019) , while it worked on an older release i kept on previous KADuke releases, maybe r5707 (May 2016)

I just want to know if XP support has been discontinued on purpose (as i cannot find any info about this), or it's a temporary measure, or it's an issue no one is aware and i can help to backtrack if this is relevant to Eduke32 users.
Also i cannot find a similar topic on the thread so please let me know if this is a duplicate.

[Doom64hunter]

Are they using the 32bit or 64bit builds?

There have been some commits in 2019 and 2020 that mentioned broken XP support, so I think this may be a known issue.

[RichardStorm]

Yes, 32 bit build (if you were referring to Eduke)

Just some examples:
One user reported this: "the point of enter in procedure inet_ntop cannot be found in the WS2_32.dll library" ... he/she also didn't solve by adding such file
When i also tried myself i got a different message : "FlsAlloc cannot be found in KERNEL32.dll"

I'm also sure there are so many XP variants out there so a proper troubleshooting is less reasonable, but at least I can try to find which Eduke32 release started to give problems with XP, from 2018 i guess

[DosFreak]

Some info

https://www.vogons.o...065045#p1065045
https://www.vogons.o...066494#p1066494

[oasiz]

Form what I can say regarding Fury, each major update usually adds features that have to be reflected in CON, this causes the compilation to fail when pairing old builds with a newer GRP.
i.e. The most recent 2021 update adds about 1+ year worth if engine changes and various CON changes exclusive to the expansion pack, updating the codebase to the latest.
Maintaining a separate branch would require much more resources.

Self-compilation is always an option but we don't really spend that much time on trying to add safeguards or documentation regarding it (It's very easy to find a matching version based on asset last modified dates or release dates).
New addon manager that is being worked on will help with dependencies, etc.. for addons. For EDuke32 it's harder to tell, I guess revision number could be one but it's simply based on git repo revision number and not necessarily build number/feature set.

[oasiz]

For what it's worth, I did a quick test on a XP VM against eduke32/voidsw/mapster32/nblood/pcexhumed/rednukem and they all fail to start due to the same reason.

Let's see what the guys have to say on this.
I'm not a maintainer/coder/dev so this is purely my ramblings..

EDuke32 and it's derivatives are ultimately designed to run these games on modern hardware/OS, the compatibility is very high, going back +15 years.
It's fair to claim that practically anyone who would play this on XP already has a system capable of running latest versions with all bells & whistles.

To put it into perspective with XP days, This would be late 70s software, ported to run again in the 80s and maintained throughout the 90s to 2000s.
The main use for a port is to get to use the software on incompatible platforms. XP is starting to be a platform of it's own. It's to be expected that things will start to break.

While I sort of think that 32bit builds could be labelled as "legacy" builds completely and even go as far as not trying too hard to work with modern OS features, there comes a time where you have to think "why?".
For retro gaming, you'd ultimately (at least I would) want the "real experience" and just not use a port at all.
With a port you're picking between two same experiences, other one is slower and other one is faster and objectively better.
Those CRTs, logitech ball mice and multimedia keyboards can just as well be plugged in to bridge the gap.
There is nothing you'd be missing out on.

To clarify here, me (and as far as I know) and none of the devs have any agenda on removing these. Probably all would like to see it back... HOWEVER
It's just that these things are getting hard to test and support, especially when adding "cool improvement/thing x" starts to rely on reasonable expectations that the user has a system that's from past 15 years.
In the end, XP is at that awkward spot where for any retro stuff you'd actually want a 9x setup instead of an older NT with the mostly the same issues/fixes for older games that modern OSs already have.
Sounds a bit cliche but remember that just because you use an older version doesn't mean that the games as-is aren't playable.

[oasiz]

Got a response.. yeah, as was expected. Libraries currently in use simply don't support XP (API functionaltiy is missing).
Windows 2003 has the required FlsAlloc call but lacks GetTickCount64 (Just tested this).

You may or may not have success with patching kernel32.dll https://www.betaarch...pic.php?t=36763 to support this extra functionality.

At the moment there are no plans to change/revert things as stuff like this is sort of expected (but unplanned) breakage that was bound to happen as tools/libs evolve.

[hrg7331]

It would seem it also doesn't run on Vista x64 anymore, but I am uncertain if it's the same reason as XP or simply some runtimes missing from my system.

[oasiz]

Vista x64 should work fine, testing on a VM I get:
4.4572s ERR| Video driver does not support OpenGL version 2 or greater; all OpenGL modes are unavailable.


So I believe it's working fine, I just can't start the instance due to no GPU emulation in Hyper-V.
No complaints about missing API calls.

[RichardStorm]

That is what i wanted to ask indeed.

It is reasonable that Eduke would have been broken on XP or any older OS at a certain point; my question is if some changes in eduke source code had to break XP support on purpose and it was known but not documented , or if broken XP support just happened and if someone was aware of that, without too much care nor reason at fixing it.

XP is surprisingly still used in many environments after 20 years, but i doubt it's the main system for people; also modern Eduke mods gets more complex and ask for more machine resources, so there is no real point at playing such mods on XP, even KAduke runs slow on an XP machine of mine - however i guess many just think that a D3D porting is still always suitable on the systems from the era it started, and that the same guess would apply to its mods/project, but we know this is not right anymore.
(I don't know if Doom ports are better are this, in comparison, but i don't really care about)

If i want to play Duke3d via Eduke32 on an XP machine i'd just put the last working version on XP, and if i want to play Eduke mods i'd just use the .exe delivered by the author in the mod itself.

It's also true that Eduke32 gets better with time and with many "quality of life" features, but i think they stick to our current perception of QoL while we also use OSs with a comparable QoL ... so there is no "real" point at asking that QoL on an XP machine; just take a working build and enjoy Eduke on that mid-era porting fashion. Eduke32 made Duke3d running fine on XP for like 15 years.

[DosFreak]

For anyone interested gerwin at vogons compiled r10161 with some fixes for Windows XP (Can be ran on Vista and 7 of course)
https://www.vogons.o...105085#p1105085

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

Updated 28-9-2022: 
Will no longer crash when something is unexpected in joystick/gamepad 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/20220914-10161-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 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 seperate 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 framerates. 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 randering option.