And, indeed, you can't remove Windows Update. Nor (in more recent versions) the Add or Remove Features component in Control Panel— er, sorry, the Settings app. So long as you can still re-install Internet Explorer without a web browser (which I think you have always been able to, ever since the days IE came in a box), there's no reason to stop you removing it.

Microsoft did have legitimate reasons to integrate the browser engine in Windows 95, what with the whole Active Desktop, HTML Application, the-web-is-the-future schtick they were going for. But that isn't one of them.

... and Linux (well, Ubuntu specifically). I'm staring down the need to upgrade from Ubuntu LTS 20.04 to Ubuntu LTS 22.04 because some software I maintain now relies on GLIBC v2.32, which is an absolute bear to back-port. The party line is "So just upgrade," but there's no guarantee my hardware is compatible with Ubuntu LTS 22.04 because the vendor doesn't support that config and I'm not really interested in dealing with all the joys of figuring out every fiddly-widget little config on a laptop to make it work myself.

Microsoft is nearly unique in caring that much about backwards compatibility. It's the value-add they bring to the market these days relative to the competition.

So it's your vendor who doesn't care about backwards compatibility - Linux does. Whatever hardware you have, once it was supported, it will stay this way until it is really ancient, and even then you will have special builds that will support it. That's the beauty of open source (or even source available) licenses. No corporate interests that would render your solution obsolete. [0]

[0] assuming your hardware doesn't need some binary blobs (khm nvidia khm) to work

(b) If Ubuntu (and I'm going to say "the Linux ecosystem in general") cared about backwards compatibility in the same sense Windows does, a minor-version bump to glibc wouldn't introduce API breakages that mean I can't build a codebase that's doing nothing new and special on my machine right now purely because a 31-subver bumped to a 32. They aren't doing anything new in the code; their JNI dependency just bumped up and so they bumped up the whole codebase's requirements.

That's fine, but it's not The Windows Way. The Linux Way doesn't think about compatibility issues like that in anything like the same way. It's a source-code-and-patch-it-yourself world. The approaches are completely alien to each other.

The reverse scenario that seems to be what you have - where you compile against a newer library version then run it on an older one - is forwards-compatibility which is a different kettle of fish. Even on Windows it's not like you can compile against the latest DirectX and run it on an older Windows?

It was actually a great feature (memory may be failing at this point), and it seemed like the filesystem viewer was IE presenting a filesystem view. If you typed an http or https URL, the window would turn into an HTML renderer window. This made it possible to build their mail and newsgroup reader apps as filesystem views. Mail was nothing but a folder full of email message files. News was, surprise, a folder full of newsgroups. Those viewers were responsible with synchronizing the folder with remote services.

I would love if Gnome would allow pluggable views in Files: a mail reader for maildir folders, a music player for folders full of audio files, and so on.

This is essentially what Gvfs is for except basically nobody uses it, at least in the ways you describe, because forcing non-FS things into the shape of a FS usually doesn't work very well. So instead Gvfs gets used for relatively simple things that naturally map onto the FS concept well, like mounting archive files, browsing FTP, etc.

There are hundreds of instruments like this in any given research institute, all because Microsoft decided unilaterally that software that ran fine 20 years ago is clearly useless and doesn't need to run anymore on modern hardware that receives security updates.

Would you expect a 20-year-old Linux to install just fine on a modern PC? I remind you that this was the era of RHEL 3! I had trouble getting RHEL 6 running in a virtual machine just recently.

Meanwhile XP will run on most modern PCs, it’s just not supported. That means no security patches.

The mistake here is not Microsoft’s.

The mistake is your organisation’s for buying a half-million-dollar device with no support plan from the vendor for its control OS.

Software using a lib I wrote in 1998 doesn't work anymore but it's because I took a bad shortcut that made DOS-era assumptions, fixing/recompiling it would be the right course of action but I haven't had the time (also not sure where all the sources are).

On a contrary note, my first USB-Wacom pads STILL work after 20 years, it's not just software but a vendor that cared about it's software long enough to make 64bit drivers that still works.

As you said, the vendor isn't interested in upgrading the software and there is where the blame is, MS tries to keep backwards compatibility but some things has had to go for performance and/or security reasons over the years and those usually broke rules (or were tied to HW, Linux has dropped 386 and 486 after all).

If this is some multi-million dollar device then maybe keeping it up to date with windows should have been part of the deal...

Did you know windows is basically known for excellent backwards compatibility? https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

I love my customer's maintenance department, they're unusually thorough and attentive to preventative maintenance, greasing and oiling and replacing wear items, root-causing failures and keeping the machines in good working order for decades. But when you keep fixing each individual small part that breaks, eventually the market moves on and you have to throw all the replaceable parts away and start over. The process requirements haven't changed, the weldments and castings aren't broken, it's just that you can't replace a failed servo drive or Core 2 motherboard or ISA card because the supply chain gave up on them 10 years ago. There's no great advantage of Windows 10 LTSC and a 64-bit Arm controller over Windows 98 with 56002 ISA cards except that I can buy the former today and I can't buy the latter because no one makes them anymore.

There is no control OS or hardware supply chain that lasts as long as military, industrial, or scientific equipment can be made to last. Fanuc and others try with massive vertical integration and a "never deprecate anything" mantra, but they don't run their own semiconductor fabs to guarantee production of chips for stuff that doesn't keep up with the rat race.

Yes, I'll keep supporting my company's gear for as long as possible, but sometimes the answer is that I need to throw away 4 working servomotors, drives, a controller, and a PC, and invest 600 engineering hours into making this machine do the exact same thing it did last week, because that 5th drive blew the IGBT and took out the controller and no one can get a replacement. Customers don't like to issue $100k invoices when a $1k subcomponent dies...because that $1k quote was from 2008, and it's now literally priceless.

Unfortunately, though, just using a CAN or Ethernet physical layer doesn't solve the problem of the https://xkcd.com/927/ standards proliferation of industrial protocols: Some customers require CIP motion over Ethernet/IP (a dog-slow Rockwell proprietary protocol), there's old MACRO fiber optic rings, Sercos III (and prior serial protocols), a dozen high-speed serial standards for communicating with absolute encoders, and, of course, good old-fashioned hardwired digital I/O - which might be either analog velocity/torque or step and direction, RS422 differential or single-ended, etc. etc. etc.

You'd hope that you could just plug something that spoke CAN or Ethernet into something else that has the same physical interface, and the two would work together. Sometimes, you get lucky and that works out. But the ever-forward march of industry leaves behind a graveyard of yesteryear's abandoned products and protocols.

E.g.: If you make 30 different kinds of industrial machines, have one controller board as an additional product for a total of 31 SKUs.

When the controller board is too old and no longer supported, make a new SKU that is backwards compatible with the old machines.

E.g.: Some televisions allowed the entire controller board to be swapped out, upgrading the TV's OS and HDMI ports with new capabilities. The panel and the case stayed the same.

Similarly, a CNC router or whatever is "just" some analogue wires that go into a digital board. Make the digital board swappable.

A similar mistake that I see is customers that are used to "archive grade paper" asking me how long digital backup tapes last. That's the wrong question!. The important thing is to be able to copy from old tapes to new tapes with full fidelity, which digital technology enables, but analogue technology does not. You can retain data indefinitely with digital media that lasts just a few years. Instead of trying to scrounge up some old floppy or CD readers, just copy the data to BluRay, then cloud storage, and then... whatever.

I see no reason why the data collection can't be managed by a highly portable console app running inside a VM or dos emulator or the legacy PC can't be kept behind a firewall that only lets data out.

Having been in this exact situation at a research institution with expensive equipment and Windows XP only software before - support.

Helpdesk and lower levels of back-end only pay a certain amount so turn over constantly, and “those PCs have had hot glue put in their ethernet jacks and USB ports and burning CDs is the only way to get data out” is a hell of a lot easier to reliably keep going than some esoteric system of VMs and firewall rules.

The people in the lab have way more tolerance for having to burn CDs than they do for firewall changes stuffing up their process and taking a while to figure out and resolve!

Only because I had the same thought and I feel like you might know more, is there an example of software that does this securely?

Command line Posix stuffgenerally works and Linux stuff works because Linus insists it should.

But what about the whole glibc debacle from about a decade ago? Entire distros broke compatibility.

And let's not get started with *nix GUI framewors and apps, those break compat more often than I change my socks :-)))

The reason is most likely... because the driver relies on APIs that were insecure and removed in the XP-Vista transition!

> The vendor for the instrument has no incentive to update that software either; they'd rather you dish out another half million dollars for a new sorter. > There are hundreds of instruments like this in any given research institute, all because Microsoft decided unilaterally that software that ran fine 20 years ago is clearly useless and doesn't need to run anymore on modern hardware that receives security updates.

So it's Microsoft's fault that the vendor won't update it's software?

Didn't this "elite institution" get a support contract for the machine?

Would they expect the driver and software to still work if it had been written for a PowerMac G5, running Mac OS X Panther?

Would a binary compiled 20 years ago even have a remote chance of running on Linux?

Yes. As long as it includes all its dependencies, it should work because the kernel never deprecates system calls.

So unless the vendor distributes the source for the driver interfacing with the machine, it shouldn't run on modern releases.

So it seems like to me they do care about legacy support.

Maybe you just need to pay for it

If they didn't have the massive backwards compatibility, corporate users would essentially be free to choose a new OS platform every few years. By maintaining deep legacy software support, they make it easy for their customers to stay addicted to Windows.

MS is not doing this for your benefit, or out of some kind of dedication, it's pure capitalism.

There is tons of documented history of their anti-competitive behavior and deceptive practices. It is not very often that a CEO of a company in a market that is "working well" is called to testify in front of Congress.

That's a good thing. People wanting to pay for your stuff is a good sign that it's valuable to them, and thus worth doing.

The only reason we need IE shims at all is because MS botched their overall internet strategy. Had they made a truly competitive browser and supported common standards, and the user's ability to choose their browser, none of this would be needed.

>This is a very strange comment.

In around 2001 when MS was being tried for antitrust, they claimed that IE couldn't be decoupled from the OS because it would break the os. I believe that is what the OP is alluding to. I believe an unassociated professor managed to decouple it later.

https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....