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. :-(
> 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.
OK, I see. There is no "library confusion" which could happen here. EMX
libc has a specific name (EMXLIBCM.DLL) which does not conflict with any
other DLL. This kind of preloading might help when having different
versions of the same DLL in different locations, but this isn't the case
here.
>> 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).
OK, this would be indeed a slightly better option (especially if it is
done in a smart way not to force the OpenSSL dependency if not necessary,
e.g. by changing the original procedural variables used for Winsock to the
OpenSSL procedures if OpenSSL is used in the project). This would be
obviously matter of some later optimization once the general approach of
going via OpenSSL is confirmed to work.
> 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.
That would be very nice, of course, although I don't want to misuse your
helpfulness; personally, I might not have much time for this topic in the
coming days except for short and quick tests. :-(
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
