More than 30 years later, you can still run winquake.exe on Windows 11. Fullscreen does not support widescreen but the windowed mode still works flawlessly. As much as Microsoft has been questionable lately, their commitment to backward compatibility is impressive.
I love this about Windows so much it's hard to explain to somebody who doesn't understand why it matters. :-)
It only matters if you don't have the source to your programs. So yes, there is a huge corpus of programs where this matters. But there is also a large library of programs where the source is available and backwards compatibility does not matter nearly as much.
As a concrete example, the source to quake is available, this has allowed quake to run on so many platforms and windows infamous backwards compatibility has little effect in keeping quake running, windows could have broken backwards compatibility and quake would still run on it.
Quake is a rare exception. Source availability is rare on Windows, falling to almost zero for commercial applications (for obvious reasons). There's also plenty of corporate internal applications where the one company that is using it is also the only one with the source .. and they've lost it.
Quite a lot of game source is lost entirely even by the original authors.
Not to mention that even if you do have the source, changing the use of an API can be a really expensive software modification project. Even Microsoft haven't been entirely systematic, you can easily find WinForms control panel dialogs in Win11.
if you have the source to those programs, and are willing to (sometimes significantly) rewrite parts of them and recompile (see: wayland, for example)
The amazing part is that you don't need to do this in windows whether you have the source or not. I am a linux user, but for all their faults, Microsoft got their backwards compatibility stuff right. Something that the oss world, on average, needs to be convinced it's a desirable thing.
Why do we need Windows 11 to support old software when we can use an older version of Windows, in an emulator at that. Playing Quake doesn't require a secure, patched box, and if a secure environment is the point of extreme backwards compat, then it seems like endless backwards compatibility is not the best way to achieve that goal (sandboxing an old, emulated OS, for example, comes to mind as more reasonable).
Letting Microsoft play this backwards compatibility card feels not healthy for the evolution of software or the diversification of the industry.
If you are like me and like to toy around with ancient game engines, for the sake of simply modding or trying things out, I made this tiny clean fork: https://github.com/klaussilveira/clean-quake
The idea is that it builds on 64-bit Linux with a very simple Makefile and SDL2, so you can start from there as your ground truth, and then have fun. It also removes a lot of cruft, like all the DOS and Windows 95 stuff mentioned in the article.
This is a great write-up for those of us that were into Quake when it was released. Trying to tune your performance was a huge undertaking during the days where you tried running Quake while also having Windows 95. I got into Quake because of all the available MAP tools you could use with it, and the multiplayer aspect, which previously had been very difficult to get working without a LAN.
The detail that -wavonly (falling back to the older WinMM API instead of DirectSound) actually gave the highest frame rate is a perfect example of a lesson that keeps reappearing in systems programming: "more direct" doesn't always mean faster when you're CPU-bound. DirectSound's lower latency came at the cost of more CPU cycles that could otherwise go to rendering.
Link to MGL v4 programmer guide seems to be broken. I’m super curious about this technique — can we do the same nowadays for modern Windows and video cards?
That's some of the same stuff that SDL is meant to abstract over, right? Although I guess SDL was more targeting Windows / Linux differences than Windows / Windows differences.
Also Linux/Linux differences – Xlib, SVGAlib, DirectFB, DRI, GGI, DGA and who knows how many other ways to draw stuff on the screen existed for Linux back then.
And the entire Quake series runs very well on Linux+Proton as well. In other words, I’m not sure why this is impressive on Microsoft’s part.
The online games have depressingly (to me) small communities. But they’re still kicking.
It only matters if you don't have the source to your programs. So yes, there is a huge corpus of programs where this matters. But there is also a large library of programs where the source is available and backwards compatibility does not matter nearly as much.
As a concrete example, the source to quake is available, this has allowed quake to run on so many platforms and windows infamous backwards compatibility has little effect in keeping quake running, windows could have broken backwards compatibility and quake would still run on it.
Quake is a rare exception. Source availability is rare on Windows, falling to almost zero for commercial applications (for obvious reasons). There's also plenty of corporate internal applications where the one company that is using it is also the only one with the source .. and they've lost it.
Quite a lot of game source is lost entirely even by the original authors.
Not to mention that even if you do have the source, changing the use of an API can be a really expensive software modification project. Even Microsoft haven't been entirely systematic, you can easily find WinForms control panel dialogs in Win11.
if you have the source to those programs, and are willing to (sometimes significantly) rewrite parts of them and recompile (see: wayland, for example)
The amazing part is that you don't need to do this in windows whether you have the source or not. I am a linux user, but for all their faults, Microsoft got their backwards compatibility stuff right. Something that the oss world, on average, needs to be convinced it's a desirable thing.
If it uses SDL (99% of the libre games), you don't have to rewrite anything.
> 99% of the libre games
i.e. much less than 1% of all existing games.
True. It's amazing that you can play Quake even on the Oculus Quest 3 these days.
I don't get it, I am sincerely sorry :(.
Why do we need Windows 11 to support old software when we can use an older version of Windows, in an emulator at that. Playing Quake doesn't require a secure, patched box, and if a secure environment is the point of extreme backwards compat, then it seems like endless backwards compatibility is not the best way to achieve that goal (sandboxing an old, emulated OS, for example, comes to mind as more reasonable).
Letting Microsoft play this backwards compatibility card feels not healthy for the evolution of software or the diversification of the industry.
If you are like me and like to toy around with ancient game engines, for the sake of simply modding or trying things out, I made this tiny clean fork: https://github.com/klaussilveira/clean-quake
The idea is that it builds on 64-bit Linux with a very simple Makefile and SDL2, so you can start from there as your ground truth, and then have fun. It also removes a lot of cruft, like all the DOS and Windows 95 stuff mentioned in the article.
This is a great write-up for those of us that were into Quake when it was released. Trying to tune your performance was a huge undertaking during the days where you tried running Quake while also having Windows 95. I got into Quake because of all the available MAP tools you could use with it, and the multiplayer aspect, which previously had been very difficult to get working without a LAN.
> Last but not least, id Software really wanted Quake to work on Windows NT.
Why?
The detail that -wavonly (falling back to the older WinMM API instead of DirectSound) actually gave the highest frame rate is a perfect example of a lesson that keeps reappearing in systems programming: "more direct" doesn't always mean faster when you're CPU-bound. DirectSound's lower latency came at the cost of more CPU cycles that could otherwise go to rendering.
Link to MGL v4 programmer guide seems to be broken. I’m super curious about this technique — can we do the same nowadays for modern Windows and video cards?
That's some of the same stuff that SDL is meant to abstract over, right? Although I guess SDL was more targeting Windows / Linux differences than Windows / Windows differences.
Also Linux/Linux differences – Xlib, SVGAlib, DirectFB, DRI, GGI, DGA and who knows how many other ways to draw stuff on the screen existed for Linux back then.
SDL1 used to render anything.
Yeah, also SDL didn't exist until a year after WinQuake's release.