From: cross@spitfire.i.gajendra.net   
      
   In article <10465mq$62th$1@dont-email.me>,   
   Arne Vajhøj   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)