[Info-vax] VMS on Raspberry Pi 5

[Jake Hamby (Solid State Jake)]

On Tuesday, November 14, 2023 at 5:40:30 AM UTC-8, Arne Vajhøj wrote:
> On 11/14/2023 4:27 AM, Johnny Billquist wrote: 
> > 
> > Do you think all the propietary APIs and libraries under Unix are any 
> > different? 
> > Nowadays there is POSIX (didn't even exist back when VMS was designed), 
> > but POSIX only covers a small fraction of the libraries people use in 
> > development. 
> > 
> > Online documentation like man-pages is helpful, but it's usually not 
> > nearly as deep as the VMS paper docs. The fact that the VMS docs were 
> > made available as HTML and PDF was a nice improvement.
> The VMS API (SYS$, LIB$ etc.) is tiny by todays standard. 
> 
> Windows is huge. Win32, MFC, OLE/COM/ATL, .NET FX, WinRT etc. 
> are probably a factor 100 bigger than VMS. 
> 
> Linux is a bit more tricky to measure, because it is not very well 
> defined what to count: Linux kernel, glibc/musl, curses, 
> Xlib + Xt + GTK/Qt, hundreds of development libraries available 
> via distro package manager. I will claim that a "typical" 
> Linux development machine has a lot more API's installed 
> than VMS has. 
> 
> The non-OS platform API's are also way bigger than VMS API 
> (Java + Maven repo, .NET Core + NuGet, Python + PyPi, 
> JS + npm etc.). 

I agree. The entire Win32 API is enormous because everything is jumbled together: processes and file handling, GUI, etc.. Win32 isn't even the native NT API: there's a different set of "Nt" APIs that Win32 calls into, and some programs/libraries (libuv is one) know how to open "ntdll.dll" and call native APIs directly whenever Win32 doesn't do what they need.

If you compare the low-level Win32 APIs to VMS, they're closer to each other than either of them is to UNIX. In Win32 and VMS, you have APIs that take many arguments and perform an entire function, like creating a process, while in the UNIX world, the API is deceptively simple. System calls like fork(), exec(), etc. take zero or few arguments but may require more work to get the job done, such as all the nonsense related to "close on exec" and dup()'ing file descriptors required to set up the environment for a child process.

The VMS APIs show their age by having a relatively large number of functions intended for assembly language, FORTRAN, etc. programming, for string handling and comparison, getting random numbers, and other functions that everyone now expects the programming language and its runtime library to handle: MTH$, STR$, OTS$, and some of $LIB. But you can just ignore all of those functions, and they don't add up to much code by today's standards. Back when RAM was expensive, the utility libraries were an excellent use of shared libraries years before SunOS and System V added them in the mid-1980s.

I think the complexity that's most confusing to someone new to OpenVMS isn't the APIs themselves so much as the underlying abstractions that don't exist elsewhere. Logical name tables and DCL symbols are both types of key/value mappings that are used in different places for different purposes. The C library exposes logical names as environment variables, but not the other way around. The RMS record APIs are roughly comparable to a library like Berkeley DB, but if you're not used to those features being integrated into the filesystem, then VMS may look overengineered, until you need something like what they provide.

The other complexity comes when you want to deal with I/O at a low level. $QIO is intimidating, with 12 arguments (although 6 of them are passed to the device driver). POSIX appears much simpler, until you actually have to use ioctl() or fcntl() and realize that not only is it not any simpler than VMS, but it's often not standardized between UNIXs. The abstraction of accessing everything through a file descriptor (UNIX) or channel number (VMS) is almost identical between the two.