Hacker News Reader

Comment by Loic | Hacker News Reader

I am so glad it does. During my PhD, I had to maintain a very old stack of software (about 1 million lines of C++ on top of 300,000 of Fortran).

It was not possible to compile it with something different than Windows 2000, it was not possible to upgrade the MFC version and all the old compilers.

It was basically stuck in time but with a very high value for the end-users and our research group had not the bandwidth to upgrade. Microsoft was nice with us and kept the compatibility and still keep the compatibility 20 years later!

I am using Linux as my daily driver, but I must say, Microsoft is the king of backward compatibility. A feeling of "compile once, run forever on Windows".

View on HN

> "Microsoft is the king of backward compatibility."

The thing is, this hasn't been true for a long time. At this point Wine/dosbox are far more compatible with old weird software than the current version of windows. For example, you can't run 16bit Windows programs at all on Windows.

You even have projects like otvdvm, running wine on windows to support older programs (or dosbox, which I think everyone is a lot more familiar with). http://www.columbia.edu/~em36/otvdm.html

The genuine article tends to be better while older platforms are supported, but at some point, inevitably, older platforms are dropped because supporting them costs money. When that happens, open source imitations end up with better support than the original.

> You even have projects like otvdvm, running wine on windows to support older programs (or dosbox, which I think everyone is a lot more familiar with).

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.

NTVDM and DOS/16-bit compatibility only died with the death of 32-bit Windows with 11. I'd say 40 or so years of backwards compatibility is pretty good.

It is really good. I'm not complaining!

But -- the OSS world is even better in the very long term.

It is and isn't. Really old stuff seems to work well. But just old stuff more often than not is unworkable. There's a serious issue in the Linux world with distros going down and software disappearing over time.

Forcing you to use 32-bit windows hasn't counted as proper support since at least the release of windows 7.

And more relevant is when people stopped releasing mainstream 16-bit programs, which is much much later when you consider all the 16-bit installers.

I believe 64bit WinXP was when 16 bit support was first dropped - circa 2005!

For XP, being on 64-bit was weird. Vista was transitional. By 7, 64-bit was the expectation for non-junk new hardware.

> For example, you can't run 16bit Windows programs at all on Windows.

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.

AFAIK not exactly, under 64bit mode you can run 16bit protected mode but not 16bit real mode code. While this would be an issue for Win1.x/Win2/x compatibility, the majority of 16bit Windows applications however are made for Win3.x which tend to be made for 16bit protected mode.

This is basically why you can run 16bit Windows programs/games under Wine on 64bit Linux (though you may need to enable some flag via /proc or /sys i don't remember the name of).

Correct, AFAIK the main reason to not support Win16 protected mode was the size the relevant bits of HANDLEs which would have been severely limited to 16bits. Completely obviating the reason to use 64bit windows. As is HANDLEs are 32bits of significant data on at least through Windows 10. In theory now that Windows 11 has dropped 32bit support could be 64bits on Windows 11. All of this because someone will inevitably want to use the clipboard between a 64bit app and a 16bit app and it would have made things VERY painful. Could MS have written a layer that "fixed" that? Potentially but the number of people using 16bit software was relatively small AFAIK at that point.

But the page tables do technically support 16bit protected mode code when in compatibility mode under long mode AFAICT.

It's worth stressing out that it's not just about 16-bit applications; even older 32-bit games for Windows that use things like DirectX 6 often work better under Wine than on Windows these days.

I can see a future where Microsoft wants to launch a platform for retro gaming products and has to use Wine as a reference implementation.

Linux has a rule to "never break the userland". So if you maintain your own userland(libc/gui libs, etc..) even the latest kernel will run your old software.

The 32-bit Oracle 8i database will no longer run on modern Linux.

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.

> "The 32-bit Oracle 8i database will no longer run on modern Linux."

Yes it will.

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

You're running into compatibility issues with newer libraries. Libraries do change in incompatible ways -- but the solution is simply to install the older library.

You absolutely can run 32-bit Oracle 8i on a modern kernel. The steps to do this in a nutshell (omitting a few details) are:

1) Grab a linux userland which 8i was built for (eg: RedHat7) and extract it somewhere. Use docker, create a chroot, whatever you like.

2) Enter the container/chroot and install 8i. It'll work fine, because you'll be linking the correct library versions and those libraries will still work even on a modern kernel due to the aforementioned kernel compatibility guarantees.

glibc != kernel

True, but users don't care why it breaks, only that it does, and most people consider "the distro" to be Linux.

So you probably CAN get old Oracle databases to run on the latest kernel, but all the supporting software would be a weird mishmash of old libraries, etc.

Alternatively: Just run it in a container using whatever version of whatever distro it did work on.

One doesn't need to make a mess of their host OS anymore.

Yeah, much of why VMWare became a big hit was "you can virtualize your weird Windows NT application and not have to maintain a Windows NT machine".

VMware is a different beast altogether. Maybe it'd remove the maintenance of a physical NT machine, but you'd still be maintaining the whole NT software system, and honestly that's most of the headache. Plus the overhead VMs have and all.

Containers run on your kernel and hardware natively, with a tiny bit of shims from the kernel side so it's a different root and possibly removing raw hardware access. Oracle 8i should run just as well as it would have 20 years ago, if you have all the userland libraries in order (hence putting an old distro in the container).

As long as Oracle isn't internet-facing (you can setup the container's networking however you wish, with whatever firewall rules you wish), it should be fairly safe. The modern kernel you run it on should be up to speed on the latest security patches too.

> It was not possible to compile it with something different than Windows 2000

How does software get that bad?

Windows 2000 was a major platform for 5+ years, so if you have a development environment on it and never moved it elsewhere, there will be lots of assumptions built-in.

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.

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

Yeah people tell me they're having problems migrating their Java 8 app to something modern and I can't understand why haven't they always been running all versions of Java in CI, including pre-releases, and just fixing the one thing a month that pops up as a problem. They can still run on Java 8, but they will know it's going to work fine everywhere, and if they find something that won't work in a future version they can engage the Java developers before they release it.

People do some of that, but Java 8 is in that weird state where it is Java for so many things that moving off of it can be incredibly hard. It took Mojang/Microsoft how many years to get Minecraft working on something that wasn't Java 8?

And that doesn't even cover the changes in the versions of Java 8 itself that break things - one even had to be reverted IIRC.

This is why you need runtime and compiler diversity in your cicd pipeline.

Ah but we do! We test on GraalVM and OpenJDK! (heh)

From the start.

Well, you chose a weird point for that example, because Java 9 is where the most Java projects break.

I don't know what you mean - if that's the case why didn't they realise that in like 2015, 2016, when these Java 9 features were added? And why haven't they been able to fix them since then?

I know about development realities, but seriously come on at some point?

Basically because Java 9 started fixing design issues, and they decided to keep Java 8 running forever.

I think Linux is the king of backwards compatibility, in that you can always download an old version of Linux and run your old software stack. Windows forces you to use a new version; Microsoft puts a lot of effort into backwards compatibility but it's always a gamble.

> in that you can always download an old version of Linux and run your old software stack.

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.

Pros and cons.

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.

Will that old version of Linux be able to run on a modern computer with working drivers for all the hardware? Backwards compatibility means that you can use the current OS with the current drivers and still run the old software.

... and will you dare put it on a network, with the unpatched security CVEs?

Where I'm from, you can still easily buy a Windows XP license. I've also seen a win2k license maybe about a year ago. Should have bought the box for nostalgic purposes when I had the chance now that I think of it.

Where can I get a legit license for XP that will activate?

MSDN still lets you download Windows 3.11; though I presume it's not licensed for "real use".

I think you will find this one amusing:

https://news.ycombinator.com/item?id=33158687

It's not quite as easy, but in a case like that I prefer to run the software in a VM using the version of Linux it was designed for.

Lets you keep "compile once, run forever" without crippling the rest of your software to support ancient or broken APIs.

> It was basically stuck in time but with a very high value for the end-users

I wonder why it wasn't properly maintained if it was such a valuable piece of software ? I assume they perform regular maintenance on all other high-value property they own ?

The OP also said “During my PhD, I”

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.

lol. lmao even.

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

"If it works, why change it?"

> I am so glad it does. [...]

I completely reject preserving backwards compatibility for the sake of application bugs.

Why should Microsoft produce a hack for a particular piece of software? That software might be used by a 10s, 100s, 1000s of people for a certain amount of time, whereas Windows itself impacts billions of people daily and will continue to do so for decades to come.

At some point the programmers, PMs, and maybe even the bug tracker behind these hacks will move on. Institutional knowledge is rarely forever. A newer generation of developers, PM, etc, will have to waste time understanding the bug, and deciding to support it or not. Possibly without ever knowing if the software in question has moved on itself, or is even in use anymore.

Say what you want about Apple, but rarely the words "badly aged" or "crufty" are used to describe their ecosystems. They are the stunning definition of darwinism at its finest.

And as a result, Apple platform developers have to tell their customers that Apple is breaking their stuff: https://help.steampowered.com/en/faqs/view/5E0D-522A-4E62-B6... which certainly doesn't earn them goodwill among the dev community.

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

Being able to run software is what makes a computer valuable. If you constantly break software, the computer is useless.

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.

> Why should Microsoft produce a hack for a particular piece of software?

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.

Apple is a terrible example to hold up for breaking backwards compatibility. Their capricious and self-serving changes are terrible for developers and users that just want their software to work.

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

Windows uses _shims_ for much of this stuff, so if you're not running the out-of-date program, it's not running anything different.

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

Microsoft has a systematic approach to applying these hacks so its less expensive for them to maintain them than it would be otherwise.

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

Reply on news.ycombinator.com