From: news@cct-net.co.uk   
      
   On 03/07/2025 17:33, bill wrote:   
   > 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   
   >   
      
   +1   
      
   --   
   Chris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)