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

[Stephen Hoffman]

On 2020-03-12 23:14:08 +0000, Simon Clubley said:

> I am not. The problems originate from the need to support Macro-32 when 
> calling VMS APIs but they infect other languages on VMS equally badly.
> 
> If you could write VMS API code which used C style (or other higher 
> language code) addressing to their full ability, you could simply write 
> something like /mode=64_bit on your compile and link commands and be 
> done with it.
> 
> You can't do that on VMS due to the way the VMS APIs are structured.

There are very roughly three API linkage styles routinely seen on 
OpenVMS. There are the by-value, by-reference, and by-descriptor 
linkages that are easier for the higher-level languages (e.g. LIB$, 
STR$, etc., and more easily called from BASIC, Fortran, and such), 
there are the pointer-based linkages are easier to work with from 
Macro32, Bliss, and C (e.g. system services, record management 
services, smg$create_menu, etc), and there are the VAX-isms; the 
Macro32 linkages using JSB and coroutines and the call stack and other 
gnarlies. Most of the exposed JSB-linkage stuff has been replaced, as 
part of the work to enable C for system programming.

The lower-level APIs are quite fond of creating user-populated data 
structures as part of sending or receiving the data. RABs, FABs, XABs, 
PQLs, descriptors, itemlists, OpenVMS just loves showing off its fleet 
of API data structures to every developer working with system services 
and record management services and related APIs. Most of these data 
structures contain pointers. The need to disable alignments is a nice 
wrinkle to trip the unwary, too. And for most folks, this also involves 
showing off how to pack and unpack and not-easily-upgrade your own data 
stored in your own RMS records.

Exactly zero of these schemes makes a whole lot of sense for extensive 
new design and development work in the decade of the 2020s, save 
remediation and updates intended to preserve existing source code, and 
to a lesser degree the existing developers. They're all code slogs.

Of these schemes, the highest-level APIs are probably the easiest to 
handle and to work with, and with the least glue code. Though there's 
piles of glue code once you need system services, and using pointers 
from the higher level languages is a slog. The current necessity of and 
usage of the pointer-based linkages are unfortunately quite prevalent 
due to the choice of C as a development language for a whole lot of the 
code around, whether that code is targeting OpenVMS, ported to OpenVMS, 
or the OpenVMS language that the available developers happen to be most 
familiar with. This is also where Objective C really shown for app 
development, too. But I digress.

VSI has far larger projects and not the least of which being the x86-64 
port, and I really don't think they're going to be migrating APIs to 
message-passing / OO any time soon. We're at the 
happy-to-have-a-newer-C-compiler stage, not the modernize-the-APIs or 
flatten-the-address-space stage. As much as I'd like to see this whole 
segmented address space relegated, logical names relegated, RMS 
relegated, importing ideas and designs from and from past DEC MICA, 
making ~twenty years of updates takes a while to code and test and 
deploy. And yet longer to be accepted and adopted and added into apps.

I once thought itemlists and descriptors were a spectacular design, and 
used them all over the place.  Back then, they were, too.  Since I've 
encountered how much less application source code is involved with 
using common code to create and parse and generate these structures and 
variously to entirely remove the need for these API-related 
structures—this is part of message-passing and OO designs—my views 
around itemlists have changed. Getting rid of all that baggage makes 
the application source code a whole lot more clear, concise, and easier 
to work with. Yes, the itemlist "parser-generator" is still needed, but 
it's now common code, it gets tested and optimized, and it means each 
of us doesn't have to deal with parsing and populating these structures 
in our own source code.

But to each, their own. And there are trade-offs all the way down.

And no, the chances of the creation and adoption of a 
moderately-complete open-source OpenVMS variant is approximately nil. 
Need that? Use OpenVMS itself, or chat with Sector7, or maybe use an 
emulator running OpenVMS.



-- 
Pure Personal Opinion | HoffmanLabs LLC