10 ms·

> It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility. Here's a pretty detailed list: - It is possible to target Windows

> It's hard to overstate how hard Microsoft has worked to maintain backwards compatibility. Here's a pretty detailed list: - It is possible to target Windows XP SP3 (released 2008, EOL 2014, 10 years ago) from Windows 11 and Visual Studio 2022[1] using C++23. Windows 2000 can be targeted with a little more setup[2]. Windows 2000 is 24 years old this year. - It is possible to run a binary written for and compiled in Windows NT 3.1 x86 on a modern 2024 Intel/AMD PC running Windows 11 with absolutely no modifications to said binary whatsoever. Windows NT 3.1 is 31 years old this year. - It is possible to write one binary and target multiple versions of Windows by simply choosing a Platform Toolset, which is paired with a Visual C/C++ Redistributable. - Windows has a run-as mode to run programs in what is essentially a super-thin VM; like you mentioned, emulating different iterations' behaviour for a given program. All four of these are nearly impossible on Linux. The fourth is essentially Docker, which is needed even to target an older glibc (i.e. the equivalent of the first situation). Windows has gone to extreme lengths to not only maintain API compatibility, but ABI compatibility as well. The fact that unmodified binaries from 20, 25, 30 years ago can run without a hitch is a testament to how important backwards/forwards compatibility still is on Windows. Side tangent: all the criticisms levelled at Windows here and in many hacker fora are limited to its userspace—things like its shell and user-space programs, and trivial complaints like 'Candy Crush', or 'start bar', or 'extra right click', or even 'PowerShell aliased curl to Get-Content, grr'. The userspace changes so often because it can; it is a superficial part of Windows. To the haters: Try actually programming with NT OS primitives and even the (undocumented) NT syscalls. It is as enjoyable as UNIX system programming, and I daresay more productive. [1]: https://learn.microsoft.com/en-sg/cpp/build/configuring-programs-for-windows-xp?view=msvc-170 https://learn.microsoft.com/en-sg/cpp/build/configuring-prog... [2]: https://building.enlyze.com/posts/modern-visual-studio-meets-ancient-windows/ https://building.enlyze.com/posts/modern-visual-studio-meets...

wvenable 3y ago
The most stable API/ABI for the Linux desktop is provided by Wine.
- pjmlp 3y ago
  Thankfully the year of the desktop is around the corner, by combining WSL with the original Win32. Day zero feature availability, without compatibility issues.
miki123211 3y ago
I wish they included an 8086 emulator so that old software compiled for DOS would still run. It worked on 32 bit systems until 32 bit support was dropped, which only happened a few years ago. That was due to Intel's virtual 8086 mode, which is not available if your CPU is running in 64 bit (long) mode. Modern computers are fast enough for the emulation overhead to be negligible, even if you don't do any fancy JIT tricks and just go with a switch/case inside a while(true). I would personally make use of this, I know of a 16-bit program whose latest version was released in the late XP days, so it's not even that old. The idea there was that it was always compatible with DOS, some users might presumably still want to run it on DOS, and there's no point in breaking that compatibility if modern Windows can run it just fine. Then development stopped, 64 bit systems got more popular, and a recompiled version was never released. I guess the lesson there is that if you're keeping an API for backwards compatibility, some programmers will refuse to switch to a replacement to make their software work on older systems, making the API impossible to remove down the line without breaking modern programs.
- mook 3y ago
  At least you can still do this with third-party software like https://github.com/otya128/winevdm https://github.com/otya128/winevdm I guess? I imagine Microsoft doesn't see the returns for it to develop something they'll have to support for decades more…
sfink 3y ago
I have unfortunately run into exceptions. I tried to play Neverhood on my Windows install, and it wouldn't start up. Tried the various compatibility modes. No luck. I ended up running it under Wine in Win95 mode (or similar; I don't remember the exact version) on my Fedora desktop and it ran fine. I haven't tried running too many old programs, though, so I have no sense for how common this might be.
ec109685 3y ago
This is impressive, but other parts of Windows are so dreary. Installs of apps that throw up all over the disk, Windows Updates that mysteriously fail in unrecoverable ways 87% of the way through and cryptic error codes and procedures to dig yourself out of the jam (before you must reinstall).
- ghusbands 3y ago
  > Installs of apps that throw up all over the disk This seems like a norm for most operating systems. Linux mixes files from all sorts of apps all over the place, for example, and a `make install` might put files anywhere.
heyoni 3y ago
This is great and all until you completely ignored the fact that wine exists and went on to call user space design questions by Microsoft “trivial”. I could also start listing ways that the Linux kernel maintains backwards compatibility with not just software but hardware that’s decades old but the list would get too long. No one is complaining that Microsoft has too much backward compatibility, it’s their utter disregard for user choices and privacy that drives away the hacker community to either Linux or even macOS.
- pjmlp 3y ago
  Linux kernel on its own doesn't run software.
  - heyoni 3y ago
    But it comes with drivers supporting very old hardware, hence the inclusion.
    - pjmlp 3y ago
      That alone still doesn't run applications.
      - heyoni 3y ago
        GNU/Linux + the linux kernel. Somehow, it feels like you don't actually care about the point I was making as much as putting me down. I misspoke...barely, yet you're so fixated on pointing it out in the most unhelpful manner. You keep replying so why not try using more than one sentence next time?
        pjmlp 3y ago
        Now that you got there, which distribution released in 2023 allows me to run a GNU/Linux binary compiled in 2000, regardless of the distribution it was compiled on back in 2000?
ahartmetz 3y ago
"The car works great technically, people just have trivial complaints about the steering wheel being made of razor blades." That is becoming less and less of an exaggeration as Windows is progressively further enshittified. NT seems to be a nice OS at the core, but that's more about what it can do and how it is implemented than about how pleasant it is to use. Some of its syscalls are much more convoluted than the UNIX ones. Typical functions take many parameters, some of them complicated on their own, and typical invocations pass a bunch of NULL arguments (you still need to roughly understand what they mean).
gkbrk 3y ago
> Windows has gone to extreme lengths to not only maintain API compatibility, but ABI compatibility as well. Linux has a stable ABI as well. For a given architecture, like x86_64, syscall numbers and their arguments and their arguments/outputs are expected to be stable. The stable API/ABI promise of Linux is the syscalls, because at the end of the day that is the interface between userspace applications and the kernel, and kernel devs take not breaking userspace very seriously. And on Windows, the opposite is true. The stable interface is the Windows DLLs that you are supposed to use dynamically. If you hardcoded the syscalls, you cannot complain if your application breaks because windows only promises that the DLL will not break backwards compatibility, and they reserve the right to change the syscalls with any update. So you can have a Linux binary that works across many Linux versions without breaking. You can also have a Windows binary that works on one version of Windows but not the next.

wvenable 3y ago

The most stable API/ABI for the Linux desktop is provided by Wine.

pjmlp 3y ago
Thankfully the year of the desktop is around the corner, by combining WSL with the original Win32. Day zero feature availability, without compatibility issues.

miki123211 3y ago

I wish they included an 8086 emulator so that old software compiled for DOS would still run. It worked on 32 bit systems until 32 bit support was dropped, which only happened a few years ago. That was due to Intel's virtual 8086 mode, which is not available if your CPU is running in 64 bit (long) mode. Modern computers are fast enough for the emulation overhead to be negligible, even if you don't do any fancy JIT tricks and just go with a switch/case inside a while(true). I would personally make use of this, I know of a 16-bit program whose latest version was released in the late XP days, so it's not even that old. The idea there was that it was always compatible with DOS, some users might presumably still want to run it on DOS, and there's no point in breaking that compatibility if modern Windows can run it just fine. Then development stopped, 64 bit systems got more popular, and a recompiled version was never released. I guess the lesson there is that if you're keeping an API for backwards compatibility, some programmers will refuse to switch to a replacement to make their software work on older systems, making the API impossible to remove down the line without breaking modern programs.

mook 3y ago
At least you can still do this with third-party software like https://github.com/otya128/winevdm https://github.com/otya128/winevdm I guess? I imagine Microsoft doesn't see the returns for it to develop something they'll have to support for decades more…

sfink 3y ago

I have unfortunately run into exceptions. I tried to play Neverhood on my Windows install, and it wouldn't start up. Tried the various compatibility modes. No luck. I ended up running it under Wine in Win95 mode (or similar; I don't remember the exact version) on my Fedora desktop and it ran fine. I haven't tried running too many old programs, though, so I have no sense for how common this might be.

ec109685 3y ago

This is impressive, but other parts of Windows are so dreary. Installs of apps that throw up all over the disk, Windows Updates that mysteriously fail in unrecoverable ways 87% of the way through and cryptic error codes and procedures to dig yourself out of the jam (before you must reinstall).

ghusbands 3y ago
> Installs of apps that throw up all over the disk This seems like a norm for most operating systems. Linux mixes files from all sorts of apps all over the place, for example, and a `make install` might put files anywhere.

heyoni 3y ago

This is great and all until you completely ignored the fact that wine exists and went on to call user space design questions by Microsoft “trivial”. I could also start listing ways that the Linux kernel maintains backwards compatibility with not just software but hardware that’s decades old but the list would get too long. No one is complaining that Microsoft has too much backward compatibility, it’s their utter disregard for user choices and privacy that drives away the hacker community to either Linux or even macOS.

pjmlp 3y ago
Linux kernel on its own doesn't run software.
- heyoni 3y ago
  But it comes with drivers supporting very old hardware, hence the inclusion.
  - pjmlp 3y ago
    That alone still doesn't run applications.
    - heyoni 3y ago
      GNU/Linux + the linux kernel. Somehow, it feels like you don't actually care about the point I was making as much as putting me down. I misspoke...barely, yet you're so fixated on pointing it out in the most unhelpful manner. You keep replying so why not try using more than one sentence next time?
      - pjmlp 3y ago
        Now that you got there, which distribution released in 2023 allows me to run a GNU/Linux binary compiled in 2000, regardless of the distribution it was compiled on back in 2000?

ahartmetz 3y ago

"The car works great technically, people just have trivial complaints about the steering wheel being made of razor blades." That is becoming less and less of an exaggeration as Windows is progressively further enshittified. NT seems to be a nice OS at the core, but that's more about what it can do and how it is implemented than about how pleasant it is to use. Some of its syscalls are much more convoluted than the UNIX ones. Typical functions take many parameters, some of them complicated on their own, and typical invocations pass a bunch of NULL arguments (you still need to roughly understand what they mean).

gkbrk 3y ago

> Windows has gone to extreme lengths to not only maintain API compatibility, but ABI compatibility as well. Linux has a stable ABI as well. For a given architecture, like x86_64, syscall numbers and their arguments and their arguments/outputs are expected to be stable. The stable API/ABI promise of Linux is the syscalls, because at the end of the day that is the interface between userspace applications and the kernel, and kernel devs take not breaking userspace very seriously. And on Windows, the opposite is true. The stable interface is the Windows DLLs that you are supposed to use dynamically. If you hardcoded the syscalls, you cannot complain if your application breaks because windows only promises that the DLL will not break backwards compatibility, and they reserve the right to change the syscalls with any update. So you can have a Linux binary that works across many Linux versions without breaking. You can also have a Windows binary that works on one version of Windows but not the next.