Windows should have a similar amount of compatibility. The API is basically the same at least as far back as Windows 3.1 (1992), and probably further (though I have no personal experience with programming for older versions of Windows).
Also, Windows 3.1 can be augmented with Win32s, which offers a subset of the 32-bit Windows API -- so it's possible for a single binary to run on Windows 3.1 all the way through Windows 10 (64-bit Windows does not support 16-bit executables). If you want to try this for yourself, Win32s is rather finicky, so executables produced by modern compilers won't run. I believe I used Borland C++ 5.5, which is now available as a free download.
It's actually interesting how similar a pure Windows API app for Windows 8 looks to one created for Windows 1.0. A fun example of this is Charles Petzold's birthday cake app:
Classic support was simply Mac OS 9 running in a virtual machine.
Carbon is a modernization of the classic APIs. If an app was ported to Carbon then it could run in OS X natively without the VM. Older apps that weren't ported to Carbon need a VM running a classic version of Mac OS.
You mean, the original System 1.0 of the 1984 era? Did not support threads, no.
There was a thing called "Desk Accessories", sort of single-window mini apps (think Calculator), that were implemented as a special kind of device driver. But IIRC even these were serviced by periodic calls to SystemTask() which would make sure every running device got some time.
To get around this, we hacked the OS in crazy ways. For example, all of the system APIs were in a big address table. So if you had loaded some code and wanted to get a little slice of execution time to yourself, patching your function's address into the table in place of SystemTask() was a common technique (not forgetting to call to the original SystemTask() address before finishing, of course)! Since everyone did this (including Apple), you can imagine the long sequences of hacks patching on top of each other would lead to a really unstable system. Hence the classic Mac OS reputation.
I once wrote a driver for a custom-built hardware keyboard which plugged in via the serial port. The keyboard driver was basically a Control Panel (CDEV) with an INIT resource that patched something (I'm guessing SystemTask() but my memory is hazy...not sure why I didn't just make it a straight-up device driver) to check for bytes from the keyboard, which it would post into the event queue, and they'd show up in the running application.
Another common technique for getting time slices was to use the interrupt manager, although that was dicey because calling into system APIs at interrupt time wasn't safe.
I, too, once wrote a driver for a hardware keyboard which plugged in via the serial port, and I did it the same way you describe. My recollection is that the keyboard/mouse driver system at the time assumed it would only be dealing with ADB devices. There was no abstraction for "a keyboard" or input device in general, there was just a system for interacting with ADB specifically and turning its input into events.
Many of the OS calls had asynchronous versions (PBHOpenAsync, etc) which add it to a queue for later processing and call your completion pointer when done. That was documented in Inside Macintosh Volume 1 (1985), predating Multifinder.
I could be wrong, but OS 9's Multiprocessing framework actually relies on multiple physical CPUs, from what I can tell - there's no way to use it or test in an emulator (I've tried in the past)
Also, Windows 3.1 can be augmented with Win32s, which offers a subset of the 32-bit Windows API -- so it's possible for a single binary to run on Windows 3.1 all the way through Windows 10 (64-bit Windows does not support 16-bit executables). If you want to try this for yourself, Win32s is rather finicky, so executables produced by modern compilers won't run. I believe I used Borland C++ 5.5, which is now available as a free download.