> -----Original Message-----
> From: curl_at_contactor.se
> Sent: Monday, August 06, 2001 12:07
> To: Curl Mailinglist <curl_at_contactor.se>
> Subject: Re: VMS Curl
>
>
> On Fri, 13 Jul 2001 Nico.Baggus_at_mail.ing.nl wrote:
>
> > I have a ZIP file containing the first attempt to port curl
> 7.7.2 to VMS.
>
> Excellent work!
>
> I got it, unpacked it and made a diff from the original 7.7.2
> and applied
> that to my current sources. There was only a few places that
> failed, more
> about those below. It still compiles/builds fine on my
> solaris box, even
> after the patches! ;-)
>
> I have a few questions/remarks, and remember that I know
> hardly nothing about
> VMS:
>
> 1. You can't run the configure script on VMS, right? I see
> that you created a
> config.h that must work for you. To make it survive, we
> must have it use a
> separate name, like config-vms.h (to follow the already established
> standard set by the win32 version) and then have
> lib/setup.h adjusted to
> include that file for VMS. Is it OK if I do that?
>

No problem.

> 2. A lot of the '#ifdef VMS' cases fix size_t comparisons <
> 0, when I guess
> the VMS' size_t is unsigned. This is not a VMS-specific
> problem, but
> something that is gonna be corrected globally. I think
> I'll let these
> #ifdefs through anyway for now, but we should check them
> later to see if
> we can't get rid of a whole lot of them. (Linus works on
> that size_t
> problem.)

No problem either.

>
> 3. Your file 000readme.vms concerns how to build curl on VMS.
> I think this
> info should go into the docs/INSTALL file, as that
> contains all the build
> info for other platforms. That OK with you?

Also no problem, (The 000read.me file is a convention on DECUS tapes
as files on VMS are stored sorted by name into directory files, they allways
come up first.)

>
> 4. I noticed several changes done by you that only added
> white space, such as
> this one:
>
> - getsockname(sock, (struct sockaddr *) &add,
> (socklen_t *)&size);
> + getsockname(sock, (struct sockaddr *) &add,
> (socklen_t *) &size);
>
> Is that really necessary? It indicates that the C compiler
> is serverly
> screwed up.

Might by that I did a change near by and deleted a line and retyped it
with tabs/space replaced by spaces/tabs, white space is of no concern...

>
> 5. Why this change:
>
> - Curl_FormFree(http->sendit); /* Now free that whole lot */
> + _Curl_FormFree(http->sendit); /* Now free that whole lot */
>
> ?? I can't understand why that would be needed, nor do I
> like to break my
> naming scheme like that.

Well there were some problems there because of Case sensitivity....
The names curl_formfree, CURL_FORMFREE etc. are equal for the librarian/linker
ONLY the C compiler is case sensitive, so to distinguish between
curl_formfree & Curl_FormFree needs to be resolved, I took the easy way out
that obviously needs work!

>
>
> ... I'll make a new tarball available when we've sorted out
> these matters so
> that it could be tested again on VMS to see that I haven't
> broken anything.

Testing will be a problem with current toolset, as the fork() paradigm is'n
supportable
on VMS. (There is a vfork() routine but only the vfork()/execXXX() will do some
things close to
fork()/exec() but NOT copy the address space of a parent to a child, it just has
some special stuff
to migrate open file handles, if they have compatible locks etc.etc. There are
also issues about
ascii/binary files (and f.e. non-stream files on VMS). There is also work to be
done.

Currently I'm swamped with work so I have made little progress since what you
have now.
Telnet is an issue I want to look into, perhaps it's better to wait for the
tarball
with the winnt telnet issues solved, because the problems look quite the same.

Regards,
Nico Baggus

-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
Received on 2001-08-06