No, my computer is not a fast PDP-11. Rather, it is a much faster, much more advanced architecture, that's capable of emulating many fast PDP-11s at once.

Ever since virtual memory was invented, operating systems have been about providing a virtual environment for their programs, which generally gives programs the illusion that they have their own memory space, etc. The idea of VM/CMS is that each program gets its own CMS computer.

How is this really different from a hypervisor that's optimized to quickly spin up a unix userspace environment and run a process in it?

Also modern OSes generally have a way to detect different types of binaries and run them through the right binary interpreter, without having to resort to shebang shenanigans and modifying the file. WINE does it with .exe, so why can't/don't other emulators do this? Is it lack of a standard mechanism for setting it up?

It'd be great to just run an unmodified 8080 CP/M program on my terminal from bash just like I can run, say, /usr/bin/git? Maybe I'd need some qemu configuration to tell it where to find libraries, etc., but that's fair.

If wine can do it with .exe files, why can't we do similar with SunOS 3.5 or OS/2 or Minix or C64 binaries, via QEMU or SIMH or VICE or whatever? Sure, you'd have to install an emulator or runtime, but when you do, why not just get binary execution capability?

Is it just that nobody has done this, or it's not possible for some reason, or maybe someone has done it and I just don't know about it?

(Yeah there would be challenges, like being able to tell if a PRG file was for C64 or PET or C128 or VIC-20 or whatever, but it could be configuratble.)

@ben seems doable to me, the mechanism for determining how to pass executables is flexible enough to allow for that
binfmt_misc - Wikipedia

@rnd Thanks for the sanity check. Yeah I'm aware of that mechanism, and it seems like it was even created with this in mind.

I was mostly asking why aren't people using it (or are they, and I don't know)? Maybe there's a good reason I'm not aware of. Or maybe nobody bothered yet.

@rnd Looking into it further, it looks like it's not even that hard to set up. Maybe people do use it, but just set it up ad-hoc.
@rnd How cool would it be to type "donkeykong.prg" and have it just pop up x64sc running donkey kong? Or even myprogs.d64 and have it open with that mounted as drive 8? Or type spacewar and up comes your 1401 vector display.
@ben if i had to guess, it's that sufficiently integrating the more esoteric architectures in a way that doesn't feel weird would also imply being able to transparently pass on filesystem access to the emulated systems and figure out a way to have stdin/out/err passthrough -- possibly doable for the more unix-like systems, but unreasonable for something like a C64
@rnd Sure, but maybe for architectures like that, you fire up a gui emulator for them (which you would of course have to install, but it could set that up at installation time). As you and another person have pointed out, the capability exists, in binfmt, but seems sparsely used.
@rnd I may try to set this up for simh and vice and some others and see if I can automate it.

@ben @rnd people are using it (not only for windows/PE executables using WINE), but also for things like cross-platform builds and running the unit tests then in qemu-user. There's scarcely anything to set up; on most Linux distros you just install a package called "qemu-user-binfmt" in addition to "qemu-user-${yourtargetarchitecture}".

For that to work, the target OS needs to be the same (i.e., Linux here), which says you can't do that for an 8080, since there can't be a linux for that;

@ben @rnd and if not the same OS, in what state specifically do you start the binary?
But as you noted, binfmt_misc is quite flexible and simple, so, if you want to start, say, a NES cartridge image in your favourite emulator, go for i.