Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: bill <bill.gunshannon@gmail.com>
Newsgroups: comp.os.vms
Subject: Re: Bootcamp
Date: Sun, 6 Jul 2025 11:02:01 -0400
Lines: 69
Message-ID: <mcvhfcFk40nU1@mid.individual.net>
References: <100jfjh$2l94e$1@dont-email.me> <1020odr$2t5n5$1@dont-email.me>
 <mchom4F15kcU1@mid.individual.net> <1041t4b$349i3$4@dont-email.me>
 <mckld9Fg08sU1@mid.individual.net> <1044fhf$3p5ha$5@dont-email.me>
 <10465mq$62th$1@dont-email.me> <10470qi$d897$2@dont-email.me>
 <104cgf1$vk0k$1@paganini.bofh.team>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net ZbiTAX6FZpAnMNccmhYZHg667D18L7jIoLe1KI2ox/MOAAz1mU
Cancel-Lock: sha1:pWBTK8maX/sJje7NhNmMO4c/p5M= sha256:W5vDfCN9FwrQH2QCsCn4qxoViv4tr3nbA+gvFvOkv2M=
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <104cgf1$vk0k$1@paganini.bofh.team>

On 7/5/2025 8:36 PM, Waldek Hebisch wrote:
> 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.
> 
Please stop feeding the troll.  He is a Linux weenie, couldn't
care less about VMS and would love to see it turned into just
another Linux distro.

bill