3 ms·

The story is great, but I was a bit confused with this part: "because C was not very well adapted to VMS" It's been a long time, but I remember using C on VMS

by tyingq 4y ago

The story is great, but I was a bit confused with this part: "because C was not very well adapted to VMS" It's been a long time, but I remember using C on VMS in the 80's, and I don't recall anything odd about it.

aradox66 4y ago
Sometimes those decisions reflect the technical familiarity / capacity of folks on the job ...
nl 4y ago
I know earlier (pre-2000's) versions of VMS were written in BLISS-32: https://en.wikipedia.org/wiki/BLISS https://en.wikipedia.org/wiki/BLISS This would have been 1991 or 1992 so DEC was probably still a BLISS shop. Maybe they didn't ship C manuals or something.
- skissane 4y ago
  > I know earlier (pre-2000's) versions of VMS were written in BLISS-32: https://en.wikipedia.org/wiki/BLISS https://en.wikipedia.org/wiki/BLISS My understanding is that, even for the brand new x86-64 port, large parts of OpenVMS are still written in BLISS and MACRO, although I believe they prefer C for brand new code. A key component of the porting effort was modifying the existing BLISS and MACRO compilers to produce x86-64 binaries instead of Itanium ones. [0] > This would have been 1991 or 1992 so DEC was probably still a BLISS shop. Maybe they didn't ship C manuals or something. I suspect the actual reason – in 1993, DEC released a new C compiler for OpenVMS – DEC C, to replace their earlier VAX C compiler. [0] DEC C was designed to be a fully ANSI C compiler, VAX C was a pre-ANSI (K&R) compiler with various unusual proprietary extensions, along with some half-finished ANSI C compatibility tacked on the side. Probably, they were used to writing ANSI C on other platforms, and were given VAX C to use as a as a compiler, and were (quite understandably) frustrated by its inability to compile ANSI C code correctly. [0] https://vmssoftware.com/docs/2021-04-27-x86-Compiler-Update.pdf https://vmssoftware.com/docs/2021-04-27-x86-Compiler-Update.... [1] https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_014.html#soft5 https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_0...
  - cdegroot 4y ago
    Timing-wise, that could be correct. However, the biggest issue to me was the inability to nicely interact with VMS system and library calls. Even with the best that DEC could do in their header files, setting up a complex $QIO was a headache, certainly compared to more “native” languages. I was a bit of a fan back then. Much more powerful and stable than pretty much anything I encountered in Unix-land. And once you tossed out the C compact libraries, very fast, too :)
    - skissane 4y ago
      OpenVMS native IO code, in C, can certainly get rather hairy, from what I’ve seen. For example, the OpenVMS port of SQLite: https://github.com/endlesssoftware/sqlite3/blob/8004eeafeec9ac4bc0fbc7a3c0bb01eca55694a0/os_vms.c#L223 https://github.com/endlesssoftware/sqlite3/blob/8004eeafeec9... When you speak of “more ‘native’” languages, what do you mean? BLISS? MACRO? Pascal/BASIC/COBOL/FORTRAN? How do they make code like that simpler?
tgv 4y ago
And emacs wasn’t written in C?
speedbird 4y ago
Used C on VMS in late 90s and remember strange bugs trying to bring up X windows and GNU packages due to bit order incompatibilities.
cdegroot 4y ago
Original author here. C worked on VMS but it was not a good match. VMS used complex data structures and async for kernel comms ($QIO) and the C standard library was built with other expectations. Setting up and handling syscalls was cumbersome and the POSIX style library was slow. I still remember picking up VAX Pascal for an other gig and getting a decent taste for the delight that VMS systems level coding was. Yes, Pascal was better suited for that than C on VMS. Fun times :)
- tyingq 4y ago
  Ah, thanks for the response! My experience in the same timeframe was using C and Fortran on VMS, though I suppose the work I was doing wasn't digging into the same level of detail as you did.

by tyingq 4y ago

aradox66 4y ago

Sometimes those decisions reflect the technical familiarity / capacity of folks on the job ...

nl 4y ago

I know earlier (pre-2000's) versions of VMS were written in BLISS-32: https://en.wikipedia.org/wiki/BLISS https://en.wikipedia.org/wiki/BLISS This would have been 1991 or 1992 so DEC was probably still a BLISS shop. Maybe they didn't ship C manuals or something.

skissane 4y ago
> I know earlier (pre-2000's) versions of VMS were written in BLISS-32: https://en.wikipedia.org/wiki/BLISS https://en.wikipedia.org/wiki/BLISS My understanding is that, even for the brand new x86-64 port, large parts of OpenVMS are still written in BLISS and MACRO, although I believe they prefer C for brand new code. A key component of the porting effort was modifying the existing BLISS and MACRO compilers to produce x86-64 binaries instead of Itanium ones. [0] > This would have been 1991 or 1992 so DEC was probably still a BLISS shop. Maybe they didn't ship C manuals or something. I suspect the actual reason – in 1993, DEC released a new C compiler for OpenVMS – DEC C, to replace their earlier VAX C compiler. [0] DEC C was designed to be a fully ANSI C compiler, VAX C was a pre-ANSI (K&R) compiler with various unusual proprietary extensions, along with some half-finished ANSI C compatibility tacked on the side. Probably, they were used to writing ANSI C on other platforms, and were given VAX C to use as a as a compiler, and were (quite understandably) frustrated by its inability to compile ANSI C code correctly. [0] https://vmssoftware.com/docs/2021-04-27-x86-Compiler-Update.pdf https://vmssoftware.com/docs/2021-04-27-x86-Compiler-Update.... [1] https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_014.html#soft5 https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_0...
- cdegroot 4y ago
  Timing-wise, that could be correct. However, the biggest issue to me was the inability to nicely interact with VMS system and library calls. Even with the best that DEC could do in their header files, setting up a complex $QIO was a headache, certainly compared to more “native” languages. I was a bit of a fan back then. Much more powerful and stable than pretty much anything I encountered in Unix-land. And once you tossed out the C compact libraries, very fast, too :)
  - skissane 4y ago
    OpenVMS native IO code, in C, can certainly get rather hairy, from what I’ve seen. For example, the OpenVMS port of SQLite: https://github.com/endlesssoftware/sqlite3/blob/8004eeafeec9ac4bc0fbc7a3c0bb01eca55694a0/os_vms.c#L223 https://github.com/endlesssoftware/sqlite3/blob/8004eeafeec9... When you speak of “more ‘native’” languages, what do you mean? BLISS? MACRO? Pascal/BASIC/COBOL/FORTRAN? How do they make code like that simpler?

tgv 4y ago

And emacs wasn’t written in C?

speedbird 4y ago

Used C on VMS in late 90s and remember strange bugs trying to bring up X windows and GNU packages due to bit order incompatibilities.

cdegroot 4y ago

Original author here. C worked on VMS but it was not a good match. VMS used complex data structures and async for kernel comms ($QIO) and the C standard library was built with other expectations. Setting up and handling syscalls was cumbersome and the POSIX style library was slow. I still remember picking up VAX Pascal for an other gig and getting a decent taste for the delight that VMS systems level coding was. Yes, Pascal was better suited for that than C on VMS. Fun times :)

tyingq 4y ago
Ah, thanks for the response! My experience in the same timeframe was using C and Fortran on VMS, though I suppose the work I was doing wasn't digging into the same level of detail as you did.