From: antispam@fricas.org   
      
   Lawrence D'Oliveiro  wrote:   
   > On Thu, 3 Jul 2025 10:56:26 -0400, Arne Vajhøj wrote:   
   >   
   >> 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.   
   >   
   > It was always tricky to emulate *nix on proprietary OSes. But emulating   
   > proprietary OSes on Linux does actually work a lot better. Look at WINE,   
   > which has progressed to the point where it can be the basis of a   
   > successful shipping product (the Steam Deck) that lets users run Windows   
   > games without Windows. That works so well, it puts true Windows-based   
   > handheld competitors in the shade.   
      
   You mention Wine, but do you know what you are talking about?  At   
   the start Wine project had idea similar to yours: write loader   
   for Windows binaries, redirect system library calls to equivalent   
   Linux system/library calls and call it done.  The loader part   
   went smoothly, but they relatively quickly (in around 2 years)   
   discoverd that devil is in emulating Windows libraries.  Initial   
   idea of redirecting calls to "equivalent" Linux calls turned out   
   to be no go.  Instead, they decided to effectively create   
   Windows clone.  That is Wine provides several libraries which   
   are supposed to behave identically as corresponding Windows   
   libraries and use the same interfaces.  Only at lowest level   
   they have calls to Linux libraries.  In light of Wine experience,   
   approach taken by VSI is quite natural.   
      
   Why part has taken so much time?  We do not know.  One could   
   expect that only small part of kernel is architecture dependent.   
   Given that this is third port architecture dependent parts   
   should be well-know to developers and clearly speparated from   
   machine independent parts.  There are probably some performance   
   critical libraries written in native assembly (not Macro32!).   
   Of course compilers (or rather their backends) are architecure   
   dependent.  There is also question of device drivers, while   
   they can be architecture independent the set of devices   
   available on x86-64 seem to differ from Itanium or Alpha.   
      
   Given 40+ developement team (this seem to correspond to publicaly   
   available information about VSI) and considering 10kloc/year   
   developer productivity (I think this is reasonable estimate for   
   system type work) in 4 years VSI could create about 1.6 Mloc   
   of new code.  We do not know size of VMS kernel, but at first   
   glance this 1.6 Mloc is enough to cover architecure dependent   
   parts of VMS.  So one could expect port in 4-5 years or faster   
   if architecure dependent parts are smaller.  IIUC initial   
   VSI estimate was similar.   
      
   What went wrong?  Clearly VSI hit some difficulties.  Public   
   information indicates that work on compilers took more time   
   than expected (and that could slow down other work as it   
   depends on working compilers).  Note that compilers are   
   neccessary for success of VMS and in compier work VSI   
   actually worked close to your suggestion: they reuse   
   open source backend and just add VMS-specific extentions   
   and frontends.  But without knowing what took time we do   
   not know if some alternative approach would work better.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)