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
