Re: Bootcamp

Lawrence D'Oliveiro <ldo@nz.invalid> 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