From: bill.gunshannon@gmail.com   
      
   On 7/3/2025 10:56 AM, Arne Vajhøj wrote:   
   > On 7/2/2025 7:32 PM, Lawrence D'Oliveiro wrote:   
   >> On Wed, 2 Jul 2025 14:01:46 +0200, gcalliet wrote:   
   >>> Le 02/07/2025 à 02:05, Lawrence D'Oliveiro a écrit :   
   >>>> I would say their market is a fraction of what it would have been if   
   >>>> they had been ready with an x86 port say, five years earlier.   
   >>>>   
   >>> Of course.   
   >>>   
   >>> But also VSI didn't really address the ecosystem as the complex set it   
   >>> is, with totally different needs and paces of evolution.   
   >>   
   >> Essentially all the (remaining) customers were waiting to move to x86,   
   >> because all the existing platforms that VMS ran on were dead-ends 10   
   >> years   
   >> ago. The only strategy left to VSI was “run as fast as possible”.   
   >>   
   >> We discussed this sort of thing in this group a few years ago. The   
   >> obvious   
   >> way it seemed to me to get to a shipping product as quickly as possible   
   >> was to re-implement VMS as an emulation layer on top of a Linux kernel.   
   >> Chuck away all the internals of the super/exec/kernel-mode legacy   
   >> baggage:   
   >> keep just the userland APIs and DCL. Hardly anybody would care about   
   >> anything else.   
   >   
   > You keep pushing that idea.   
   >   
   > But:   
   > 1) Third party user mode emulations has existed for decades, but   
   >     there is still demand for VMS, so the hypothesis that   
   >     "Hardly anybody would care about anything else" does not   
   >     match with the real world.   
   > 2) The assumption that it would be easier to rewrite user mode   
   >     stuff to use Linux kernel than rewrite VMS kernel to support   
   >     x86-64 has been rejected by everyone that has spoken on the   
   >     topic *and* has actually worked on VMS.   
   > 3) The kernel is only a part of the project - an important part   
   >     but still just a part. Another huge part has been the compilers.   
   >     Getting Fortran, Pascal, Cobol and Basic compilers that   
   >     accept all the traditional VMS extensions so existing code   
   >     continues to compile has been a huge effort.   
   > 4) As with any software project writing the code is just a   
   >     part of the project. On top of that comes planning,   
   >     project management, testing, documentation etc.. The number   
   >     of hours for does not depend much on the technical implementation.   
   > 5) The idea of emulating one OS on another OS is questionable   
   >     in itself. It is not that difficult to achieve 90-95%   
   >     compatibility. But 100% compatibility is very hard. 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.   
   >   
      
   Please stop feeding the troll.  He is going to continue to insist   
   that the only survival for VMS is to become another Linux distribution.   
   You can't win.  Starve it and let it die.   
      
   bill   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)