Thanks for your thoughts, William. I confess I'm still uneasy. Actually, I'm coming not so much from a Unix perspective as from a Windows perspective where we've dealt with dueling DLLs and DLL Hell for years. I don't recall previously looking at an app (single .exe file) where different components of the app were using different versions of Winsock out of two different DLLs. My concern was that different components of the app are operating on the same socket through different DLLs and whether that would cause problems like trashed/inconsistent/missing state info or whether anything else would go wrong. Among other things, the WSAStartup() negotiation is done by a part of the app that's using ws2_32, so a Winsock2 socket created by ws2_32 is then passed to OpenSSL which only understands Winsock. Any potential for problems here? Mike
________________________________ From: [EMAIL PROTECTED] on behalf of William A. Rowe, Jr. Sent: Thu 11/23/2006 10:39 AM To: openssl-users@openssl.org Subject: Re: WIN32 winsock vs winsock2 coexistence? Brown, Michael A wrote: > I'm looking at an app where the app and all libs/DLLs it uses EXCEPT > openssl use ws2_32, and openssl uses wsock32. Is this a problem or can > the two coexist peacefully? It makes me somewhat uneasy. Well, using winsock period makes me uneasy ;-) Seriously - no - there's no issue. You are coming from a unix perspective where an exported function such as 'connect()' exists once in the global symbol table. Not so on win32 - it's more akin to the OSX two-level name- space schema. When you bind a symbol on windows, you bind the PE Binary to the specific function -within- a specific DLL. Because they all become system handles, there are really no other differences. Bigger issues include using nonblocking sockets on winsock functions that really expected a blocking socket, etc. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
<<winmail.dat>>
