Comment by delta_p_delta_x | Hacker News Reader

Comment by delta_p_delta_x | Hacker News Reader

Parent Full thread

delta_p_delta_x

> 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-prog...

[2]: https://building.enlyze.com/posts/modern-visual-studio-meets...

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.

At least you can still do this with third-party software like 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…

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.

Linux kernel on its own doesn't run software.

But it comes with drivers supporting very old hardware, hence the inclusion.

That alone still doesn't run applications.

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?

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?

What am I chatgpt? Just make your point and tell us which 2000 binaries don't run and we can argue about whether or not that counts as a mark against backwards compatibility.

Also, is this a trick question about binaries that weren't patched for y2k or something?

If a binary from 2000 doesn't run, it's because of glibc ABI changes. I still have faint memories of glibc crap happening in the early 2000s. But if the binary from 2000 is statically linked, then the Linux kernel probably runs it fine today.

Which is weird considering the argument you had with others above about how "Linux (kernel) doesn't run software", was it a buildup to convince us that "GNU(glibc)/Linux" is really bad at running old binaries? Because your argument doesn't hold for the Linux kernel itself running statically linked binaries.

Only if those binaries were designed to be called from the Linux kernel directly, using only syscalls.

Last time I checked, hardly anyone uses their computer as an embedded board.

application /= software. You're moving the (extremely ill-defined) goalposts. Next you'll be arguing that device drivers or the Linux VFS layer aren't "software".

The goal hasn't moved, we are talking about ABI compatibility for a full operating system across multiple decades and generations of operating systems releases, without requiring building those applications from source.

Not a kernel booting directly into an application doing straight syscalls.

> Linux kernel on its own doesn't run software.

Linux runs /sbin/init.

Which you can make any executable you want.

Not to mention initial RAMdisk (loaded by a bootloader like grub) which can be of arbitrary size & loaded up with an arbitrary ton of goodness.

Yeah, which is quite far from a full OS experience providing ABI compatibility across several generations of operating systems.

Linux (kernel) has a userland ABI of its own. Which is pretty stable & rarely broken (Linus will probably breath fire @ any kernel developer who does break user space). So eg. 10y old statically compiled binaries will likely run fine on recent kernels.

But as you state: it's the OS-level ABI's (C library, desktop environments, middleware libraries, etc) that keep changing constantly. And thus, keep breaking pre-compiled binaries.

Source-level API vs. binary ABI stability. Kind of a philosophical debate imho. But sadly, even that source-level API isn't too stable in some circles.

Do you have an actual argument or are you really committing to "nuh-uh"

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

Thankfully the year of the desktop is around the corner, by combining WSL with the original Win32.

Day zero feature availability, without compatibility issues.

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).

> 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.

> 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.

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.

"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).

Reply on news.ycombinator.com