Thanks for the guidance John. To be honest I don't want libssh2 for the sake
of curl, but for it's own sake. On the other hand it would probably be a useful
exercise.I'll see how far I get.
libssh2 has only lowercase functions, no real problems there, some
functions exceed
the maximum lenght for the linker, though.
>There are 3 stacks in use on current versions of VMS. For the purposes of most
>programs, you do not need to care. The C runtime has wrappers and dynamically
>loads the TCP/IP library as needed.
A test if a socket is blocking or non blocking in libssh2 is stack
specific I'm afraid.
I do a test on the definition of SO_STATE to execute the TCP/IP
services specific
statement.
The setting a socket nonblocking might not be an issue, but of that
I'm not sure.
> 2. Configure is badly broken on all platforms that support backwards binary
> compatibility and this really is exposed on VMS and configure seems to be
> evolving to be worse in this area instead of better.
>
As far as I understand configure scripts are useful to discern between
the hundreds
of *ix implementations, and the complex versioning issues on these systems.
On VMS, I see hardly any added value. I'd rather stay clear of it, it solves an
issue that hardly exists on VMS, but I understand that for conformity one would
go that way. I'll have a look.
> When I refresh a port of an Open Source project to VMS, I search for those
> and try to eliminate them. Mnlbaajany times I find that either they were never
> needed, or they were incorrect. There are some in curl that can be removed
> by changing the os specific header files to create wrapper macros to
> redirect the routines to ones customized for VMS.
>
In a lot of projects, and partly so in libssh2, the test is on the availability
of features, in stead of a platform test. In libssh2, some platform tests
exist already for WIN32, which would break the defining of macro's in the
os specific header files, without having to change the macro's for
Windows vs. Unix as well. I am reluctant to do that.
> The main issue that would likely to show up for libssh2 is that VMS has a
> limit on how much it can read/write to a socket in one operation.
>
No, that seems not a problem. The libssh2 developers have been very conservative
or rather prudent. Writes are limited to 16k, in my experience,
problems start to pop up
when reads and writes get > 32k. Anyway, I have most examples working.
> VMS also has problems with ".." in #include directives, and some of the
> shared images only have uppercase universal symbols.
No problems there either. libssh2 is only depending on OpenSSL (I use HP's,
for convenience) , and zlib. Zlib on encompasserve seems like the way to go.
> Using the 'diff -u' option with exact case UNIX style path names in quotes
> has been good enough for the projects that I have worked on.
That was also suggested by Thorvald. I like the idea of using git,
though, as it might
save me manual labour in the end.
Question: should I do that against a current tarball or the latest
stable release?
Jose
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-02-26