Linux Kernel Has Been Forcing Different Behavior for Processes Starting with “X”

I'd rather have old software run on a new OS and hardware.

Than access to old OS and hardware to run the software.

Simply because that means you're not reliant on obselete hardware (expensive poor performance hard to find) and potentially a OS full of security holes.

Similarly I'd rather have to use a VM at compile than run time. For convenience.

That's not really what's meant by backwards compatibility. Backwards compatibility generally means your current OS can run your old software without having to install a raft of older (and likely insecure) versions.

Windows accumulates backwards compatibility "hacks" over time meaning you likely have a fairly decent chance of running your older software where vendors misused API's in ways they ought not to have.

Of course there are the usual caveats about running 16bit apps on 64 bit Windows where you'll need to find a 16bit emulator.

> Windows forces you to use a new version

It doesn't. If you were running Windows 7 or 8 on the cusp of the Windows 10 roll out, that 20-25 year old app will still run on the currently supported versions of Windows. The "hacks" for that ancient app you still know and love will still be there. Now there are some far away and yet undiscovered edge cases, as in really exotically and mythically rare that yes their hacks might only appear in a future version of Windows.

As the OP mentioned they didn't have _time_ to fix it; likely 80% of the problems are hard-coded paths and such that would be relatively easy to "fix" - but the other 20% may be dependencies on things that got deprecated/removed in later versions of the build environment, and updating would take quite a bit of work.

This is one of the reasons that if you are trying to build cross-platform software (and Windows 2000/XP/98/Vista is cross platform, mind you) you should start building and testing on the various platforms early.

Fortunately nowadays we have more resources to throw at the problem and can run such software in containers, VMs, or other such isolated sub-environments when necessary, but that wasn't always the case.

It's a trade-off, I don't think you can declare one strategy better than the other in absolute terms.

For instance they changed the implementation of malloc() between Win95 and Win2k that broke some applications that depended on the behavior of the old malloc() so there is a flag in the system for those applications that restores the old malloc().

There are advantages to both ways of doing it, and for enterprise stuff the Windows way is very useful.

Apple and Windows are extremes in each direction. The best (and hardest) answer is to live in the middle somewhere.

Because if software app Foo works fine on Windows X, and suddenly breaks on Windows X+1, users don't care if Foo is actually buggy or not. It worked on Windows X. What they see is that Windows X+1 broke Foo. And they talk to each other - "Do you use Foo? If so, don't upgrade to Windows X+1, it breaks Foo!"

And if there's another app Bar which has a different bug that nevertheless works on Windows X but breaks on X+1, those users will chime in saying "Oh yeah, we noticed it breaks Bar too!"

And then you get the general conversation go around "Don't upgrade to Windows X+1, it breaks random software!" Do you rely on some niche app, or even a semi-popular one made by anyone who isn't Microsoft? If so, better stay away from Windows X+1 - it breaks a bunch of random apps dontchaknow.

I forget the exact errors, but the software is simply too old.

I was also around for the tail end of the libc5 to glibc conversion, so I have definitely seen breaking change.

Isn't that architecture limit? AFAIK 64-bit mode on x86_64 machines does not support vm86 mode, so 16-bit code cannot run directly on 64-bit OS. That is why dosemu no longer works in (64bit) Linux, while dosbox works, because it is full CPU emulator.

Note that otvdvm isn't the same as DOSBox which emulates everything. Otvdm passes the calls to the native 32bit APIs and it relies on the fact that Windows does preserve backwards compatibility. It wouldn't work without it.

DOSBox on the other hand only needs a framebuffer, an audio device and an input device to work and does everything else itself.

I would guesstimate that software 100% was ‘maintained’ by PhD students with x years of funding in which they 1) had to get their thesis done. 2) had to get their thesis done. 3) etc.

Spending a few months to make life easier for your successors just isn’t worth it. And yes, it might be worth it at the start of your PhD, but then, you don’t know the software well enough to dare embark on such a journey.

Also, it’s quite possible none of those PhD students had decent schooling in software engineering.

You even worked for a company that was not in software or IT?

"If it works, why change it?"

What people miss from the story is why it was so important that Microsoft do that (and it's a similar reason to why Linus insists on never breaking userspace).

If it's the comedy post on reddit[0] then that's not how you determine which version of windows you're running on[1][2].

[0]: https://www.reddit.com/r/technology/comments/2hwlrk/comment/...

[1]: https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

[2]: https://learn.microsoft.com/en-gb/windows/win32/sysinfo/vers...

Same reason we never had an iPhone 9. Other companies skip the number 9 too for the same reason.

Companies will not admit this in public as to not offend the CCP or it's people. It's why their reasons when questioned tend to seem a little odd or incomplete.

Since the performance upgrade between intel to apple M is less critical than power to intel, that there is less incentive to move from intel, and that apparently apple uses it an opportunity for virtualization compat', Rosetta 2 might be here longer, but i'd be careful on any assomption :)

https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

Basically, if you want to break any piece of software, there's a locale for that.

And some design decisions are.... iffy at best. Like the fact now every DM have to implement its own mouse(trackpad etc.) management coz "well we don't wanna" (basically, I'm sure Wayland developers have better articulated response to why everyone else involved have to duplicate the code).

Or how many hoops software have to jump just to record screen (or is that fixed now?)