RFC: Adding Mac support to secur32/schannel.c

[Ken Thomases]

On Feb 1, 2011, at 10:19 AM, Juan Lang wrote:

> I may be flogging a dead horse here, but I personally am loath to see
> another implementation creep in, side by side with the existing one,
> that has no guarantee of working any better.

Well, it won't work any better, just as well as.

> I don't see how this
> helps CodeWeavers, either, other than reducing installation
> complexity.

Well, Outlook didn't used to be able to connect to Gmail IMAP in our Mac product and now it does.

> If there are bugs in the new implementation, and I expect
> there will be, you'll still have a large support load.  Worse, even if
> you succeed in fixing bugs for your Mac customers, the rest of us
> don't benefit, as the current implementation still isn't getting any
> support.

That's not true.  First, if there are bugs that affect our products, it will likely affect both our Linux and Mac products, and we'd fix it in both.

But more to the point, as I've said before, the schan_imp_* stuff is a very, very thin wrapper around the platform library (Secure Transport on the Mac and GnuTLS elsewhere).  It is quite unlikely that the sorts of bugs you're concerned about -- in the logic of schannel -- would be in the platform-specific code.  They'd be in the code that's shared.  So, the fixes would be shared, too.

> If there are development resources available to work on
> schannel, why not put them into something that benefits the project as
> a whole?

Everybody, whether volunteer or commercial, devotes development time to Wine to "scratch their itch", however they define that.  For us, it's largely to meet customer needs.  This work did that.  The work you describe doesn't, particularly.  It may, someday.  It is quite a bit more likely to now because our Mac product has schannel support, so it will get exercised by many more of our customers, and they'll find the problems with it.  (Or, if few real-world applications encounter limitations with schannel as it stands, then schannel is de facto fine as-is.)

Lots of work contributed to Wine doesn't benefit everybody, but only improves things for one particular use case.  It's still an improvement to the project as a whole, even if most don't receive the benefit.

Regards,
Ken