Hi all,

> Get well soon.

Thank you for the well wishes - I got a good night's sleep but am still
feeling pretty crap this morning :(

I'm dosed up on Ibuprofen at the moment to try and reduce the fever but I
might have to nip out in a bit and grab some paracetamol based cold and flue
type remedies.

> As Gün sugested "SSL-Windows-native" or "WinSSL"
> without version number information.
> But, only when actually using Windows SSL
> implementation. Unless I'm wrong, that is when
> schannel is in use not simply when SSPI is used.

I'm not opposed to not including the version number - this would be
consistent to what WinIDN displays, however, I also think including the
version number would also be consistent with all the other libraries that we
display. I know this is a community effort but perhaps some direction from
Daniel and whether the version number, as a rule of thumb, should be
included for all items in the version string or not is needed here.

I also think, as per the discussion I started 6 weeks ago which I thought we
had decided to do, hence my work here, was that the package name "WinSSPI",
"Windows SSPI" or "SSPI-Windows-native" should be displayed for the other
features that SSPI offers not just the SChannel SSL support - again this is
synonymous to the other Security Providers that curl uses and provides
consistency.

The inclusion of SSPI in curl has obviously changed a fair amount since it
was first included as a feature and that was why I recommended including it
in the version string back in April and moving to a scenario where SSPI
isn't listed in the features list ;-) For API compatibility we have decided
to keep it in the features list as well as listing it in the package /
version string. If this is something that you had a strong opinion on, and
I'm still not sure if it is or not, then why didn't you let us know 6 weeks
ago before I spent two days doing the rework and learning curl's makefiles
when I didn't need to.

> Mostly library version number given for a system library.

I don't have an issue with that, whilst others Guenter, Marc, Gisle et all
don't seem to mind either.

The only possible objection I have is... that version.lib is currently being
linked to statically and if that is a problem for running curl on 12-year
old+ versions of Windows then we *should* consider dynamically including it
like we do with secur32.dll for example.

S.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-06-13