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.

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.

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.

>AllocConsole and ReadConsole are gone

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