From: arne@vajhoej.dk   
      
   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.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)