What Is a PC Compatible?(codon.org.uk)
codon.org.uk
What Is a PC Compatible?
https://codon.org.uk/~mjg59/blog/p/what-is-a-pc-compatible/
31 comments
> 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.
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.
True. Also, timing and so on. The thing is "can run applications" was a rather load carrying part of my statement.
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.
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.
(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.
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.
You would presumably supply usb floppy drives on the way back in time, and then you'd be alright. And an ethernet NIC with 10base2 and AUI for thicknet, cause twisted pair wasn't typical that early.
Network booting PCs happened a lot later, but if the booter used bios calls to access the disk, you could probably netboot that too.
Network booting PCs happened a lot later, but if the booter used bios calls to access the disk, you could probably netboot that too.
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.
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.
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.
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.
> 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.
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.
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.
It's a single binary.
And produces binaries that are smaller than a typical single-OS build.
> 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.
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.
> 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.
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.
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.
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.
Apparently this is Matthew Garrett's blog. It contains one article.
Looking at his more common blog, https://mjg59.dreamwidth.org/ ... it says he's moved to this one.
Any particular reason he's no longer using Dreamwidth?
Looking at his more common blog, https://mjg59.dreamwidth.org/ ... it says he's moved to this one.
Any particular reason he's no longer using Dreamwidth?
Just glancing around, dreamwidth is hosted on AWS, and this blog looks like it's hosted on mythic-beasts.com which is a uk-based hosting provider. No idea if that's it.
It is mjg59 - he posted it on January 4th.
https://bsky.app/profile/mjg59.eicar-test-file.zip/post/3mbm...
What does this mean?
Most Planets should be updated already (I've an MR open for Planet Gnome)
Most Planets should be updated already (I've an MR open for Planet Gnome)
"Planets" were public feed aggregators collecting RSS (RDF, Atom) feeds for blogs on a specific topic, so you can go to a "Planet" and find all recent blogs by all people from that community. Thus a place to discover recent things, without following everybody individually.
In this case it is referencing https://planet.gnome.org/ which collects many Gnome people's blogs. And the statements tells us that the subscription was sulfated, so users of "Planet Gnome" don't have to do anything, but may continue consuming from there.
In this case it is referencing https://planet.gnome.org/ which collects many Gnome people's blogs. And the statements tells us that the subscription was sulfated, so users of "Planet Gnome" don't have to do anything, but may continue consuming from there.
The section about the transition from BIOS to UEFI really sums up why hardware support is such a nightmare to maintain. I remember dealing with those old IRQ conflicts back in the day, and I certainly do not miss it. It is accurate to say that a PC is just whatever we agree it is because the technology has drifted so far from the original design.
>>> When BIOS interfaces weren’t sufficient they hit the hardware directly - and even if they weren’t doing that, they’d end up depending on behavioural quirks of IBM’s BIOS implementation.
This happened with the Apple II as well, and made it impossible for Apple to update their system. Even minor changes, from the Apple II to the IIe and IIc, broke some apps. And if an app broke, it was presumed to be the hardware maker's fault.
There was a book entitled "what's where in the Apple II" that documented all known variable locations and entry points in the Apple ROM and DOS. For instance people would just branch directly into weird places in the ROM, or poke directly into memory.
This happened with the Apple II as well, and made it impossible for Apple to update their system. Even minor changes, from the Apple II to the IIe and IIc, broke some apps. And if an app broke, it was presumed to be the hardware maker's fault.
There was a book entitled "what's where in the Apple II" that documented all known variable locations and entry points in the Apple ROM and DOS. For instance people would just branch directly into weird places in the ROM, or poke directly into memory.
Even back in the day, computers which ran the PC versions of Lotus 1-2-3 and Microsoft Flight Simulator without issue were judged "100% PC compatible".
These days, a PC is pretty much defined as a computer that runs Windows.
These days, a PC is pretty much defined as a computer that runs Windows.
In the 1980's, computer software was sold in catalogs and magazines. Users had either of three platforms: A Macintosh, a PC-Compatible (probably x86), or a Commodore/Amiga. So these are the three categories were there to help you order the correct version of oregon trail. They were really a name for the operating systems, not the specifics of the hardware, at least back then they were.
And Atari…
I never saw Atari software for sale in the same magazines, but I'm sure it was available somewhere.
That's late 80s.
Early 80s very different.
Early 80s very different.
Fantastic article! You nailed the core irony perfectly: the term "PC Compatible" was almost a misnomer from day one, because even in the heyday of cloning, a "compatible" machine could choke on software that poked the hardware directly or relied on the quirks of IBM's specific BIOS. True compatibility was always a spectrum, not a binary state.
It’s a great example of a technological anachronism—a term that outlives its original meaning. We have plenty of those, for example, we still "dial" a phone number on a keypad, "hang up" a call without a physical receiver to hang, and save a file to a "desktop" that’s often just a digital metaphor.
So really, "PC Compatible" fits right in: a useful, socially-agreed-upon label that’s more about practical expectation than technical purity. Thanks for the insightful read—it definitely brought a smile to my face. Cheers
It’s a great example of a technological anachronism—a term that outlives its original meaning. We have plenty of those, for example, we still "dial" a phone number on a keypad, "hang up" a call without a physical receiver to hang, and save a file to a "desktop" that’s often just a digital metaphor.
So really, "PC Compatible" fits right in: a useful, socially-agreed-upon label that’s more about practical expectation than technical purity. Thanks for the insightful read—it definitely brought a smile to my face. Cheers
>So, what’s a PC compatible? No modern PC will run the DOS that the original PC ran.
Now define "modern PC". Oh boy, we've hit a dependency loop.
PC compatible means your software runs without error on MS-DOS. That's the definition I've used for 3 decades, and it should not change due to bloggers' retrospective. Of course, 100% IBM PC compatible is a level above this, when your software works exactly as if it were running inside an IBM PC.
Now define "modern PC". Oh boy, we've hit a dependency loop.
PC compatible means your software runs without error on MS-DOS. That's the definition I've used for 3 decades, and it should not change due to bloggers' retrospective. Of course, 100% IBM PC compatible is a level above this, when your software works exactly as if it were running inside an IBM PC.
What software? The Apricot ran DOS but didn't implement a full PC-compatible BIOS, so some software would work and some wouldn't. Even back in 1984 people didn't call it a PC compatible.
Great article
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.