QTWeb
FireFox
SeaMonkey
Retrozilla
ScummVM
https://gitlab.com/wsusoffline/wsusoffline
https://download.wsusoffline.net/

DOSBox
pcem
VLC
Media Player Classic
PCSX2
Clamwin
Windirstat
qbittorent
SoundFX
munt
Miranda
Pidgin
goldberg for xp https://gitlab.com/this_isnotme/winxp-goldberg-emulator
https://github.com/rishooty/Q9xS

Python 2.7
Python 3.7.1

When the workflows and changes are done, would there be attempts to pull into their upstreams?

I know a lot of showstoppers go into mingw/gcc and sdl2 politics and/or "windows" targeting that'll likely end in shrugs.

One useful tool for some of the platform-regressive WinSock2 matters can be done with ReactOS's wspiapi.h file (from my experience)., as there's Software Freedom(tm) reasons for that in not using Microsoft's DDK for the 9x-compatible header, etc.

Would need a feel for what projects are interested in fixing broken OS support.

Default assumption is if they didn't care enough to at least list what OS it works on is that they don't but it's probably just laziness. On Doomworld and other doom port forums I see alot of bashing for using an old OS but strangely the DOS ports never receive such bashing.....

If you're gunning for it being quasi-official, I suggest changing the avatar photo to be either the old logo:
https://web.archive.org/web/20191108125231im_ … t/site_logo.png
or the current one, which would need to be rendered out, as it appears to be inline SVG or something. 😉

Posted a prboom+ 2.6.1um (up to latest commit) binary in the releases section for XP
As I suspected vcpkg dependencies are compiled with mingw-w64 posix instead of win32 thread and a couple of releases back posix compatibility with Windows XP was dropped. win32 thread works fine or reversing the commit in mingw-w64 posix thread that broke XP should as well.

Found some oddities with how prboom+ is compiled.
https://github.com/vogonsorg/prboom-plus/issues/2

What's even weirder is that they appear to use mingw compiled dlls but a Visual Studio compiled binary. wtf.

Added repos that have been forked to the first post.

gimp
https://gitlab.gnome.org/GNOME/gimp.git
bochs
https://svn.code.sf.net/p/bochs/code/trunk
Qemu
vlc
notepad++
https://msfn.org/board/topic/183153-method-to … -in-windows-95/

https://msfn.org/board/topic/175262-last-vers … ws-server-2008/

DOME 11-17-2021
https://msfn.org/board/topic/133014-last-vers … r-windows-2000/
https://msfn.org/board/topic/181336-last-vers … r-windows-nt-40

DONE 11-16-2021
https://msfn.org/board/topic/176299-latest-ve … e-running-on-xp

Not forked
Sumatra PDF 3.3.3 http://designingonajuicycup.com/downloads/unt … _winxp/3.3.3.7z
mame
https://drive.google.com/drive/folders/1eiNzt … z0SMDM_eJOmb0FO
https://www.progettosnaps.net/index.php
https://oss.netfarm.it/clamav/
PatchPE https://nikkhokkho.sourceforge.io/static.php?page=PatchPE
https://reactos.org/wiki/ReactOS_Build_Environment
https://forums.mydigitallife.net/threads/tool … r-v1-5-6.82935/
VC++ 2019 14.28.29213.0 redist for XP
XP SP2 64-bit
https://download.visualstudio.microsoft.com/d … _redist.x64.exe
XP SP3 32-bit
https://download.visualstudio.microsoft.com/d … _redist.x86.exe

I've been out of the dev game for a few years now but don't you only fork a repo when you have a change to make? Or are you looking ahead 10 years to the original repos missing / vastly changed and some old vogons crank wanting to build a long lost version?

The idea is that most likely the projects do not care about: maintaining compatibility in new versions,documenting what versions work with what OS or hardware and providing those versions for download. You can see this wherever you go and the behavior by even users themselves towards those that do care is quite toxic.

Doesn't matter if it's a github "fork" or clone you can submit changes from both to the original repo, with the "fork" it's assigned to your account and have full access to it.

Usage case is for right now and for the future.
1. Fork the open source project.
2. Add last known working release binaries for each OS (or older ones).
3. Create actions to compile the last known working release binaries.
4. Compile last working commit for that OS.
5. If commit breaks OS support then attempt to fix, if source repo doesn't want the change then no big deal. It's in the "fork".

1 and 2 are fairly easy and is helpful for forums like these where you can just say: "Go to github/vogonsorg/xxxx/releases" and download vx.xx of VLC" for NT4!
Instead of "vx.xx works on NT4. Try googling for it and clicking on a bunch of ads and missing links or compile it yourself!

If you asked anywhere else it would be: "NT4? WTF. Loser. Use winbloze 11 or Ubuntu. VLC works fine there." That would be a fairly nice response.

DosFreak wrote on 2021-11-18, 01:43:

If you asked anywhere else it would be: "NT4? WTF. Loser. Use winbloze 11 or Ubuntu. VLC works fine there." That would be a fairly nice response.

Ah yes I'm familiar with that sort of response and now that I think of it a few projects I follow are dropping XP support or have done already.

There's some that are already like that towards 7. *cough*ViGembus*cough*Python*cough*

Here's the github for the abandoned vstmidi driver that many of us want to use, but can't get to load properly. From the look of things, the repo hasn't been touched in years, so I can't say the code is close to the last version of the driver that mudlord put out. I don't know if there's anything useful there, but it would be nice to restart it.

https://github.com/jkammueller/vstdriver

Look into adding mingw-w64 for xp for those using posix instead of win32.
Note that since there doesn't seem to be much interest in this thread then possibly thus would just be to fix the pthread issue or for any other vogonsorg issues. Although may make sense to just use win32 thread for all when possible for all windows os excluding less than 3.5x

DosFreak wrote on 2021-11-27, 14:50:

Look into adding mingw-w64 for xp for those using posix instead of win32.
Note that since there doesn't seem to be much interest in this thread then possibly thus would just be to fix the pthread issue or for any other vogonsorg issues. Although may make sense to just use win32 thread for all when possible for all windows os excluding less than 3.5x

I am following your progress with this and appreciate the work so far. Of course that is just me, one person.

I don't know exactly what you are talking about regarding the posix/pthread/win32-thread thing, Maybe you could explain it?

In the meantime I am slowly doing similar things in a slightly different way.

• Compiled OmniSpeak SVN (Commander Keen 4,5,6, SDL2) for Windows XP, easy.
• Looked at Commander Genius (Commander Keen 1 to 6 + dreams) and concluded that the "v1.9.2 Beta" I archived is probably best for Windows XP. As the later versions have Python integrated and are normally not compatible.
• Tried to compile ecwolf SVN and also the normal v1.3.3 (2016) version, but my cmake is not linking SDL(2) with this one properly, and I gave up ... for now.
• Still missing on the list: OpenRA v20160508 is the last for Windows XP. After that it requires an incompatible .NET or Mono.
• Master of Orion 1oom? Development has slowed past years, but it is nice as it is. I prefer the win32_rfs_81_v1.0-56 version. Found on Gitlab. What to do with Gitlab?
• Browsing https://osgameclones.com I found someone 'remade' Space Cadet Pinball. It comes with legacy friendly builds. It is on github.
• Compiled CorsixTH (Theme Hospital) v0.65.1-hotfix for Linux. I do have v0.62 working in XP with some tricks, but IIRC they went 64-bit only.
• Can tell a lot about Spring Engine versions (Total Annihilation like) and v104.0.1-409 (07-2020) is may favorite legacy build. Shard/DAI computer opponents eat memory like crazy, so you need v104.0.1-409 which still supports somewhat legacy friendly RAI opponents. This version is a match with Balanced Annihilation game package ba-v10.11.

If need be, I can send you any of the files mentioned.

https://github.com/mimi1vx/openmoo2 OpenMOO2 (open source clone of Microprose game "Master of Orion II: Battle at Antares")

Thanks gerwin.
The Posix issue with mingw-w64 is that there was a commit added at some point breaking XP compatibility so you either had to revert the commit, use old pthread package, use an older mingw-w64 version or just use a mingw-w64 compiled with win32 thread. Mingw-w64 that comes with Linux is already win32 thread whereas I want to say MSYS2 repos are posix. So even if you use mingw-w64 w/ win32 thread on Windows, pacman will still pull posix thread binaries but it's been a long time since I bothered with MSYS2 so unknown if they ever fixed that but I remember a long time ago that they made a decision that the pacman repo pushes posix.
I just cross compile from Linux. Tools are always up to date, no MSYS2 flakiness and compile times are much faster. Linux and/or WSL2 FTW.
For those that care about posix thread thought was to just fork mingw-w64, revert the commit and depending on how important it was keep it reverted or find a way to fix it.
Also there is this as well..... https://github.com/msys2/MSYS2-packages/issues/2696
Mingw-w64 win32 thread compiled binaries work on NT3.51+ (As long as you update msvcrt.dll). Since posix thread broken on XP then would make sense to just use win32 thread for XP as well.

You've got some good stuff there, will add soon.

Current status:
Done with Windows workstation VMs from 11-2000.
Currently working on Server VMs from 2022 to 2000.
I'm also synchronizing WSUS on Windows 2022 and downloading all Windows 2000+ updates.

Think after the Server VMs are done I'll:
Catch up on this thread and add items github
I've been doing some cleanup on the software on my fileserver so can add some more versions of what works on what OS.

TO DO after above, likely after DEC:
Need to do some researching on installing updates after 3.x-ME, NT 3.x-4 using qchain or a script so I can finish those VMs. Been a long time since I scripted those.
Need to decide how to test SSE2 vs SSE1 vs none. Qemu (official) vs pcem vs bochs. Likely pcem and bochs are the best bet, think Qemu just masks. What was the last Windows XP update before they went SSE2? What was the last Windows 7 update before it went SSE2?
For D3D/OGL - Use Vmware for 2000+
For D3D/Glide/OGL - Use pcem - bochs for 3.x-9X-NT4
For 2D use Vmware for 3.x+

Mesa3D in 9x
Re: DOSBox Compilation Guides

Going on a trip for a week starting this Friday, so will resume after. Still working on VMs but did add a radgametools repo this week.

DosFreak: You are doing an amazing piece of work. Not just the github stuff, I am also talking all the other "small" projects you have done over the years. Like collecting different versions of the same files, and what not. My hat is off to you Sir !

Blender 3.0 breaks Windows 7! Python 3.9 and w10 core-path strike again!

I think the last 9X blender was 2.49?