The right thing to do is decouple video decoding from Windows and just ship a video decoder with the game. Then it becomes 100% irrelevant what Windows supports now or in the future.

This is related to my point though. I would guess eventually the way to play classic PC games will be a Windows 7/10 offline machine built with older parts, or maybe some kind of Windows 7/10 emulator within whatever future devices we use. I would think having less requirements on top of the game will make for better compatibility with that future.

I guess eventually it will (have to) be a x86 PC emulator which can run Windows. IIRC there already is such a PC emulator but I don't know of its current status.

I am also expecting that at some point of time there will be a period when people can't play their older PC (Win32) games because the platform they are then using doesn't run them, and there is no emulator available yet (not sure if Linux WINE can be considered as such, maybe). Like how when Windows XP became the norm, we PC gamers had to say goodbye to most of our MS-DOS games (some of them could be made run with utilities for getting the sound work etc.)... but eventually DOSBox became a thing and instantly revived all those MS-DOS classics. Suddenly we were able to run pretty much all of them once again.

I also recall when as a kid I finally sold my Commodore Amiga 500, I recall thinking how sad it is I will never see and experience the Amiga games anymore. I had recorded the gameplay of some of them to VHS cassettes, that was my only way to relive them and kinda keep them alive.

But then at some point WinUAE (an Amiga emulator) became a thing, reviving the old Amiga classics.

My biggest concern with whether these past systems will live on also in the future is whether we will keep having open computing systems where it is possible for anyone to create new emulators and revive past systems, as to me Microsoft seems to wish to "walled-garden" the Windows ecosystem. However, with Linux and also open non-x86 systems like Raspberry Pi etc., maybe there will always be such an open alternative, no matter what.

Also, naturally it is possible some less known systems never get to become emulated as there is not enough interest. From my childhood, I recall ALMOST buying a certain Sharp home computer which came with quite many free games that interested me. I have to google what the name of that computer was, I just recall it had a small 3 or 4 color "drawing printer" in it where you could print some kind of pictures or graphs on paper.

I've been wondering if that system was ever emulated, and if anyone ever got to save those games that came with it for future generations. Maybe not, I'll have to check. EDIT: It was most probably Sharp MZ-700 series, possibly MZ-731.

Yeah I've been thinking about the same, but I am unsure how Windows games normally handle it, do they rely on what Windows offers them, or include their own "dependencies" included with the game installation.

With MS-DOS games it was simpler, they were provided with each game. There was no danger of MS-DOS dropping support for some video format or sound card or whatever, hence all the games which earlier worked suddenly not working anymore.

There are x86 emulators but they tend to be ridiculously slow. I wouldn't count on Moore's law to give us CPUs fast enough to emulate a 2010s Win7 gaming PC twenty years from now. Nevermind that implementing the emulator is a gargantuan task.

JIT recompilation plus some hardware & OS support for emulation is more likely to succeed, but I won't bet on that either. More likely JIT plus hardware & OS support plus something like Wine (so you don't have to emulate the entire computer, just implement the Windows APIs and syscalls). The answer is it depends. Some ship their decoders, others don't. For example I'm pretty sure Windows has no Theora decoder built in, but a few games use it: https://wiki.xiph.org/index.php?title=Games_that_use_Theora&mobileaction=toggle_view_desktop

I look at the console "retro" systems like the Retron and kind of imagine buying a "retro PC" someday for too much money. But who knows.

To answer the OP question the client requirement does introduce compatibility issues:

Steam dropping 9x-XP support makes games that require Steam stop working on those operating systems.
For 9x you are better off cracking the games or using revemu (Steam Emulator) or Steamless
For 2000 you can use SmartSteamEmu, Revemu, Steamless, and game cracks
For XP you can use SmartSteamEmu, RevEmu, Steamless, Goldberg (w/ XomPie), game cracks
For Vista I believe all of the above emulators and tools work fine but eventually the newer versions of those will stop working and you will have to hope that the latest version of those that work on your OS will work for your game or hope that there is something like OneCoreAPI or XomPie or a kind soul who modified them to work on that OS
For 7-8 and builds of Windows 10 that are not the latest then eventually you'll see the same issues as what I said above.

Steam recently as of 2 days ago dropped compatibility for certain processors in the Steam client due to the brilliant decision to use the bloated CEF for launching games so they whenever Google decided to drop compatibility then every other idiot that wants to use a browser for their application has to do the same..

Alot more games on Linux that use Steam are less reliant on the client than the Windows versions but for those that do you can use Goldberg.

For GOG the Galaxy.dll requirement prevents compatibility with <Vista so you have to use XomPie or hexedit the executables to run on XP32/64.

So yes the client requirement does and will break games which is why if you buy those games and you care then you need to do what you can to remove the requirement.

So 25yrs ago we were using 32bit applications and those still run on the latest versions of Windows for the most part, those with issues have fixes, those that don't have fixes can be run in virtualization or emulation. I don't see that changing in another 25 years except for possibly 32bit programs being required to run under virtualization but hopefully GPU wrapping and passthrough support is handled better than it is currently. passthrough of a Nvidia GTX 100000 to an OS that doesn't support it isn't going to do anything so hopefully wrapping of APIs is still a thing. Dege is currently testing D3D12 support in dgvoodoo2, I wish that virtualization vendors were half as dedicated as he is to game compatibility.

It'll be interesting to see how Apple handles the ARM transition. If their entire line moved to ARM then that would mean that the MAC users can't dual-boot to Windows 10 and play their games unless they use an ARM version of Windows 10 that emulates x86 but the performance would be pretty bad. Since Apple is horrible to game developers I don't see much to be learned for for PC gaming compatibility from that fiasco but it is another data point.

You'll probaby see someone jump in and mention how the cloud streaming will save us all for compatibility (but obviously not for offline) but I don't see how. As we all know from the hell that GOG goes through to finding who owns the license for what software there is no way a cloud vendor is going to support 10,000+ games in the cloud as well as having to pay all those publisher fees especially when only 100 people are playing Mean Streets and 10,000,000 are playing OwMyBalls 69 Matrix edition.