>> You could comment out the lines in THTTPSend.InternalDoConnect that set >> FSock.SSL.SNIHost but I think this is just a red herring. > Will do and let you know. I assume you mean commenting it out temporarily > for the debug purposes only, right? Right. SNI host is only used for servers hosting many certificates for different domain names using the same IP address.
> There should be no C runtime involved when accessing the standard OS/2 API > (which includes both the native BSD sockets and the Winsock compatibility > layer). Whatever is done when using EMX libc, it must still go through > this OS/2 API in the end. However, I understand that there may be some > socket initialization involved on the EMX libc side (this indeed seems to > be the case as suggested by peeking into > http://svn.netlabs.org/repos/libc/branches/libc-0.6/src/emx/src/os2/tcpip.c > - really bad, all this ugly world of mixing file and socket handles > together on a platform having these concepts completely separated :-( ). > I'll see what I could do (probably start by extending the previous test to > import the "send" call from EMX libc). It would be the best to just > allocate the fake "file" handle expected by EMX libc to the existing > socket number if necessary (i.e. if OpenSSL is involved), but I'm afraid > that the respective EMX libc function (tcpip_new_handle) may not be > exported / accessible externally. Too bad. :-( When talking about "forcing" the use of the EMX library I was thinking about something like the unix LD_PRELOAD where you can force the use of a library by pre-loading it. The loader wouldn't load any other library to resolve externals if they are already in the lib pre-loaded. On windows, you can use the same exported name in several libraries but when the dll's have the same name you can force the use of one or the other by explicitly loading them (dynamically) . I don't know what OS/2 is doing. > The OS/2 implementation of BSD sockets should not use any C run time > itself, but I could try importing the EMX libc versions of send, recv, > accept, bind, select, etc., in the worst case. _Very_ ugly for a > Pascal program on a platform not providing any libc as part of its > official API at all (i.e. much worse than with Linux where libc may > not be necessary for some tasks, but at least it is always included > and accessible - OS/2 also includes some libc for certain > applications, but the official API doesn't depend on this libc and it > is only used for some "user-land" tools and applications). Thanks anyway. Yes this is ugly. An alternative would be to do everything with openssl instead of winsock or BSD. At least that would be not as messy as trying to sort out libc libraries but you'll need to add 1 or 2 new functions to ssl_openssl_lib. A Connect translates into PBIO:=BIO_new_connect('hostname:port'). Send becomes cnt:=BIO_write(PBIO,buf,len) and recv becomes cnt:=BIO_read(PBIO,buf,len). Closing the connection is just a BIO_free(PBIO). I'm a little short on time right now but later I can help you to get that working on linux or windows. The code should be the same everywhere. Ludo ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ synalist-public mailing list synalist-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synalist-public
