[BirAdam]

> The truth is that there’s no way we can technically describe a PC Compatible now - or, honestly, ever. If you sent a modern PC back to 1981 the media would be amazed and also point out that it didn’t run Flight Simulator.

For historical context, a PC compatible is a machine that can run a DOS that is compatible with PC-DOS and that can run applications for the IBM PC running PC DOS. This was vital to the success and failure of many companies and thus we can absolutely say what a PC compatible was. The PC-compatible standard was largely replaced by WinTel compatible in the late 1990s. Modern machines can still run Win32 and applications written for Win32, and thus are WinTel compatible.

Of course, being WinTel compatible matters less than ever before. Much of the software people care about is now either browser-based or open source and compiled for multiple targets. We also now have dynamic recompilers that are quite good, and therefore even being compiled for the target is... well, not as important.

We need some new kind of standard that identifies general purpose, superscalar CPU with large cache and SIMD, a PCIe controller with many lanes, a memory controller for DDR4/5 paired with UEFI and either a modern GPU or a decent NPU (or both). Currently, this describes a few RISC-V machines, many ARM machines, and most AMD64 machines after about 2018. Maybe this is something like 5th Generation Industry Standard Architecture or 5SA? Whatever the industry does or doesn't call it, it's certainly not PC compatible in any sense.

[Someone]

> For historical context, a PC compatible is a machine that can run a DOS that is compatible with PC-DOS and that can run applications for the IBM PC running PC DOS.

Historically, a lot more was required in practice. For example, programs that use the BIOS for screen I/O are slow, so most programs wrote directly to video memory. Because of that, video memory had to be laid out identically and had to be located at the same address.

See https://en.wikipedia.org/wiki/IBM_PC_compatible#Non-compatib... for other examples.

[BirAdam]

True. Also, timing and so on. The thing is "can run applications" was a rather load carrying part of my statement.

[trollbridge]

A modern PC can most certainly run Flight Simulator. Most PCs still have an EFI that provides a CSM. And most GPUs default to running a program that provides VGA (and thus CGA) compatibility.

What's even more surprising is that it functions properly, other than a timing issue with the World War I Ace mode.

If you want to run FS 2.11 or earlier, you will need to get a cracked copy, since its copy protection requires using a diskette version. But "PC compatible" has never required diskette drives - the original IBM PC included an edition with no diskette drives at all.

[fsckboy]

(I'm personally more on your side of the argument than not, but need to point out literal details of the "standard" that is under dispute)

the article says if we transported back to the early 80's people would have said "it doesn't run Flight Simulator", so what that would have meant?

the original Flight Simulator for the IBM PC--first independently produced, then purchased by Microsoft--booted itself directly from the floppy; meaning, you had to reboot in order to run it; and it had its own "custom operating system" or really no operating system at all, something more like a kernel, or just an app.

yes modern "PC compatibles" do have some means of running that old software, but it won't work out of the box atm.

[BirAdam]

On the Intel side of things, Skylake retired VGA support.

Modern UEFI implementations do not universally support BIOS, which means things like https://github.com/FlyGoat/csmwrap are required.

Also, timing problems are a major reason for the transition to "WinTel" rather than PC-compatible... along with things like 8bit ISA support.

[the__alchemist]

This is a fantastic explanation! I've been thinking about software/binary compatibility lately. I think even before crossing the CPU arch barrier you mention, we could cross the OS barrier. Windows apps are generally mutually compatible. Within Linux is dicier. I've found some rules of thumb (compile on the oldest version you wish to support), with some cross-distro compat.

Some things like MUSL and manylinux are nice! I would love to see all OS barriers to compatibility knocked down. Or at least be able to make a single "Linux" binary. The CPU type barrier is obviously larger, but I think the OS one shouldn't exist.

Maybe we would need standard abstractions for things the OS provides like file system, date/time, allocator, threads, networking. The things programming languages abstract over in their std libs, but at an OS/compile level.

[thewebguyd]

> Or at least be able to make a single "Linux" binary.

Isn't this what Flatpak/Snap/AppImage try to solve?

Though lately they may not even be necessary. There's a lot less difference between distros now than there used to be in the past. All the majors seemed to have coalesced around the same userland stack, largely thanks to SystemD. If you ship something for Ubuntu LTS, there's a really good chance it'll also work on Fedora, Debian, Arch out of the box.

[ElectricalUnion]

jart Cosmopolitan. It combines a polyglot format (the αcτµαlly pδrταblε εxεcµταblε is simultaneously a Windows Portable Executable and a Thompson Shell script) and a polymorphic libc that works in all major OSes under both amd64 and arm64.

It's a single binary.

[littlestymaar]

> Modern machines can still run Win32 and applications written for Win32, and thus are WinTel compatible.

This is being repeated continuously but in reality this isn't the case in practice: Half if not more of the videogames I owned in the 90s stopped working on Windows XP, and some of those which kept working also failed under Vista/Win7. If you sent a modern PC to the media from 1990, they would indeed notice that their favorite game cannot run on it, despite the general compatibility effort from Microsoft.

[cogman10]

> many ARM machines

ARM that supports UEFI? I wouldn't say that's many devices. All the other support is there, but the UEFI is notably missing (at least at the consumer level). That's part of the reason why it's almost impossible to buy an ARM linux laptop that doesn't have some hacky vendor specific kernel.

[giancarlostoro]

If that's the case... You could send any machine with FreeDOS installed and really blow their mind, or at least I would think so? I'm not sure how well maintained FreeDOS is for more modern hardware. I assume it would still install and run.

[BirAdam]

The primary issue is that even with FreeDOS, if you're not using 8bit ISA, PC BIOS or compatible, and if your CPU is too fast, it wouldn't meet the standard of running PC DOS applications in any usable sense.