[Info-vax] Creating an open source version of VMS, was: Re: OpenVMS Hobbyist Notification
Simon Clubley
clubley at remove_me.eisner.decus.org-Earth.UFP
Tue Mar 10 15:05:26 EDT 2020
On 2020-03-10, roger.ivie at gmail.com <roger.ivie at gmail.com> wrote:
> google "freevms"
I'm familiar with FreeVMS. One major mistake it made was trying to
emulate the existing VMS design in great detail at a far lower level
than it should have done.
For example, it decided to keep supervisor mode and tried to emulate
the required additional hardware level by other means within its design.
I on the other hand say that supervisor mode should be utterly discarded in
any VMS like open source operating system and never heard from ever again.
Supervisor mode, as implemented within VMS, is an hideous abomination
and most normal applications simply don't need it as it is currently
implemented.
In a modern design, the shell (DCL or otherwise) would live in a parent
process and a modern version of sys$cli() can be a normal system service
which passes messages between the program and the shell. The shell would
be just another normal user-mode program which registered itself to receive
and reply to those messages.
That also means you would have a sane version of the image activator which
activates the image in one go without the shell needing to be involved
_during_ the image activation process.
The above is a good example of the kind of thing I am talking about.
The application program would still have the same calls to interact with
a modern DCL in its source code but the implementation is completely
different, and the differences are hidden from the application source code.
Other things I would get rid of would include any support for Macro-32.
No-one writes normal applications in assembly language any more and
modern compiler capabilities have made even the speed critical parts
of programs less likely to need assembly language. Even when assembly
language is required for speed in normal applications, you are going
to be using the native assembly language anyway instead of Macro-32.
There could also be a strong emphasis on a truly modular kernel design,
so that XQP (for example) would be discarded and replaced with a modular
plug-in architecture.
My point is that you can have a vastly improved design that looks nothing
like current VMS internally and yet still manages to present a strongly
compatible VMS environment to normal VMS application source code written
in C or other higher level languages.
Simon.
--
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
More information about the Info-vax
mailing list