Subject: Re: Port to VMS; how to get changes into the main code stream?

Re: Port to VMS; how to get changes into the main code stream?

From: Jose Baars <>
Date: Sun, 07 Mar 2010 22:51:23 +0100

John E. Malmberg schreef:
> A different image name would be used for different incompatible
> revisions of a shared image.
This is probably the easiest way to go.
> A program does not have to be built with GNV to use the GNV directories
> to hold it. The GNV directory tree is a convenient one to use to match
> Unix conventions.
Yes, why not. I'm less convinced of your insistence of using Unix
or build procedures, but it's good idea to try to start a common place
to put
things, regardless of the way how they end up there.

> I would recommend having a PCSI kit install and if needed create the
> GNV$GNU: directory tree, and to put everything under GNV$GNU:[usr] which
> will be seen by Unix programs as "/usr"
Yes, I like that idea too, anyone on VMS knows that way of installing.
If I put the build procedure in the vms subdirectory, this would not
be pose a major problem to anyone else having a go at doing this for
libssh2. Never made a PCSI install kit, but I know which door to
knock if I run into problems.
> Also please include a VMSified xxxx.pc file if the libssh2 project has
> one, and any of the documentation files in the same directories that
> they would be on a Unix system.
No .pc file. Lots of docs, I'll have a go at converting the man stuff
 to a help library. The HTML could stay as is.
> One benefit of using the GNV style build is that you can run the UNIX
> install procedure in a test mode to identify what files should be in the
> binary kit and where they should be. Otherwise, you have to figure that
> out some other way.
Yes, but a lot of people are not running GNV on their system, and they
usually have good reasons, or are not allowed to by company policy.
> If new parameters are added, then the va args method can be used. VMS
> calling standard allows a routine to be changed from a fixed number of
> arguments to one that takes additional optional arguments, as long as
> the routine understands that.
I think that would be too intrusive in the libssh2 code, and/or a lot of
work creating
jacket routines. Also, if parameters change in meaning ( for instance
Session* becomes Channel*) you would end up with programs producing
weird run time errors. If something is incompatible, then it is
Bump the (major) version and put the version in the imagename, allowing for
dozens of libssh2's to be alive.

I'm working on a build procedure that adds new procedure entry points to the
the end of the shared image by a balanced read aginst the major version
so new image libraries would maintain compatibity over minor versions.
> Direct references to data in a VMS shared image is a pain, because it is
> difficult to maintain backwards compatibility if the size of the data
> changes. The trick that I have seen to do this is to only use functions
> that return a pointer to that data. Then the header files use macros
> that will change direct references to the data to call the routines.
No such thing in libssh2 as far as I can tell.
> Please start a libssh2 note in the PORTING_TO_VMS conference about your
> project.
I will.
> Once you get a PCSI kit built, I can get it added to the FTP repository
> there.
Sounds good.

-- is the private domain of Jose Baars*Josť Baars*
  State 56,5509 NX Veldhoven,Nederland


Received on 2010-03-07