Windows has changed the kernel interface more often than Linux.

This fact alone throws this commonly held belief to the wind.

Glibc provides binary compatibility to newer versions too.

Shims exist in both, “windows compatibility layer” for example, but pulseaudio can emulate ALSA- and pipewire can emulate pulseaudio and ALSA.

It’s actually a quagmire, but I would contend that either has solid story for backwards compatibility depending on the exact lens you’re looking at. Microsoft is worse than Linux in many ways.

Microsoft sort of only wins in the closed-source, “run this arbitrary binary” race - if you totally ignore the w10/11 UWP migration that killed a lot of win32 applications, but drivers for older hardware are much more long lived under linux.

▲

zigzag312 4 days ago | parent | next [-]

What win32 apps were killed by UWP migration? When UWP was added win32 wasn't removed. Win32 applications still work.

> Microsoft sort of only wins in the closed-source, “run this arbitrary binary” race

That is actually a big win as some manufacturers only provide binary blob drivers and a lot of commercial software is distributed as binaries only.

▲

dijit 4 days ago | parent [-]

Binary applications do not include drivers. I only mean applications, drivers do not transfer cleanly between versions of Windows.

To answer your other question though; Any GDI that is not accessible through DirectX- The Contacts API, Timers API, BITS (Background Intelligent Transfer Service), The inbound HTTP server API, NDF (Network Diagnostic Framework), SNMP.

AllocConsole and ReadConsole are gone, NamedPipes (something I used to use extensively) are gone. Toolbar and Statusbar APIs are gone and direct manipulation APIs for the Desktop.

I mean, I can keep going.

▲

int_19h 4 days ago | parent | next [-]

You are describing limitations on sandboxed UWP apps, but Windows still supports regular Win32 just fine, and everything that you describe is available there.

I still run 30 year old games on Windows and write new software using WPF and WinForms even, and it all "just works", much more so than similar attempts at software archeology on Linux.

It's really too bad that Microsoft is hell bent on shoving ads, AI, and dark patterns everywhere in what could otherwise be a decent boring "it just works" OS.

▲

zigzag312 4 days ago | parent | prev | next [-]

Surprising amount of drivers do transfer between versions of Windows, even if not officially supported. But yes, most break at some point.

I'm able to run binaries compiled over 20 years ago on the latest version of Windows most of the time. They do require enabling compatibility mode and sometimes installing legacy features.

I don't know, if APIs you mentioned are available in compatibility modes, but at least named pipes can still be enabled.

But Windows is going downhill lately, so backwards compatibility isn't what it used to be. Improving backwards compatibility for running old binaries would make Linux adoption easier. I hope that Linux PCs market share keeps improving to cross the threshold where it becomes an economically viable platform for most of commercial software.

	▲	4 days ago \| parent [-]
		[deleted]

▲

71bw 4 days ago | parent | prev [-]

>AllocConsole and ReadConsole are gone

...sorry, what? I use these intensively and they are still available to use.

▲

ectospheno 2 days ago | parent | prev [-]

> Windows has changed the kernel interface more often than Linux. This fact alone throws this commonly held belief to the wind.

Every Windows release I compile code straight from a Windows programming book from the 90’s. The only changes I made last time was a few include statements and one define.