From: bill.gunshannon@gmail.com
On 7/5/2025 8:36 PM, Waldek Hebisch wrote:
> 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.
>
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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
