Geoff wrote:
Or we write our own BIO that wraps up whatever glue is desirable on the wine-side. Worst-case (and it's not that bad an alternative) is that you use a memory-base BIO to encapsulate all I/O and worry about moving data to and from "sockets", whatever they look like, afterwards.
That's what I've always done.
<snip>
So it's not a bad way to go at all.
Yep, in fact the "real" way to do this as far as Wine is concerned is to implement SSL in secur32.dll, since this is where Windows does it. It looks about like this, although as Geoff pointed out to me the API is a bit broken. Doing a BIO inside wininet.dll might be more expedient for Hans, who I think is trying to get as much of Wine as possible ported to MinGW.
You guys that know SSL better than I do: patches welcome :)
--Juan
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
Hi Juan, --- Juan Lang juan_lang@yahoo.com wrote:
Yep, in fact the "real" way to do this as far as Wine is concerned is to implement SSL in secur32.dll, since this is where Windows does it. It looks about like this, although as Geoff pointed out to me the API is a bit broken. Doing a BIO inside wininet.dll might be more expedient for Hans, who I think is trying to get as much of Wine as possible ported to MinGW.
I think you are right. This way we only have to dlsym/dlopen OpenSSL in once place rather than linking Unix functions to all of these dlls.
Thanks Stevem
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
-
Juan Lang -
Steven Edwards