Op 3/14/2010 8:21 PM, Peter Stuge schreef:
>
> However, it will require some education of us unix guys without
> strong VMS background. I know next to nothing about VMS so far, but
> if we can make changes to libssh2 code or development practice to fit
> better into VMS then I think those changes should be considered very
> carefully.
>
Ok, I'll try. ( I'm going for Olympic Geek medal here :-))
see also : http://labs.hoffmanlabs.com/node/163
if you really want know:
http://h71000.www7.hp.com/doc/83final/4548/4548pro_011.html#itn_share_ch
if you don't get scared quickly, for a really geeky use of shared images :
http://h71000.www7.hp.com/openvms/journal/v7/faking_it_with_openvms_shareable_images.pdf
In short, there are 2 features for shared images on VMS that are
different to .dll's and .so's:
- Normally, when developing applications using a shared image, you link
against the shared
image on the system. At link time, the jump vectors in the shared
image are read and coded into the
resulting executable ( the application you wrote).
This is fundamentally different on Unix and Windows, where at run
time the shared image
(excuse my French) after an extensive search is opened, and the
application is
directed to the proper routine in the shared image based on the name
of the routine.
This means that on VMS if a new routine is added to the shared image
without further ado,
the vector table after this new routine has shifted one place, and
executables linked against the
the old version will bomb, or worse, do something really horrible,
if any of these routines is
accessed.
The standard solution is of course to make sure new routines are
added at the
end of the vector table, so all old routines keep the same vector.
And as a safeguard
there is the global section match.
( there is way to use shared images on VMS with a dynamic lookup,
lib$find_image_symbol but that is not a common way
to offer access to a complete API, although it does exist for
Apache apparently.)
- To make sure the available shared image on a system and the shared
image at link time
of an application are compatible, every shared image is linked with
a Major version and a Minor version,
and a match parameter, usually Less or Equal, meaning the major
version of the shared image against
which the application has been linked must match, and the Minor
version at runtime has to be at least
the Minor version at linktime.
When an application is started, VMS will open the shared image
available, and will immediately bomb
out if this global section match as it is called doesn't meet the
conditions in the shared image.
This is the version that will need to be maintained. It roughly
matches the ld version, but needs extra care
and attention, and maybe more 'bumping'.
Pro's and con's:
This sounds all a bit restrictive and complicated, but there are
some advantages too:
- as a developer, it is possible to guard against mismatches of
applications and shared libraries.
- dll hell, is an almost non-existent phenomenon on VMS, and if it
is, it's a bug introduced by the
developer of the shared image, noone else. That is a mixed blessing.
- there is no such thing as opendl. That problem has already been
solved at link time.
Anyway, these are design decisions made in the 70's and a discussion
on the pro's and con's
is pretty useless: it won't change.
Plan:
So, I will not be following the ld versioning in the global section
match id,, but the major ld
version and major * 1000000 + minor*1000 + patch of the build version
to start with, as
this will probably be most close to what the glocal section id is
intended for.
It is a number that actually doesn't mean anything, it's just a
safeguard against DDL hell.
In the actual identification of the image ( the string that describes
the shared library ) I'll use both the ld version
and the build version to exactly identify the image.
To make sure several versions of libssh2 can exist on a VMS system
I'll also make sure the Major (
and if necessary Minor version) are in the filename of shared image
in the binary kit if it is an incompatible
version to the last one. To make this transparent the logical name
pointing to the image library has to reflect
this version as well.
I don't think it would be fair for the libssh2 maintainers to take
these restrictions into account,
as it is so VMS specific. On the other hand, it would be nice to
have a routine vs. date-added/deleted/modified
cross reference.
> The overall goal is that libssh2 should be very portable. That means
> we love VMS too. :)
>
>
> //Peter
>
>
LOL! The actual VMS specific changes in the code are very small, I am
trying keeping up with the daily builds now,
my agenda is now making a VMS PCSI ( binary) kit and automating the
process of producing this
as automatically as possible.
Jose
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel