[Info-vax] Creating an open source version of VMS, was: Re: OpenVMS Hobbyist Notification

[Dave Froble]

On 3/10/2020 3:05 PM, Simon Clubley wrote:

Normally I would not have replied to this, however a few statements are 
a bit too prejudiced.

> 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.

Perhaps ...

> 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.

Really a prejudice, not shared by all.

> 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.

Really off the wall, since Macro-32 is not part of the OS.  At this time 
it is a compiled language.  Perhaps it caters a bit too much to rather 
extreme programming practices.  But in general it's just another 
language.  Machine specific issues, such as the AP, are emulated and do 
not actually access the hardware.

> 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.

Quite right.  However, there is existing code.  Thanks a lot for 
discarding my application(s).

> 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.

If all you want is a C environment, you already have it, leave VMS alone.

For the concept, I'd agree, in general.  Specifically, I'd avoid the 
prejudices seen in some "freeware".  "If I need it, I'll include it, and 
if I don't need it, then devil take the hindmost."

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486