Sujet : Re: Bootcamp
De : news (at) *nospam* cct-net.co.uk (Chris Townley)
Groupes : comp.os.vmsDate : 03. Jul 2025, 17:47:04
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <1046c69$552f$1@dont-email.me>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
On 03/07/2025 17:33, bill wrote:
On 7/3/2025 10:56 AM, Arne Vajhøj wrote:
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.
>
Please stop feeding the troll. He is going to continue to insist
that the only survival for VMS is to become another Linux distribution.
You can't win. Starve it and let it die.
bill
+1
-- Chris