[Info-vax] CRTL and RMS vs SSIO

[Lawrence D’Oliveiro]

On Sunday, October 17, 2021 at 12:35:10 AM UTC+13, John Dallman wrote:
> In article <44512ead-b6e0-4735... at googlegroups.com>,
> lawren... at gmail.com (Lawrence D_Oliveiro) wrote: 
>
>> If VMS compatibility for user-mode code just takes the form of a
>> library to link against, then VMS-specific compilers shouldn_t be
>> necessary. You could use the existing GNU and LLVM compilers, and 
>> just implement wrappers that understand the VMS-specific options.
>
> Won't work without ludicrous amounts of effort.

The question is whether that effort is more or less than that of porting the whole of VMS, with its deeply-embedded hardware assumptions dating back to VAX days, to new hardware. I suspect it’s a lot less.

> There are subtle, but pervasive, differences in the process model, the i/o model,
> the error handling, and many other aspects of programming for the two operating 
> systems. That's why the Unix-emulation products for VMS have failed ...

That was the other way round. Here we are trying to emulate (core parts of) a more ancient system on a more versatile one.

For example, you know how on VMS the life of a subprocess is inextricably tied to its parent process? That if the parent process should die, the subprocess is killed also? In traditional Unix/POSIX, the subprocess would simply be reparented to PID 1.

Well, Linux has prctl(2) <https://manpages.debian.org/bullseye/manpages-dev/prctl.2.en.html>, which among its myriad of options, lets you specify a signal to be sent to the child process when the parent dies (PDEATHSIG). If you set this signal to SIGKILL, then the child has no choice but to die--no ifs or buts.

> ... and why there are still VMS customers - it's been too hard for them to move 
> applications to other platforms, for a variety of reasons. The ones that 
> were easy to move have largely been done. What's left is the ones that 
> are difficult.

I suspect even they are finding a way, as time inexorably drags on; as the way forward seems to be taking longer and longer to appear, the only way left is out.

> The reasons for wanting to use the DEC compiler front-ends is that DEC 
> languages weren't terribly standards-conformant: once upon a time, the 
> DEC market was big enough that the company didn't worry too much about 
> those things. It isn't just additional command-line options, it's 
> differences in the languages and libraries. Providing Clang for C++ and 
> standard-conformant C is an addition: the DEC C will still be needed for 
> historical code. 

You have the source for those GCC and LLVM compilers, that you can adapt as necessary. Plus you have the source for DEC’s own proprietary compilers, that can also be adapted as necessary.