On 11 Dec 12, at 9:46, Ludo Brands wrote: > On 11/12/2012 00:59, Tomas Hajny wrote: > > On 10 Dec 12, at 17:52, Tomas Hajny wrote: > >> On Mon, December 10, 2012 14:24, Ludo Brands wrote: > >>>> 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. :-( > > It seems that there is a call published by the EMX runtime for > > importing an externally opened socket handle, so this might be the > > best solution. I'll play with it once I find the needed time and let > > you know the results. > tcpip_impsockhandle? > > Attached is a modified httpsend and ssl_openssl that uses openssl BIO to > make the connection. It only works with https since I didn't change > TBlockSocket. TBlockSocket uses SSL_write and SSL_read for ssl > connections and send recv for non ssl. > > Test program: > > program project1; > > {$mode objfpc}{$H+} > > uses > Classes,ssl_openssl_openssl,httpsend_openssl; > > var > HTTP: THTTPSend; > s:string; > begin > HTTP := THTTPSend.Create; > try > if HTTP.HTTPMethod('GET', 'https://www.google.com') then > begin > setlength(s,HTTP.Document.Size); > HTTP.Document.Read(s[1],length(s)); > writeln(s); > end; > finally > HTTP.Free; > end; > end. > > Tested on windows. You'll need to check the library names in both files.
I fixed the library names and compiled the test, but it gets caught in an endless loop somehow (OS/2 shows me that the socket is created and in time_wait status, there is no visible output and it runs forever or rather until I interrupt it). It seems to get caught somewhere in one of the DLLs. One of the potential issues may be if the EMX socket handle is passed to the standard OS/2 API for socket handling (either via the Winsock layer or not), it would result in something unpredictible. I need to go to bed now; more testing later... Tomas ------------------------------------------------------------------------------ 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
