All the 25 years of code is still in Windows 11 they just hide it with a lick of paint. If you want to play old games Microsoft is still your best bet.
There are a lot of baffling decisions by Microsoft’s Windows division, but their extreme dedication towards backward compatibility is nothing short of Herculean.
Sometimes I wish they’d split up Windows in an ultra-slow ‘Enterprise’ ring and a move-fast (think about the speed of macOS changes) ‘consumer’ ring, where they could drop much of the legacy cruft in trade for speedy/forced improvements. Think macOS going fully 64 bit, making the system image immutable, etc.
Hell, imagine if they’d allowed the Xbox One, X and S to run Windows 11 in S mode. Instant cheap performant computer for the layperson! And with it running S mode, they’d make their money through the Microsoft Store.
They do: Long-term Servicing Channel releases: https://techcommunity.microsoft.com/t5/windows-it-pro-blog/l...
This just tells me Windows is on a level with Linux + Wine, with the compatibility mode.
> All the 25 years of code is still in Windows 11 they just hide it with a lick of paint.
That's not true. Windows had a big, discontinuous shift when they abandoned the DOS-centric Windows codebase in the move to XP.
Initially happy as the install and intro ran fine, but pressing enter to skip the video exits the game immediately.
Maybe that's further than you would expect, wine / proton is incredibly good nowadays, but still your point stands.
You mean the move to the NT platform, which made the consumer windows desktop OS finally stable.
Compatibility features, while not perfect, were implemented to help try and get Win9x and DOS workloads to function normally. Some DOS apps ran fine on XP in compatibility mode, although I couldn't say what %.
Windows 11 is the latest member of the Windows NT family, which originates from Windows NT 3.1 which coincides with Windows 3.1.
Windows NT 4.0, which coincides with Windows 95, is where things start to look more familiar to us today.
Windows 2000 followed to coincide with Windows 98 and ME and is where the NT family really got consumer-aimed software working right with the integration of DirectX all the way up to DirectX 9.
Windows XP which followed 2000 is really just 2000 with some more cleanup and QoL improvements. All the foundations were laid by the time of Windows 2000.
So yes, "all the 25 years of code" are definitely still in Windows 11 under a lick of paint.
Like sure I understand that having specific packages for each version should make it reliably work, but the trade off and demand for devs to keep up is pretty huge.
I compiled xv from 1994 the other day on my Linux box; just has to make a tiny patch to fix an include (lots of warning, but it compiles and runs).
That said, there's some room for improvement. For example pkg-config/pkgconf could automatically suggest which packages to install if "pkg-config --libs x11" fails, or some other distro-agnostic way for people to track down dependencies.
If you're shipping a binary program without source (i.e. a game, for example, which tend to be closed source) you should ship the libraries or compile things statically. Some of the older Linux games on gog.com can be a bit tricky to run on modern systems due to this.
See that's the thing, everything on linux is designed to work by sideloading as much as possible, depending on thirty thousand packages that must be all installed to the perfect version by apt or else nothing works. A good system if you need to get a fully featured OS running on 100 MB of disk space, which tbf is linux's niche, but it's absolute horseshit to maintain.
Windows on the other hand tends to have flatpak-style monolithic executables, with the odd .NET framework or cpp resdistrubutable here and there, but it's the rare exception. Things tend to actually work when they bundle their dependencies. Hell, the average Java app ships the JRE along with it because nothing works if the wrong version is installed globally. Linux just takes that problem as a fact of life and tells you to fuck off.
In practice however, I rarely encounter issues, except for closed-source programs that don't ship their libraries. That, I think, is mostly the fault of the vendor and not the Linux system. Of course, as a user it doesn't really matter whose fault it is if your application doesn't work because you just want the damn thing to work. It does mean the problem (and solution) is mostly an educational one, rather than a technical one. You certainly can ship binary programs that should work for decades to come: the two core components (Linux kernel and GNU libc) take backwards compatibility pretty serious, more or less on equal level with Windows.
You don't even need flatpack. A wrapper script with "LD_LIBRARY_PATH=. ./binary" gets you a long way (and still provides people the ability to use a system library if they want, so sort-of the best of both worlds).
The key difference is that each app bundles its DLLs for its own private use. From the user's perspective, it's essentially the same as static linking, if you treat the entire folder as "the app".
In MS speak, it is xcopy install, based on how MS-DOS applicatons used to be distributed, even when static linking was the only option (with overlays).
I've tried similar on debian, ubuntu, and centos but fighting with apt or yum and their (seemingly) comparatively brittle packaging systems got very old very quickly. Not that it can't be done easily on those systems but so far I haven't managed it yet.
Nix I find can also be really nice for this, especially since flake based packages are pretty much self contained. Still a lot less pleasant compared to the portage/ebuild route though.
I've had more luck with old Linux binaries running, myself.