In article <
10465mq$62th$1@dont-email.me>,
Arne Vajhøj <
arne@vajhoej.dk> wrote:
On 7/2/2025 7:32 PM, Lawrence D'Oliveiro wrote:
[snip]
You keep pushing that idea.
And you keep humoring a troll.
Of course, the troll's idea is bad. That said....
But:
[snip]
5) The idea of emulating one OS on another OS is questionable
in itself.
This really needs to be qualified, as it is common and has been
done for decades. Evaluation criteria must include a) the
complexity of the emulation target, and b) its alignment with
the existing system design. Consider PA1050 on TOPS-20, for
example: this was a type-2 hypervisor that allowed the
DECSYSTEM-20 to provide very faithful emulation of TOPS-10. But
TOPS-20 is argably closer to TOPS-10 than, say, VMS is to
Linux. And since TOPS-20 used a different mechanism for
trapping into the executive for system requests than TOPS-10, it
was easy to distinguish between the two.
On the other hand, things like gVisor, which emulates the Linux
kernel interface, are very complex and difficult to get right.
And of course the PDP-10 was a much simpler machine than x86_64.
It is not that difficult to achieve 90-95%
compatibility. But 100% compatibility is very hard.
For systems that are very precisely specified and where the
target is very faithful _to that specification_ it's not so bad.
The real hard part is providing compatibility for areas where
the implementation differs from the specification. Linux, in
particular, is very bad in this regard: the maxim from Torvalds
to "not break userspace!" means that when surprising or
unintended behavior is discovered, more often than not, it
becomes a de facto part of the interface (since some userspace
software somewhere may depend on it).
Other systems are far more rigorous about giving compatibility
guarantees at the behavioral level.
Because
the core OS design tend to spill over into
userland semantics. It is always tricky to emulate *nix
on VMS and it would be be tricky to emulate VMS on *nix.
Getting DCL, image activation, process permanent files,
subprocesses, logicals and symbols working 100% compatible
on a Linux kernel would not be easy. A lot hang on the
4 mode design and DCL being in S.
Those things, specifically, probably wouldn't be that bad, given
the internal task system used by the Linux kernel. Much harder
are the undocumented assumptions about how the system behaves.
I imagine that things like mailboxes and ASTs might be
challenging to emulate well. The latter may be ok; since POSIX
real time signals were modeled after VMS ASTs, if the system
provides good support for them, it may be possible to build ASTs
that interact well with the rest of the system. A much harder
area, in my estimation, would be the IO subsystem, which is
rather different.
- Dan C.